Some Web Application Vulnerability Remediation (based on OWASP recommendation)

● Cross-site scripting (XSS): (A03:2021-Injection)

XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. XSS is serious and can lead to account impersonation, observing user behavior, loading external content, stealing sensitive data, and more.

·??????Use Framework Security: This should be used with caution. The framework could be outdated and vulnerable. The latest should be used and verified.

·??????Use Output Encoding: There are many different output encoding methods because browsers parse HTML, JS, URLs, and CSS differently. Using the wrong encoding method may introduce weaknesses or harm the functionality of your application

·??????HTML Sanitization: Sanitizing output using HTTPOnly cookie. This will strip dangerous HTML from a variable and return a safe string of HTML. OWASP recommends DOMPurify for HTML Sanitization.

·??????Use Safe Sinks: Refactor your code to remove references to unsafe sinks like innerHTML.

Note, that no single technique will solve XSS. Using the right combination of defensive techniques is necessary to prevent XSS. Other control includes:

·??????Validating input

·??????Use Content Security Policy

·??????Make sure the cookie setting is HTTOOnly, Secure, and expires as the session logout

·??????Set up an SSL certificate

·??????Use secure HTTPS for all web applications and firewalls.

● Cross-site request forgery (CSRF): (A03:2021-Injection)

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.

With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

The following principles should be followed to defend against CSRF:

·??????Check if your framework has built-in CSRF protection and use it

·??????If the framework does not have built-in CSRF protection add CSRF tokens to all state-changing requests (requests that cause actions on the site) and validate them on the backend

·??????For stateful software use the synchronizer token pattern

·??????For stateless software use double submit cookies

·??????Implement at least one mitigation from Defense in Depth Mitigations section

·??????Consider SameSite Cookie Attribute for session cookies but be careful to NOT set a cookie specifically for a domain as that would introduce a security vulnerability that all subdomains of that domain share the cookie. This is particularly an issue when a subdomain has a CNAME to domains not in your control.

·??????Consider implementing user interaction-based protection for highly sensitive operations

·??????Consider the use of custom request headers

·??????Consider verifying the origin with standard headers

·??????Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques

·??????The synchronizer token pattern is one of the most popular and recommended methods to mitigate CSRF. Do not use GET requests for state-changing operations.

·??????Use Built-In or Existing CSRF Implementations for CSRF Protection

§?Synchronizer Token Pattern: CSRF tokens should be:

a)??????Unique per-user session.

b)?????Secret

c)??????Unpredictable (large random value generated by a secure method).

§?CSRF tokens should not be transmitted using cookies.

§?Double Submit Cookie

§?Defense In Depth Techniques

·??????SameSite Cookie Attribute: SameSite is a cookie attribute (like HTTPOnly, Secure etc.) which aims to mitigate CSRF attacks.

·??????Verifying Origin with Standard Headers: There are two steps to this mitigation, both of which rely on examining an HTTP request header value.

????????????????????????????????I.???????????Determining the origin, the request is coming from (source origin). Can be done via Origin or Referrer headers.

??????????????????????????????II.???????????Determining the origin, the request is going to (target origin).

If you are behind a proxy, there are several options to consider.

Configure your application to simply know its target origin

Use the Host header value

Use the X-Forwarded-Host header value

§?Use of Custom Request Headers

§?User Interaction Based CSRF Defense

§?The session should be destroyed and a new one should be made to avoid session fixation attacks.

● SQL injection: (A03:2021-Injection)

A common malicious injection like SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) would compromise any information system.

An application is vulnerable to attack when:

·??????User-supplied data is not validated, filtered, or sanitized by the application.

·??????Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.

·??????Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.

·??????Hostile data is directly used or concatenated.

·??????The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.

The under list are suggested to control this vulnerability;

§?Preventing injection requires keeping data separate from commands and queries:

§?Source code review is the best method of detecting if applications are vulnerable to injections. Automated testing of all parameters, headers, URLs, cookies, JSON, SOAP, and XML data inputs is strongly encouraged. Organizations can include static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to identify introduced injection flaws before production deployment

§?Use a safe API, which avoids using the interpreter entirely, provides a parameterized interface or migrates to Object Relational Mapping Tools (ORMs).

§?Use positive server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.

§?For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.

§?Note: SQL structures such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.

§?Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

● Sensitive data exposure: (A08:2021-Software and Data Integrity Failures)

This risk is related to code and infrastructure that do not protect against integrity violations. The information system and data are loosely structured and vulnerable such that an attacker can see and modify them. Attackers can easily gain unauthorized access, exfiltrate data, inject ransomware attacks, or other malicious code, and the whole network becomes compromised.

The under list are suggested to control this vulnerability;

§?Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered.

§?Ensure libraries and dependencies, such as npm or Maven, are consuming trusted repositories. If you have a higher risk profile, consider hosting an internal known-good repository that's vetted.

§?Ensure that a software supply chain security tool, such as OWASP Dependency Check or OWASP CycloneDX, is used to verify that components do not contain known vulnerabilities

§?Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline.

§?Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.

§?Ensure that unsigned or unencrypted serialized data is not sent to untrusted clients without some form of integrity check or digital signature to detect tampering or replay of the serialized data

● Insufficient logging and monitoring: (A09:2021-Security Logging and Monitoring Failures)

There should be adequate visibility of what is going on in the network. Sensitive events such as logins failed logins, and high-value transactions, are to be monitored and logged.

In a case where there is insufficient logging detection and monitoring, it would be impossible to detect malicious activities and respond accordingly. Other examples of this issue are when;

§?Warnings and errors generate no, inadequate, or unclear log messages.

§?Logs of applications and APIs are not monitored for suspicious activity.

§?Logs are only stored locally.

§?Appropriate alerting thresholds and response escalation processes are not in place or effective.

§?Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do not trigger alerts.

§?The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

The under list are suggested to control this vulnerability:

Depending on the risk posture, the developer should;

·??????Ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.

·??????Ensure that logs are generated in a format that log management solutions can easily consume.

·??????Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.

·??????Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.

·??????DevSecOps teams should establish effective monitoring and alerting such that suspicious activities are detected and responded to quickly.

·??????Establish or adopt an incident response and recovery plan, such as the National Institute of Standards and Technology (NIST) 800-61r2 or later.

Reference:

1.??????https://owasp.org/www-project-top-ten/