The PowerBuilder code rule "Always use AES encryption algorithm in a secure mode" requires that developers use the Advanced Encryption Standard (AES) algorithm for all encryption operations. AES is a symmetric encryption algorithm that is considered to be one of the strongest and most reliable encryption algorithms available. When using AES encryption, it is important to always use a secure mode, such as Cipher Block Chaining (CBC) or Galois/Counter Mode (GCM). This ensures that the encrypted data is secure and not susceptible to attacks.

This rule states that when using cryptographic hash functions, SHA-1 or Message-Digest Algorithms should not be used. Cryptographic hash functions are used to provide a secure way of verifying the integrity of data. SHA-1 and Message-Digest Algorithms are known to be vulnerable to attack, so it is important to use stronger algorithms to ensure the data is secure.

This PowerBuilder code rule states that database queries should be constructed in such a way that they are not vulnerable to injection attacks. An injection attack is a type of malicious attack in which malicious code is inserted into a query in order to gain access to or manipulate data. To prevent such attacks, code should be written to ensure that user input is sanitized and that queries are constructed properly so that malicious code is not able to be injected into them.

This rule states that the Data Encryption Standard (DES) or Triple DES (3DES) should not be used in PowerBuilder code. DES and 3DES are outdated encryption algorithms, and are considered to be weak and insecure. It is recommended to use more modern and secure algorithms such as AES or RSA for encryption.

This rule states that when using encryption algorithms, they must be used in conjunction with the appropriate secure mode and padding scheme in order to ensure the security of the data being encrypted.

The rule "Encryption keys should be long enough" states that encryption keys used to protect sensitive data should be of a sufficient length to provide an adequate level of security. The longer the key, the more secure the data will be. Generally, the longer the key, the more difficult it is for an attacker to guess or crack the key. It is important to use strong encryption keys that are at least 128 bits long to ensure that the data is sufficiently protected.

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 PowerBuilder code rule "IP addresses should not be Hardcoded" states that IP addresses should not be stored directly in the code, but should instead be stored in a configuration file. This allows the IP address to be changed without having to modify the code. This helps to ensure that the code is easier to maintain and allows for easier updates in the future.

The rule "Never use Console logging in production" states that developers should never use Console logging when deploying their code to a production environment. Console logging is a debugging technique that allows developers to output information to the console window during code execution. While this can be useful for debugging purposes, it should not be used when the code is running in a production environment. This is because the information outputted to the console can be visible to users, which can lead to security and privacy issues. Additionally, the output from the console can also slow down the performance of the application, which can lead to an overall decrease in user experience. Therefore, it is best to avoid using Console logging in production environments.

This rule states that developers should never use the CoSetProxyBlanket or CoInitializeSecurity APIs in PowerBuilder code. These APIs are used to set the authentication level for a COM object, which can be a security risk when used incorrectly. As such, they should be avoided when writing PowerBuilder code.

The "OS commands should not allow injection attacks" rule states that when executing OS commands from PowerBuilder code, the commands should be validated to ensure that they cannot be used to inject malicious code into the system. This can be done by using parameterized queries, whitelisting accepted commands, or other methods of input validation. Additionally, the code should be written to ensure that any user-supplied data is properly escaped and sanitized to prevent malicious code from being injected into the system.

This PowerBuilder code rule states that regular expressions should not be used in a way that could result in a Denial of Service (DoS) attack. A DoS attack is an attack that attempts to make a system or network resource unavailable to its intended users. Regular expressions can be used to match patterns in strings, but they can also be used to create malicious input that can overwhelm a system with requests. To prevent DoS attacks, regular expressions should be used with caution and be thoroughly tested before being deployed in a production environment.

This rule states that the SOAP and INET objects should not be used when writing PowerBuilder code. These objects are not supported by PowerBuilder and can cause instability and unexpected behavior. Instead, developers should use other supported objects such as the Web Service Proxy or the HTTP Client object. Using these objects will ensure that the code is stable and reliable.

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.

This rule states that user IDs and passwords should not be hardcoded into any PowerBuilder code. This means that any references to user IDs and passwords should not be included in the code itself, but instead should be stored in a separate, secure location. This ensures that user credentials are kept confidential and secure, and that they can be easily updated when necessary.

This PowerBuilder code rule states that user input should not be allowed to inject or traverse paths, as this could allow attackers to gain access to unauthorized areas of the system. Path injection and path transversal attacks involve maliciously manipulating the system's file paths to gain access to areas of the system that the user is not authorized to access. To prevent this, user input should be validated and filtered to ensure that only legitimate paths are allowed. Additionally, it is important to ensure that the system is configured to prevent users from accessing areas of the system that they do not have permission to access.