ONFA - Pentesting

The "Log out" feature does not handle session termination properly. All the cookies involved in the user's session remain valid even after the user has logged out of the application. The session cookies are: - `PHPSESSID` - `onfa_username` - `onfa_keypass` Additionally, the `onfa_securkey` cookie is not deleted from the user's browser. This cookie is a combination of the `onfa_username` and `onfa_keypass` cookies encoded in hexadecimal. For example: - `onfa_securkey` cookie: `70656e74657374314063657274696b2e6f72677c7c7c6262383336303261363664303865386364616662386632376137376534613865` - Decoded `onfa_securkey` cookie: `pentest1@certik.org|||bb83602a66d08e8cdafb8f27a77e4a8e` - `onfa_username` cookie: `pentest1@certik.org` - `onfa_keypass` cookie: `bb83602a66d08e8cdafb8f27a77e4a8e`

The web application provides an IP whitelist feature that restricts user authentication with credentials to specified IP addresses. If a user attempts to authenticate from an IP not on the whitelist, they receive an email with a link for authentication. However, this security mechanism can be bypassed by adding the `X-Forwarded-For` header, allowing an attacker to spoof their IP address and authenticate using an IP included in the whitelist.

An authentication mechanism is only as strong as its credentials. For this reason, it is important to require users to have strong passwords. Lack of password complexity significantly reduces the search space when trying to guess the user's passwords, making brute-force attacks easier. The currently implemented password policy is permissive regarding the requirements related to the password length and complexity, as it allows any 8-character password.

The web application stores the password hash directly within the `onfa_keypass` and `onfa_securkey` cookies. This design allows malicious actors to access these hashes if they compromise the browser, facilitating password-cracking attacks.

iOS application does not implement certificate pinning. Certificate pinning is the act of associating a host with its expected certificate within the application. When the application connects to the host, the stored certificate is compared to the certificate held by the remote host. If the two certificates do not match, the request is dropped. Currently, the application only verifies that the server presents a TLS certificate that is trusted by the iOS trust store, not validating that the TLS certificate is in fact the one known to be deployed on the servers.

HTTP headers are well known and their implementation can make your application more versatile and secure. Modern browsers support many HTTP headers that can improve web application security to protect against clickjacking, cross-site scripting, and other common attacks. The important ones are missing and should be added to the response headers. They are listed below. - `Content-Security-Policy`: Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. - `X-Frame-Options`: X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. - `X-Content-Type-Options`: X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared.

The remote service accepts connections encrypted using TLS 1.0. TLS 1.0 has a number of cryptographic design flaws. Modern implementations of TLS 1.0 mitigate these problems, but newer versions of TLS like 1.2 and 1.3 are designed against these flaws and should be used whenever possible. As of March 31, 2020, Endpoints that aren’t enabled for TLS 1.2 and higher will no longer function properly with major web browsers and major vendors. PCI DSS v3.2 requires that TLS 1.0 be disabled entirely by June 30, 2018, except for POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits.