1. Development Security Guide
  2. How to address the OWASP Top10 in FLEXCUBE UBS

3 How to address the OWASP Top10 in FLEXCUBE UBS

This topic explains to address the OWASP Top10 in FLEXCUBE UBS.

Injection

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or SQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code.

FLEXCUBE uses Oracle database and, it has adequate inbuilt techniques to prevent SQL injections as, underlined below:
  1. Use of prepared statements (parametrized queries): FLEXCUBE uses PreparedStatement with bind variables to construct and execute SQL statements in JAVA.
  2. Use of Stored procedures: Stored procedures have the same effect as the use of prepared statements when implemented safely. Implemented safely means the stored procedure does not include any unsafe dynamic SQL generation. FLEXCUBE uses safe Java stored procedures calls.
  3. In addition to the above, wherever dynamic queries exist, FLEXCUBE uses adequate defense to sanitize the untrusted input. The use of DBMS_ASSERT.SIMPLE_SQL_NAME and the use of bind variables justify the fact.
  4. Escaping all user supplied input: This third technique is to escape user input before putting it in a query. If it’s a concern that rewriting the dynamic queries as prepared statements or stored procedures might break the application or adversely affect performance, then this might be the best approach for the purpose. However, this methodology is frail compared to using parametrized queries and there’s no guarantee that it will prevent all SQL Injection in all situations.

FLEXCUBE uses context specific escaping. It has a StringEscapeUtils.java file, where context specific escaping is handled.

Broken Authentication and Session Management

In FLEXCUBE Universal Banking Solutions application session interval will be validated against the session interval stored in the configurable file FCUBS.properties file. Validations are added to check the maximum time limit for the inactive session from being expired. Java API method javax.servlet.http.HTTPSession will set the max time out period for the session.

A maximum limit is imposed on the value passed to set the maximum limit of session interval. The maximum limit is a positive practical value. This validation is required to prevent long running sessions that can be actively targeted.

The default value for session time out is 30 minutes and it is configurable in the FCUBS properties file.

The session used for login authentication will be invalidated (destroyed) and a new session will be created once the user logged in successfully to the application and the new session will be used to store the required variables.

A session attribute IsAuthenticated set to “Y” on successful login to the application. A new random token (Cross-site request forgery) is also generated and the same is available in the session attribute.

The entire subsequent request within the session will be having the Authenticated and Cross-site request forgery tokens. Every request sent to the application from the browser is validated against the IsAuthenticated attribute and Cross-site request forgery token.

A hidden form is used to submit the logout request to the server, with the response resulting in a 302 redirect instead of a client-initiated redirect to the login page.

The session gets expire once the user logs off from the application or if idle for its maximum limit.

Cryptography used

PCI council defines Strong Cryptography as:

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher)

Encryption algorithm: The application leverages the AES encryption algorithm to store sensitive information into the properties file. This algorithm uses a 256 bit secret key for encryption and decryption which would be stored at property file.

Hashing algorithm: FLEXCUBE Universal Banking Solutions leverages the SHA-512 hashing algorithm for user password authentication. This algorithm generates a password digest for the user password by using the SALT (Random number generated using SHA1PRNG algorithm) and the iteration number available in the property file.

Session storage

FLEXCUBE Universal Banking Solutions application does not store Http Session objects.

A unique sequence number generates and stored in the current user table for the purpose of mapping server-side sessions with the entries in the current user table.

During session expiry (triggered by the container), the session listener provides the application with the sequence number of the session. The application makes checks as to whether the entry in the current user table contains the same sequence number. Only in such a case should the entry be deleted.

When authentication of credentials (involving an incorrect user ID) is unsuccessful, the user id should not be logged in the audit logs (database table). The following possible scenarios will be accounted for:

  • Session logging

    An unsuccessful login attempt is stored in the database with the terminal’s IP address and timestamp. Invalid and expired session IDs submitted to the application are categorized as authentication failures and, the same is logged in the database table.