The increasing number of cyberattacks has made application security a critical issue.
To ensure application security, it is essential to regularly scan the code to detect vulnerabilities that could be exploited to steal data or hijack the application's functionalities.
Visual Expert helps improve the security of PowerBuilder applications by working on several levels:
- It detects vulnerabilities in PowerBuilder code.
- It helps reduce the potential attack surface by listing dead, duplicate, or obsolete code.
- It identifies bad practices or inefficient code, for example, to optimize performance and make denial-of-service (DoS) attacks more difficult.
- For each issue identified, Visual Expert can propose modifications to fix it.
- For complete coverage, these checks cover both the PowerBuilder client and Oracle or SQL Server code if your application includes it.
Which Code Inspection Rules does VE follow for Security Scanning?
VE comes with 300+ pre-defined code inspection rules. To list some:
- Always use AES encryption algorithm in a secure mode
AES offers several modes (ECB, CBC, CFB…), some of them being faster or safer.
If you are using AES in your PowerBuilder code, your calls should use the most secure modes.
Visual Expert will scan your application, find less secure calls and highlight them in your code. - Never use Console logging in production
Console logging is a method to discreetly find out what the code is doing and warn if a problem has occurred. It should be disabled in production, as it could expose sensitive data and reveal information about the inner workings of your application. Visual Expert will track such issues in your Powerbuilder code, to help you disabled them before going live. - Never use CoSetProxyBlanket or CoInitializeSecurity
Calls to subroutines CoSetProxyBlanket, CoInitializeSecurity and CoInitializeSecurityAlias can generate security breaches. Visual Expert will find such calls in PowerBuilder code to help remove them. - Encryption keys should be long enough
To make cryptographic keys robust against brute force attacks, they must have a sufficient key size. Visual Expert will tell you if non-robust keys are used in your PowerBuilder code. - Database queries should not be vulnerable to injection attacks
Code Injection is an attack injecting malicious code that will be interpreted/executed by the application. In particular, SQL code injection allows performing illegal operations in your database (access to sensitive data, server takeover or shutdown…).
By nature, PowerBuilder applications are database-intensive and mission critical.
They handle large volumes of important data, which make them premium targets for hackers.
For instance, Visual Expert will search for string concatenations, used for building SQLs, and are not properly validated or escaped. They may create major loopholes for the SQL injection. Identifying and refactoring such queries will strengthen your database protection.
Learn more about How to Protect PowerBuilder Apps against Code Injection Attacks. - DES (Data Encryption Standard) or 3DES should not be used
The Data Encryption Standard (DES) is a symmetric key algorithm for encrypting digital data.
Its short key length of 56 bits makes it insecure. It should not be used anymore.
Visual Expert will find all DES calls in your PowerBuilder code, so you can remove them. - Encryption algorithms must be used with the appropriate secure mode and padding scheme
When securing your code with encryption algorithms, operation modes and padding schemes should be used correctly. Depending on the encryption algorithm used, Visual Expert will determine the proper padding and mode values, and verify that they are correctly used in your PowerBuilder code. - Generic exceptions should not be ignored
In terms of exception handling, CATCH blocks should always have a proper catching mechanism. Visual Expert identifies empty catch blocks to secure your code with a meaningful Exception handling. - IP addresses should not be Hardcoded
Hardcoding sensitive information like IP addresses, encryption keys or pass codes may expose them to hackers.If someone can access your runtime files, they may decompile them and expose this info. Leaking information protected by official regulations like GDPR, SOX, HIPPA can lead to major legal consequences.
Visual Expert will search for any hard coded IP Address for you to remove this security breach. - User IDs and Passwords should not be Hardcoded
Hardcoding sensitive information, such as usernames or passwords, IP addresses, and encryption keys can expose them to hackers. Anyone accessing the executable files may decompile them and find the sensitive information. Leaking data protected by official regulations like GDPR, SOX, HIPPA can generate severe legal consequences.
Visual Expert will search for hard coded user IDs and passwords, to let you remove these security breaches. - User input should not allow path injection or path transversal attacks
Data entered by users such as URL parameters or cookies should be considered suspicious. If your code dynamically generates a file system path from this data, a hacker could inject specific values such as '../' and change the originally intended path.
These attacks are often called "path traversal" or "directory traversal". They allow the attacker to access forbidden directories to read, modify or delete sensitive data or execute operating system commands.
Visual Expert will identify the code introducing such vulnerabilities to let you sanitize it. A possible defense strategy consists in defining a whitelist of authorized paths or characters. - OS commands should not allow injection attacks
If your code executes operating system commands based on user input, it must check the name of each command. Otherwise, a hacker could inject his own commands to perform illegal operations and compromise your system.
Visual Expert will detect these flaws in your PowerBuilder code, so you can fix them. For example, you can define a whitelist of safe commands and sanitize shell meta-characters. - Regular expressions should not allow Denial of Service attacks
It is highly unrecommended to generate regular expressions from user data, because it can lead to Regular expression denial of service (ReDoS).This type of attack exploits the possibility to drastically slow down the evaluation of regular expressions by maliciously using specific characters. An attacker can induce this situation when a program uses a regular expression and blocks it for a very long time (hence the denial of service).
Visual Expert pin-points such calls in your PowerBuilder code, allowing you to remove them or sanitize the input by removing/annihilating regex meta-characters. - Cryptographic Hash Functions should not use SHA-1 or Message-Digest Algorithms
The SHA-1 and Message-Digest algorithms: MD2, MD4, MD5 and MD6 algorithms are no longer considered secure. Visual Expert will check if such algorithms are used in your PowerBuilder code and locate the corresponding calls, to help you update them with more secure ones. - SOAP and INET objects should not be used
SOAP and INET PowerBuilder objects do not support use of TLS 1.2 and that makes it vulnerable to attacks. - Encryption keys should not be hardcoded
The PowerBuilder code rule "Encryption keys should not be hardcoded" states that any encryption keys used in PowerBuilder code should not be stored as plain text in the code. Instead, the encryption keys should be stored in a secure location outside of the code and referenced from there. This ensures that the encryption keys are kept secure and not exposed to potential attackers who may be able to access the code. It also makes it easier to manage the keys in the event that they need to be changed or updated. - The OLE web browser should not be used anymore (not secure)
The PowerBuilder code rule states that the OLE web browser should no longer be used, as it is not secure. This is because the OLE web browser is an outdated technology that is no longer supported or updated, and thus is vulnerable to security breaches. It is recommended that developers use more secure alternatives such as HTML or JavaScript. - EAServer - no longer supported - should not be used
EAServer is no longer supported since PowerBuilder 2017. The SSLServiceProvider object provides SSL/TLS services in older PowerBuilder versions. It may not support modern security protocols, making it unsuitable for contemporary secure communications. The CORBACurrent object is part of the CORBA standard for distributed objects. CORBA is outdated and not widely used in modern application architectures. The CORBAObject represents remote objects in a CORBA system. Its use is discouraged due to performance issues and obsolescence. The TransactionServer object handles transaction management in distributed applications. Modern frameworks provide more robust and scalable solutions. - Fields should not have public accessibility
This rule states that fields in PowerBuilder code should not be made publicly accessible. This means that they should not be declared as public variables, and should instead be declared as private or protected variables. This is important because making fields publicly accessible could open up the code to potential security risks, as it would allow external code to access and modify the fields without any restrictions. It is also important to ensure that fields are only accessible by code that is within the same class, as this will help to ensure that the code is secure and that it is only modified in the intended way.
