OWASP Top 10 notes 1

folder_openWeb Security
commentNo Comments

     Overview of the risk

     Understanding the risk

     Common defenses

     The risk in the wild

Injection overview

—|—|—| Attack Vector | Security Weaknesses | Technical Impacts Exploitability Easy | Prevalence Common | Detectability Average | Impact Severe

Attacker –> Malicious Request(website) –> Modified Query (database) Attacker <– Data exfiltration(website) <– Query output(database)

Understanding SQL Injection

http://www.mysite.com/Widget?Id=1 or 1=1

SELECT * FROM Widget where ID = 1 or 1 = 1 (Always true)

1 (untrusted data)

Common Defences Against Injection Attacks

  1. Whitelist Untrusted Data:

    • What input do we trust?
    • Does it adhere to expected patterns?
  2. Parameterize SQL statements:

    • Separate the query from the input data
    • Type cast each parameter
  3. Fine tune DB permissions:

    • Segment accounts for admin and public
    • Apply the “principle of least privilege”

Broken Authentication and Session Management

Understanding Hijacking

  • Exploit an XSS risk or Retrieve it from the victim’s PC or Sniff it over an insecure connection => Auth Cookie Theft

  • Copy and paste a URL with it or Retrieve it from a long or Send it via an insecure email => Session ID theft

  • Brute force the login or Exploit password reset or Discover weak credentials => Account management attack

Common Defences Against Broken Authentication

  1. Protect the cookies:

    • Use the HttpOnly flag
    • Make sure they’re flagged as “Secure”
  2. Decrease the window of risk:

    • Expire sessions quickly
    • Re-challenge the user on key actions
  3. Harden the account management:

    • Allow(and encourage) strong passwords
    • Implement login rate limiting and lockouts


Attacker –> URL with XSS payload to USER –> User clicks URL goto webiste and responds XSS payload “reflected” back to User (in his browser) and exfilterate client data to Attacker. (cookie, auth cookie etc). (reflected XSS).

Atacker inject XSS injection to Database and persistence.

XSS payload “persisted” to Website and exfilterate USER data to attacker.

Understanding XSS

http://www.mysite.com/Search?q=Lager (Untrusted)

You searched for Larger


Common defences Against XSS Attacks

  1. Whitelist untrusted data:

    • What input do we trust ?
    • Does it adhere to expected patterns?
  2. Always encode output:

    • Never simply reflect untrusted data
    • This applies to data in your own DB too
  3. Encode for context:

    • HTML/ attributes / JavaScript / CSS
    • Wrong encoding in wrong context is useless

Insecure Direct Object References

Attacker –> Change ID in the URL (to Website) –> Changes requested record –> Database

Database –> Record sent to website –> Attacker

Understanding Direct Object References

http://mybank.com/Balance?AccountID=293843 (Untrusted)

http://mybank.com/Balance?AccountID=498274 (Untrusted)

http://mybank.com/Balance?AccountID=984353 (Untrusted)

Common Defences Against Direct References

  1. Implement access controls:

    • Be explicit about who can access resources
    • Expect the rules to be tested
  2. Use indirect maps:

    • Don’t expose internal keys externally
    • Map them to temporary ones
  3. Avoid predictable keys:

    • Incrementing integers are enumerable
    • Natural keys are discoverable

Security Misconfiguration Overview

Attacker –> Insecure resource –> Website

Website –> Exposure of a “gateway risk” –> Attacker

Understanding Security Misconfiguration

  • Is any of your software out of data? This includes the OS, Web/App Server, DBMS, applications, and all code libraries

  • Are any unnecessary features enabled or installed (e.g. ports, services, pages, accounts, privileges)?

  • Are defaults accounts and their passwords still enabled and unchanged?

  • Does your error handling reveal stack traces or other overly informative error messages to users ?

  • Are the security settings in your development frameworks and libraries not set to secure values ?

Commong Defences Against Security Misconfiguration

  1. Always harden the install:

    • Turn off features that aren’t needed
    • Apply the “principle of least privilege”
  2. Tune the app security config:

    • Ensure it’s production-ready
    • Defaults are often not right
  3. Ensure packages are up to date:

    • Be conscious of 3rd party tool risks
    • Have a strategy to monitor and update

