SaFi Bank Space : Secure Coding Guideline

 Overview

Most of the software security flaws were found at code level implementations due to the poor business logic design or different approach in development.

OWASP Secure Coding Practices defines the difference between approach by development team and someone attacking an application.

A development team typically approaches an application based on what it is intended to do. In other words, they are designing an application to perform specific tasks based on documented functional requirements and use cases.

An attacker, on the other hand, is more interested in what an application can be made to do and operates on the principle that “any action not specifically denied, is allowed”.

Software security flaws can be introduced at any stage of the software development lifecycle, including:

• Not identifying security requirements up front.

• Business logic designs that have logic errors.

• Using poor coding practices that introduce technical vulnerabilities.

• Deploying the software improperly.

• Introducing flaws during maintenance or updating.

 Reviewing process with the checklists

The review process is simply cross-checking the implemented code with the checklist. The checklist were categorized per critical implementation checkpoints. Each of checkpoints were listed below:

General Coding Practices

• Use tested and approved managed code rather than creating new unmanaged code for common tasks.

• Utilize task specific built-in APIs to conduct operating system tasks. Do not allow the application to issue commands directly to the Operating System, especially through the use of application initiated command shells.

• Use checksums or hashes to verify the integrity of interpreted code, libraries, executables, and configuration files.

• Utilize locking to prevent multiple simultaneous requests or use a synchronization mechanism to prevent race conditions.

• Protect shared variables and resources from inappropriate concurrent access.

• Explicitly initialize all your variables and other data stores, either during declaration or just before the

  first usage.

• In cases where the application must run with elevated privileges, raise privileges as late as possible, and drop them as soon as possible.

• Avoid calculation errors by understanding your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.

• Do not pass user supplied data to any dynamic execution function.

• Restrict users from generating new code or altering existing code.

• Review all secondary applications, third party code and libraries to determine business necessity and validate safe functionality, as these can introduce new vulnerabilities.

• Implement safe updating. If the application will utilize automatic updates, then use cryptographic signatures for your code and ensure your download clients verify those signatures. Use encrypted channels to transfer the code from the host server.

Input Validation

• Define data specification for all sources of inputs.

• Implement data validation techniques in all systems and data sources wether trusted or untrusted.

• Implement a centralized input validation mechanism for the application.

• Validate all client provided data before processing.

• Validate data from redirects.

• Validate all input against a “white" list of allowed characters, whenever possible.

• If any potentially hazardous characters must be allowed as input, be sure that you implement additional controls like output encoding, secure task specific APIs and accounting for the utilization of that data throughout the application . Examples of common hazardous characters include:
  < > " ' % ( ) & + \ \' \”.

• All validation failures should result in input rejection.

Output Encoding

• Standardize encoding specification of all system or data source output.

• Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP.

Authentication and Password Management

• Require authentication for all pages and resources, except those specifically intended to be public.

• Establish and utilize standard, tested, authentication services whenever possible (e.g., OAuth2, OpenID Connect, etc.)

• Use a centralized implementation for all authentication controls, including libraries that call external authentication services. (e.g., keycloak, Okta, Azure AD, etc.)

• Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control.

• All authentication controls must be enforced on a trusted system. (e.g., Core banking system, api gateways, etc.)

• All authentication controls should be transmitted only on encrypted connection (e.g., HTTPS, TLS enabled TCP or UDP).

• Set the “secure” attribute for cookies transmitted over a TLS connection

• Set cookies with the HttpOnly attribute, unless you specifically require client-side scripts within your application to read or set a cookie's value.

• All authentication controls should fail securely.

• All administrative and account management functions must be at least as secure as the primary authentication mechanism.

• Password hashing must be implemented on a trusted system.

• Validate the authentication data only on completion of all data input, especially for sequential authentication implementations.

• Authentication failure responses should not indicate which part of the authentication data was incorrect. For example, instead of "Invalid username" or "Invalid password", just use "Invalid username and/or password" for both. Error responses must be truly identical in both display and source code.

• Utilize authentication for connections to external systems (e.g., public applications like mobile app, web based banking application, etc.) that involve sensitive information or functions.

• Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system (e.g., The server). The source code is NOT a secure location.

• Use only HTTP POST requests to transmit authentication credentials.

• Only send non-temporary passwords over an encrypted connection or as encrypted data, such as in an encrypted email. Temporary passwords associated with email resets may be an exception.

• Enforce password complexity requirements established by policy or regulation.

• Enforce password length requirements established by policy or regulation. Eight characters is commonly used, but 16 is better or consider the use of multi-word pass phrases.

Minimum: 8, Maximum: 72

