Common Vulnerabilities and Recommendations Part-3

Cross-Site Request Forgery (CSRF):

Cross-Site Request Forgery (CSRF) vulnerability occurs when an attack forces an authenticated end user to execute unwanted requests in a web application that they do not intend to do. 

This permits the attacker to send a malicious script to trick users by using social engineering techniques such as phishing emails, fake alerts, or chat links and perform unauthorized actions in the application when the user is already logged in.

The security risk for the successful CSRF attack affects in several ways such as modification of database contents, state changes like changing email address or passwords, transferring funds and if the victim has a privileged role, will compromise the entire web application.

Recommendations:

• Include CSRF tokens within relevant requests.
• Implementing Synchronizer Token Pattern (STP) technique in which token for each request is embedded in all HTML forms and confirmed on the server side.
• Never permits any changes to data via GET requests.
• Use the “double-submitted cookie” method.
• Limiting the lifetime of session cookies.

Insecure Cryptographic Storage (ICS):

Insecure Cryptographic Storage (ICS) vulnerability occurs when in an application, sensitive data is not encrypted or not stored securely. The attacker exploits this flaw and can perform many attacks such as SQL injection, XSS, confidential information exposed, etc.

This vulnerability basically arises due to poorly designed older cryptographic algorithms, improper key management and storage, insecure cryptography, inappropriate ciphers, encryption of wrong data, unencrypted data in the database, developers implementing their own cryptography. These flaws can lead to exploit sensitive information to attackers.

The attacker is so sophisticated that they just don’t need to break the cryptographic algorithm to gain unauthorized access to the application. But finding the registry, databases, and temporary files stored in insecure manner is enough for them to exploit and also can access data from insecure channels that can decrypt.

Recommendations:

• Locate and identify all the sensitive data in the application and encrypt it with a strong algorithm.
• Minimize the sensitive data storage in the application and remove the data which is not necessary.
• Ensure that sensitive data is authorized to limited people and can be accessed in assigned areas only.
• Patch the application with all the common vulnerabilities and secure it from risk.
• Ensure that sensitive memory location can be overwritten and data should be deleted immediately if it is no longer needed.

Race Condition:

Race Condition vulnerability occurs when the system executes certain tasks in a specific sequence is forced to implement two or more operations at the same parallel time. To execute these operations, there is some period of time gap to initiate a service. The attacker utilizes this moment for the exploitation and can enforce the system to execute unauthorized action instead of a normal process.

The attack that is able to run multi execution threads simultaneously can generate flaws that doesn’t exist in single threaded programs and are capable of running multiple actions at the same time.

The security risk of this vulnerability leads to leakage of sensitive information, complete access to the system, manipulating API calls, denial of service, meltdown attacks, etc. This vulnerability is also called Time of Check/Time of User attacks.

Recommendations:

• Implementation of proper Thread Synchronization in critical sections i.e. to execute one thread at a time.
• Avoiding shared states that ensure shared resources are part of a system, atomic functioning are set up that execute independently of other processes.
• Developers should utilize dynamic and static analysis tools to detect race conditions.
• Critical section should be executed as an atomic instruction, that will ensure that once a single thread is executed, no other threads will execute until the previous thread is exited.

Insecure Cookie:

Insecure Cookie security vulnerability occurs when a secure attribute is not set for sensitive cookies in HTTP sessions. If assigned authentication cookies are not set as secure, web browsers are free to send authentication cookies over an insecure HTTP channel.

The attacker utilizes this vulnerability and can access sensitive information stored in those insecure cookies, even if the web application uses an SSL certificate.

This vulnerability basically occurs when a programmer fails to assign authentication cookies as secure. The attacker can cache all DNS responses and observe hostnames that use port 443 and make connections with one of the domain names stored there. This flaw will allow an attacker to inject malicious scripts from insecure portions of the protected website and force browsers to send authentication cookies.

Recommendations:

• Always set the secure attribute when the cookie should send via HTTPS only.
• If Cookies are used to transmit session tokens, then the application should implement its own session handling mechanism and tokens should never be transmitted in unencrypted communications.
• Set the HttpOnly flag on a cookie that restricts reading and returns empty string while accessing JavaScript, thus preventing XSS attack.