Sensitive Data Exposure

User –> Login over HTTP –> Website (not secure) – Attacker can sniff the password and access the data

Understanding Sensitive Data Exposure

Login not loaded over HTTPS or Mixed Mode or Cookies not sent securely => Insufficient use of SSL

Incorrect password storage or Weak algorithem chosen or Poor protection of keys => Bad crypto

Browser auto-complete or Leaked via logs or Diclosure via URL => Other exposure risks

Common Defences Against Sensitive Data Exposure

  1. Minimise sensitive data collection:

    • You can’t lose what you don’t have!
    • Reduce the window of storage
  2. Apply HTTPS everywhere:

    • It’s too easy to “insufficiently” implement
    • Start with it everywhere – it’s easy!
  3. Use strong crypto storage:

    • Hashing algorithms designed for passwords
    • Be very careful with key management

Missing Function Level Access Control

User(admin) –> Authenticated request–> Website Website –> Link to admin in nav –> User (admin)

Attacker –> Request admin page –> Website Website –> Admin page returned –> Attacker

Understanding Missing Function level Access Control

  • Does the UI show navigation to unauthorised functions ?

  • Are server side authentication or authorization checks missing ?

  • Are server side done that solely rely on information provided

  • Are system or diagnostic resources accessible without proper authorisation ?

  • Will “forced browsing” disclose unsecured resources ?

Common Defences Against Missing Function Level Access Control

  1. Define a clear authorisation model:

    • Define centrally and consistently
    • Use roles and apply membership
  2. Check for forced browsing:

    • Check for default framework resources
    • Automated scanners are excellent for this
  3. Always test unprivileged roles:

    • Capture and repay privileged requests
    • Include POST requests and async calls

Cross Site Request Forgery CSRF

Attacker –> Shares a malicious link to –> User –> site loaded to Attacker’s website

Attacker’s website –> Malicious request embedded to User –> User Authenticated request send to Target website

Understanding CSRF

User –> Authentticated request to transfer money online –> Website

HTTP POST https://mybank.com/transfer 
Auth-cookie: 87e090ace8...

TargetAccNum: 8781648823
Amount: 1000000.00 

Attacker forges request 

Common Defences Against CSRF

  1. Employ anti-forgery tokens:

    • CSRF is exploited by predictable patterns
    • Tokens add randomness to the request
  2. Validate the referrer:

    • Valid requests don’t originate externally
    • The referrer is in each request header
  3. Other defences:

    • Native browser defences
    • Fraud detection patterns

Using Components with Known Vulnerabilities

Attacker –> Exploitation of vulnerable component –> website

  • Circumvent access control
  • Local file inclusion
  • SQL injection, XSS or CSRF
  • Vulnerable to brute force login

Understanding Components with Known Vulnerabilities

Attacker –> Request for page using a potentially vulnerable component –> website

website –> Disclosure of the component version –> Attacker

Attacker –> Search for known vulnerabilities –> Internet

Internet –> Exploitable risks discovered –> Attacker

Attacker –> Attack –> Website

Common Defences Against Components with Known Vulnerabilities

  1. Identify components and versions:

    • Components are often used haphazardly
    • Keep track of components and versions
  2. Components should be monitored:

    • Keep abreast of project updates
    • Monitor CVEs impacting the components
  3. Keep components updated:

    • Use the framework’s package management
    • Regularly monitor new releases

Unvalidated Redirects and Forwards

Attacker sends a URL with redirect payload and USER clicks the link. the link takes the user to a valid website and that redirects to a malicious website. That malicious website sends Malicious content returned to the User.

Understanding Unvalidated Redirects and Forwards

“Here’s a piece of text on a website with a link to an external website.”

external website -> /redirect/?url=http://externalwebsite.com

(usually used to log the event and pass some parameter)

However, what attacker does:


Common defences Against Unvalidated Redirects and Forwards

  1. Use a URL whitelist:

    • What URLs are allowed to be redirect to?
    • Abort if the URL is not allowed
  2. Use indirect references:

    • Pass an ID to the redirect, not a URL
    • Resolve the URL from a reference map
  3. Check the referrer:

    • Did the redirect originate from the site?
    • May need to whitelist multiple sites
Tags: ,

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed