OWSAP Top 10

[rainit2006]

OWASP Top10

AWS WAF -- Addressing OWASP Top 10 risks

https://aws.amazon.com/developer/application-security-performance/articles/addressing-owasp-top-10-risks/?nc1=h_ls

In addition to the custom rules that you configure in AWS WAF, it's recommended to use Amazon Managed Rules (AMR). (AMRs) is a set of rules inspired by OWASP top 10 and maintained by the AWS Threat Research Team. It's designed to to protect applications from the most common and high-severity threats while keeping a very low false positive rate across all customers. https://aws.amazon.com/jp/developer/application-security-performance/articles/addressing-owasp-top-10-risks/

[rainit2006]

The OWASP Top 10 (2021): What They Are and How to Test Them

https://www.bleepingcomputer.com/news/security/the-owasp-top-10-what-they-are-and-how-to-test-them/amp/

1. Broken Access Control Broken access control refers to placing insufficient restrictions on what authenticated users are allowed to do in an app. These flaws in the implementation of user permissions and rights allow users to perform actions or access data beyond their intended privileges. An example of broken access control is where a standard user simply manipulates a URL to access admin functionalities in the app without proper privileges.

To test a web app for broken access control security risks, consider the following strategies:

• Create multiple test accounts, each with different roles, and try to perform out-of-scope actions.
• Try to hijack or swap session tokens to see if one user can impersonate another or elevate their access.
• Try to modify parameters in the URL, hidden fields, or API requests to access objects not meant for standard users.

The most important preventative measure is to design and implement a robust role-based access control (RBAC) system. Ensure that each user role has the minimum necessary permissions (least privilege principle). Enforce these roles consistently throughout the application, both on the front end and back end.

2. Cryptographic Failures This security risk relates to the problem of the improper implementation or usage of cryptography, such as using outdated algorithms or incorrect key management configurations. Skilled hackers can trivially bypass weak or misconfigured cryptography to tamper with a web app or access sensitive data.

To test for this risk:

• Audit cryptographic practices for deprecated methods or algorithms.
• Test key management practices.
• Ensure the app uses secure, updated cryptographic libraries.

3. Injection Injection flaws in web applications allow attackers to craft malicious inputs that can trick an app into executing unintended commands. The most well-known type is SQL injection, where hackers manipulate a web app's database queries.

To test your web app for injection risks:

• Use static code analysis to identify potential vulnerabilities.
• Test the app dynamically with various injection payloads.
• Make sure the app validates and sanitizes user inputs.

4. Insecure Design Insecure design in web applications means architectural and foundational choices that inherently lack security considerations. These risky choices may render an app vulnerable to attack, regardless of individual code-level security measures.

The testing strategies for insecure design are more nuanced and include:

• Conducting threat modelling to understand the application's design, how data flows, and potential areas of weakness.
• Performing a comprehensive review of the application's architecture and assessing if security controls are built into the foundational layers, including authentication, authorization, and data validation.
• Ensuring that development, testing, and production environments are distinct and segregated.

5. Security Misconfiguration Security misconfiguration in web applications occurs when security settings and controls are improperly implemented, left at default values, or overlooked entirely. The risks of misconfigurations include unprotected files, directories, or databases that facilitate unintended access to valuable data or system capabilities.

Hurried deployments and a lack of security awareness are the primary causes of these risks.

To test your web applications for security misconfigurations:

• Regularly review and audit application, database, server, and network configurations manually.
• Use automated scanners and security tools that can detect common misconfigurations.
• Monitor error messages for sensitive information leakages, such as paths, server details, or database information.
• Ensure that no default credentials (username/password) are active in the app.

6. Vulnerable and Outdated Components Vulnerable and outdated components in web applications refer to third-party libraries, plugins, frameworks, and other software modules that have known security vulnerabilities but have not been updated or patched by the developers.

Web applications that rely on vulnerable components inherit their weaknesses, which provides a potential path for threat actors to exploit.

To test web applications for vulnerable/outdated components:

• Maintain an up-to-date inventory of all third-party components, libraries, plugins, and frameworks used in your application, including their versions and dependencies.
• Cross-reference your component inventory with vulnerability databases like the National Vulnerability Database (NVD) or CVE details.
• Use automated tools like OWASP's Dependency-Check to scan project dependencies and compare them against known vulnerability databases.

7. Identification and Authentication Failures Flawed authentication mechanisms, such as weak password policies, lack of multi-factor authentication, or improperly implemented session management enable attackers to impersonate legitimate users or bypass authentication checks altogether. These failures pave the way for unauthorized data access, identity theft, and potential takeover of user accounts.

To test for this OWASP Top 10 risk:

• Check for minimum password length/complexity requirements and try common or default passwords to see if the app accepts them.
• Check if sessions expire appropriately after inactivity or after a user logs out.
• Try to manipulate or replay cookies to see if you can impersonate a session.
• Try manipulating URLs, query parameters, or hidden fields to bypass authentication checks.

8. Software and Data Integrity Failures Software and data integrity failures occur when an application has an inability to ensure the authenticity and trustworthiness of data and application code. Integrity is about ensuring that data and code remain unaltered and genuine from their original state. Failures in software and data integrity introduce the risk of unauthorized modifications that lead to fraudulent transactions or malicious code being inserted into the application.

To test for these failures, consider:

• Tampering with transmitted data and observing if the application accepts the tampered data without any checks.
• Manipulating application files or libraries and seeing if the application detects unauthorized changes.
• Checking for the absence of checksums, digital signatures, or other verification mechanisms that would validate the integrity of data or software components.