• Password entry should be obscured on the user’s screen. (e.g., on web forms use the input type “password")

• Enforce account disabling after an established number of invalid login attempts (e.g., five attempts is common). The account must be disabled for a period of time sufficient to discourage brute force guessing of credentials, but not so long as to allow for a denial-of-service attack to be performed.

• Password reset and changing operations require the same level of controls as account creation and authentication.

• Password reset questions should support sufficiently random answers. (e.g., “favorite book” is a bad question because “The Bible” is a very common answer)

• If using email based resets, only send email to a pre-registered address with a temporary link/password.

• Temporary passwords and links should have a short expiration time.

• Enforce the changing of temporary passwords on the next use.

• Notify users when a password reset occurs.

• Prevent password re-use.

• Passwords should be at least one day old before they can be changed, to prevent attacks on password re-use.

• Enforce password changes based on requirements established in policy or regulation.

• Disable “remember me" functionality for password fields.

• The last use (successful or unsuccessful) of a user account should be reported to the user at their next successful login.

• Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when user IDs can be harvested or guessed.

• Change all vendor-supplied default passwords and userIDs or disable the associated accounts.

• Re-authenticate users prior to performing critical operations. (e.g., password change, fund transfer, etc.)

• Use Multi-Factor Authentication for highly sensitive or high value transactional accounts.

• If using third party code for authentication, inspect the code carefully to ensure it is not affected by any malicious code.

Authentication and Password Management

• Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid.

• Session identifier creation must always be done on a trusted system.

• Session management controls should use well vetted algorithms that ensure sufficiently random session identifiers.

• Logout functionality should fully terminate the associated session or connection.

• Logout functionality should be available from all pages protected by authorization.

• Establish a session inactivity timeout that is as short as possible, based on balancing risk and business functional requirements. In most cases it should be no more than several hours.

• Disallow persistent logins and enforce periodic session terminations, even when the session is active. Especially for applications supporting rich network connections or connecting to critical systems. Termination times should support business requirements and the user should receive sufficient notification to mitigate negative impacts

• If a session was established before login, close that session and establish a new session after a successful login.

• Generate a new session identifier on any re-authentication.

• Do not allow concurrent logins with the same userID.

• Do not expose session identifiers in URLs, error messages or logs. Session identifiers should only be located in the HTTP cookie header.

• Protect server side session data from unauthorized access, by other users of the server, by implementing appropriate access controls on the server.

• Generate a new session identifier and deactivate the old one periodically.

• Supplement standard session management for sensitive server-side operations, like account management, by utilizing per-session strong random tokens or parameters. This method can be used to prevent Cross Site Request Forgery attacks.

• Supplement standard session management for highly sensitive or critical operations by utilizing per- request, as opposed to per-session, strong random tokens or parameters.

Access Control

• Use only trusted system objects for making access authorization decisions.

• Use a single site-wide component to check access authorization. This includes libraries that call external authorization services.

• Access controls should fail securely.

• Deny all access if the application cannot access its security configuration information.

• Enforce authorization controls on every request, including those made by server side scripts, "includes" and requests from rich client-side technologies like AJAX and Flash.

• Segregate privileged logic from other application code.

• Restrict access to files or other resources, including those outside the application’s direct control, to only authorized users.

• Restrict access to protected URLs to only authorized users.

• Restrict access to protected functions to only authorized users.

• Restrict direct object references to only authorized users.

• Restrict access to services to only authorized users.

• Restrict access to application data to only authorized users.

• Restrict access to user and data attributes and policy information used by access controls.

• Restrict access security-relevant configuration information to only authorized users.

• Server side implementation and presentation layer representations of access control rules must match.

• If state data must be stored on the client, use encryption and integrity checking on the server side to catch state tampering.

• Enforce application logic flows to comply with business rules.

• Limit the number of transactions a single user or device can perform in a given period of time. The transactions/time should be above the actual business requirement, but low enough to deter automated attacks.

• Use the “referrer” header as a supplemental check only, it should never be the sole authorization check, as it is can be spoofed.

• If long authenticated sessions are allowed, periodically re-validate a user’s authorization to ensure that their privileges have not changed and if they have, log the user out and force them to re-authenticate

• Implement account auditing and enforce the disabling of unused accounts. (e.g., After no more than 30 days from the expiration of an account’s password.)

• The application must support disabling of accounts and terminating sessions when authorization ceases. (e.g., Changes to role, employment status, business process, etc.)

• Service accounts or accounts supporting connections to or from external systems should have the least privilege possible.

• Create an Access Control Policy to document an application’s business rules, datatypes and access authorization criteria and/or processes so that access can be properly provisioned and controlled. This includes identifying access requirements for both the data and system resources.

Error Handling and Logging

• Do not disclose sensitive information in error responses, including system details, session identifiers or account information.

• Use error handlers that do not display debugging or stack trace information.

• Implement generic error messages and use custom error pages.

• The application should handle application errors and not rely on the server configuration.

• Properly free allocated memory when error conditions occur

• Error handling logic associated with security controls should deny access by default

• Ensure logs contain important log event data.

• Ensure log entries that include un-trusted data will not execute as code in the intended log viewing interface or software.

• Restrict access to logs to only authorized individuals.

• Utilize a master routine for all logging operations.

• Do not store sensitive information in logs, including unnecessary system details, session identifiers or passwords.

• Ensure that a mechanism exists to conduct log analysis.

• Log all input validation failures.

• Log all authentication attempts, especially failures.

• Log all access control failures.

• Log all apparent tampering events, including unexpected changes to state data.

• Log attempts to connect with invalid or expired session tokens.

• Log all system exceptions.

• Log all administrative functions, including changes to the security configuration settings.

• Log all backend TLS connection failures.

• Log cryptographic module failures.

• Use a cryptographic hash function to validate log entry integrity.

Data Protection

• Implement least privilege, restrict users to only the functionality, data and system information that is required to perform their tasks.

• Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files a soon as they are no longer required.

• Encrypt highly sensitive stored information, like authentication verification data, even on the server side.

• Protect server-side source-code from being downloaded by a user

• Do not store passwords, connection strings or other sensitive information in cleartext or in any non-cryptographically secure manner on the client side.

• Remove comments in user accessible production code that may reveal back end system or other sensitive information.

• Remove unnecessary application and system documentation as this can reveal useful information to attackers.

• Do not include sensitive information in HTTP GET request parameters.

• Disable auto complete features on forms expected to contain sensitive information, including authentication.

• The application should support the removal of sensitive data when that data is no longer required. (e.g. personal information or certain financial data)