Techie Ranch

OWASP Top 10 Vulnerabilities

·

Open Web Application Security Project (OWASP)

Founded in 2001 the Open Web Application Security Project is a non-profit global organization that strives to promote application security across the web. One of OWASP’s core principles is that all of their materials will be freely available and easily accessible making it possible for anyone to improve their own web application security.

This blog post will examine the top 10 security vulnerabilities as stated by OWASP and measures that can be taken to mitigate the risks.

  1. Injection
  2. Broken Authentication
  3. Sensitive Data Exposer
  4. XML External Entities (XXE)
  5. Broken Access Control
  6. Security Misconfiguration
  7. Cross Site Scripting (XSS)
  8. Insecure Deserialisation
  9. Using Components with Known Vulnerabilities
  10. Insufficient Logging & Monitoring

1. Injection:

Summary: This attack covers the injection of malicious code into an interface, this could be via web forms or API requests but also covers injection into things such as SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers and SMTP headers.

String query = "SELECT * FROM accounts WHERE id='" + request.getParameter("id") + "'";

Prevention:

  1. Use existing frameworks/libraries to handle all user input
  2. Escape and validate all user input at first point of entry
  3. Design validation both in the frontend as well as the backend
  4. Enforce the principle of least privilege across the system
  5. Ensure all SQL queries are parameterized

2. Broken Authentication:

Summary: Attack on the login mechanism and authentication of a system. Covers areas such as session management, brute force login, weak passwords and password management such as password reset flows.

Prevention:

  1. Enforce strict password requirements
  2. Set-up alerting & blocking mechanisms for brute force attacks
  3. Implement a robust password reset flow
  4. Consider Multi Factor Authentication (MFA)
  5. Enforce default passwords are changed for software & well as hardware
  6. Use a secure session manager that generates random, time-limited session IDs and never include session IDs in URLs.

3. Sensitive Data Exposer

Summary: Sensitive data, such as Personally Identifiable Information (PII); is exposed either in storage or in transit. The data might not have been encrypted hence accessible to attackers.

Prevention:

  1. Encrypt sensitive data at rest & on transit (SSL)
  2. Classify & identify sensitive data & apply the appropriate security controls
  3. Understands the current regulation especially when dealing with PII
  4. Disable caching for sensitive data where possible
  5. Never store sensitive data longer than needed; think GDPR
  6. Consider using specialised 3rd part suppliers such as AWS Cognito, Active directory, Google Identity Platform for user information or external payment gateways for card payments.

4. XML External Entities (XXE)

Summary: Outdated XML parsers not parsing external XML content correctly, leaving potentially a backdoor into systems. Alternatively, the external XML could contain cyclic references to itself, causing a denial-of-service attack.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>

Prevention:

  1. Ensure the latest XML parsers are used and the system responsible for XML parsing only has the permissions it needs to work legitimately
  2. Validate XML input before parsing
  3. Consider disabling XML External Entity (XXE) on the parsers
  4. Consider replacing XML for JSON if possible

5. Broken Access Control

Summary: Encompasses the different users having the access control to the resources with permitted access levels. Access controls should limit visitor access to only those pages or sections needed by that type of user even if the user somehow knows a URL or ID, they should be blocked if they don’t have the authorised level for the resource.

Prevention:

  1. Adopt a least privileged approach
  2. Delete accounts that are no longer needed or active
  3. Is CORS correctly enabled
  4. Can existing frameworks be utilised
  5. Set-up auditing and logging and utilise detection tools such as Dynamic Application Security (DAS) and SAS (Static Application Security)

6. Security Misconfiguration

Summary: Generally linked to 3rd party tooling misconfigured with loose access control or default configuration as opposed to the most appropriate configuration for an environment. Example would be servers running on default ports with default username/password. Also, some unnecessary features may be enabled by default, which will increase overhead and open more vulnerabilities.

Prevention:

  1. Ensure all necessary defaults are changed
  2. Take the time to understand the vulnerabilities of 3rd part application before implementation
  3. Treat configuration as you would with all source code, (i.e., version control, code review etc)
  4. Ensure platforms are up to date & include necessary patches
  5. Use automated process to validate the recommended settings are enforced

7. Cross Site Scripting (XSS)

Summary: This is client-side code injection and comes in three different forms: Reflected, Stored and DOM. An attacker creates some code which is pushed it onto your website, which your website then serves up. Commonly this comes from JavaScript code in HTML, for example added in a comment section of a website. The malicious code is effectively trusted as it’s served by the web server.

Prevention:

  1. Escaping inputs
  2. Using approved frameworks for user input validation
  3. Using Content Security Policy (CSP)
  4. Review of all forms, comments, text editors and search terms that are echoed backed to the user
  5. Attempt to push users to use newer browsers

8. Insecure Deserialisation

Summary: Serialisation is turning an object into a stream of bytes, for transporting or saving it to a persistent store. Deserialisation is taking the stream of bytes and turning it back into objects. If the data being deserialised isn’t being checked or sanitised, this could introduce bad data into the application.

Prevention:

  1. Implement digital signatures to ensure the integrity of serialized object
  2. Initiate type constraints during deserialization so that application code detects unexpected classes
  3. Use approved libraries for serialising and deserialising data
  4. If processing data from 3rd party treat this like any other user input

9. Using Components with Known Vulnerabilities

Summary: Most applications are made up of inhouse code and 3rd party modules and components. Some of these 3rd party components might have known vulnerabilities; these maybe newly added components or existing historical components. You can check for vulnerabilities at the CVE database.

Prevention:

1. Consider automating patches and updates when possible

2. Prepare a process for urgent patches

3. Audit and examine legacy modules

4. Download software only from official channels

10. Insufficient Logging & Monitoring

Summary: Application and software should use appropriate logging that is continuous and relevant. At a minimum you should be logging application errors, warnings and failed login attempts. For a full list on what should be logged see OWASP’s logging cheat-sheet.

Prevention:

1. Examine if the current logging is sufficient and is relevant to content

2. Determine if logs are being monitored & alerts are firing for suspicious activity

3. Consider a centralised logging & monitoring service

References

https://snyk.io/learn/owasp-top-10-vulnerabilities/

https://www.immuniweb.com/resources/owasp-top-ten/

https://www.cloudflare.com/en-gb/learning/security/threats/owasp-top-10/

OWASP

Follow me on: YouTube, LinkedIn, Twitter, BlueSky, Mastodon

Leave a comment

Latest episodes