9. Security Logging and Monitoring Failure This risk relates to the insufficient recording of activities in an app or the inability to proactively detect and respond to malicious actions in real time.

A lack of detailed logs or the absence of monitoring creates blind spots that prevent timely detection of unauthorized access, data breaches, or other malicious activities.

To assess if a web application has these risks:

• Regularly review logs to ensure that they capture relevant security events, such as failed login attempts, access to sensitive data, or system configuration changes.
• Ensure all critical components, such as databases, servers, and application endpoints, are monitored.
• Review configurations of monitoring tools to ensure they are set up to capture all relevant security events.

10. Server-Side Request Forgery (SSRF) Server-Side Request Forgery (SSRF) is a security vulnerability in which an attacker manipulates a web application into making unwanted requests to internal resources or third-party systems on behalf of the server.

This risk facilitates lateral movements in network infrastructures and enables attackers to interface with backend services or exfiltrate data.

To test for SSRF:

• Experiment with different URL schemes (like file://, dict://, sftp://, etc.) to attempt to access non-HTTP resources.
• Emulate web front-end requests to hit a back-end API, but modify the requests with http://localhost/admin or http://127.0.0.1/admin to see if any unexpected data is returned.
• Identify areas of implicit trust between hosts, such as local database servers trusting web servers.
• Look for detailed error messages that might indicate an SSRF vulnerability. For instance, if you enter an internal IP and the error reveals details about an internal resource, that's a potential sign of risk.

[rainit2006]

Using Burp to Test for the OWASP Top Ten (2017)

https://portswigger.net/support/using-burp-to-test-for-the-owasp-top-ten

1. Injection

Using Burp to Test For Injection Flaws

• active scan
• Manual testing

Injection Attack: Bypassing Authentication

• To bypass the authentication of a vulnerable login page (used ' or 1=1 -- in name filed)

Using Burp to Detect SQL-specific Parameter Manipulation Flaws Using Burp to Exploit SQL Injection Vulnerabilities: The UNION Operator Using Burp to Detect Blind SQL Injection Bugs Using Burp to Exploit Bind SQL Injection Bugs

2. Broken Authentication and Session Management

Using Burp to Brute Force a Login Page Using Burp to Test for Sensitive Data Exposure Issues

• active scan

Injection Attack: Bypassing Authentication

Using Burp to Hack Cookies and Manipulate Sessions

• In this example we have altered the value of the "uid" cookie to 1.Alter the value then click the "Go" button --> The response shows that by altering the "uid" cookie we have logged in to the application as "admin".

Using Burp to Test Token Generation

1. Using Burp Decoder to decode Session Tokens
2. Using Burp Sequencer to Test Session Tokens. Burp Sequencer will repeatedly issue the request and extract the relevant token from the application's responses.
3. Using Burp Intruder to Test Session Tokens. On "Payloads" tab, under the "Payload Sets" header, use the drop down menu to select either the "Character frobber" or "Bit flipper" payload type.

Using Burp to Test Session Token Handling

• If cookies are being used as the transmission mechanism for session tokens, verify whether the "secure" flag has been set, preventing them from ever being transmitted over unencrypted connections.

Forced Browsing

• In the example, the application allows a user to access another user's employee profile page (by changing userId or employeeId)

Using Burp to Test for Insecure Direct Object References

• A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. e.g. change id value in path /users/{id} to get other user's info.

3. Cross-Site Scripting (XSS)

Using Burp to Find Cross-Site Scripting Issues Using Burp to Manually Test for Reflected XSS

• "" Using Burp to Manually Test for Stored XSS Using Burp to Exploit XSS - Injecting in to Direct HTML Using Burp to Exploit XSS - Injecting in to Tag Attributes

Using Burp to Exploit XSS - Injecting in to Scriptable Contexts

4. Insecure Direct Object References

Using Burp to Test for Insecure Direct Object References

5. Security Misconfiguration

Using Burp to Test for Security Misconfiguration Issues

• use Spider to find more hidden path/files

6. Sensitive Data Exposure

Using Burp to Test for Sensitive Data Exposure Issues

7. Missing Function Level Access Control

Using Burp to test for Missing Function Level Access Control Using Burp's "Request in Browser" Function to Test for Access Control Issues

8. Cross-Site Request Forgery (CSRF)

Using Burp to Test for Cross-Site Request Forgery (CSRF)

• In the "Proxy" tab, right click on the raw request to bring up the context menu.Go to the "Engagement tools" options and click "Generate CSRF PoC".

video: https://www.youtube.com/watch?v=NtggatbBetU

9. Using Burp to Test for Components with Known Vulnerabilities

Using Burp to Test for Components with Known Vulnerabilities

10. Unvalidated Redirects and Forwards

Using Burp to Test for Open Redirections

[rainit2006]

XML external entity (XXE) injection

https://portswigger.net/web-security/xxe

SSRF

Server-side request forgery is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems. This could leak sensitive data, such as authorization credentials.

Example When a user views the stock status for an item, their browser makes the following request:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.

In this example, an attacker can modify the request to specify a URL local to the server:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

The server fetches the contents of the /admin URL and returns it to the user.

Instead of localhost, attacker can try to use other IP address: In the previous example, imagine there is an administrative interface at the back-end URL https://192.168.0.68/admin. An attacker can submit the following request to exploit the SSRF vulnerability, and access the administrative interface:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

[rainit2006]

Web cache deception

Burp Scanner automatically detects web cache deception vulnerabilities that are caused by path mapping discrepancies during audits. You can also use the Web Cache Deception Scanner BApp to detect misconfigured web caches.