Web Application Security Testing

WEB APPLICATION SECURITY TESTING – 8. ATTACKING ACCESS CONTROLS

This notes is for learning/educational purpose only. Use it at your own risks. 

Authentication and Session management ensure that you know who is using the application. Similarly, Access Controls is defense mechanism which limits what actions are possible for authenticated users. It must be tested for every request and operation.

COMMON VULNERABILITIES

Access controls can be divided into three broad categories – Vertical, Horizontal and Context-Dependent.

  • Vertical Privilege Escalation – allow user to access a different part of app’s functionality. Like, escalating from user to administrator.
  • Horizontal Privilege Escalation – allow user to access a wider range of resources of same type. Such as reading another user’s email.
  • Context-Dependent (Business Logic Exploitation) – User can do things that should not be possible in context. Like, performing tasks out of order. Or, bypassing payment step when checking out.

Completely Unprotected Functionality

  • Functionality can be accessed by anyone who knows the URL
  • OWASP refers this as “Unsecured Direct Object Access”, also known as “Security through Obscurity”
  • Inspecting client side code may reveal privileged URLs

Identifier-Based Functions

  • Identifier for a document passed to server in parameter
  • Access controls may be broken so everyone with URL can view the document. This often happens when developers find it too difficult to share session-based security model between servers using different technologies.
  • Document identifiers might be predictable.
  • URLs are not treated as secrets – often visible in logs or elsewhere in app

Multistage Functions

  • App may enforce access control in early step but not test it again in later step.
  • Attacker can skip steps and escalate privileges

Static Files

  • Anyone with direct link to file can view and/or download the file if app-level code is executed for access.

Platform Misconfiguration

  • Access to specified URL paths are restricted.
  • Platform level configuration allow or deny access based on following – HTTP request method, URL path, User role

Verb Tampering:

  • Access control rule may apply only to POST method. Using GET/HEAD may perform admin-level tasks.
  • Unrecognized HTTP methods may default to GET

Insecure Access Control Methods

  • Parameter based access control:
    • Privilege level in hidden form field, cookie or query string parameter.
    • Attacker can just add parameter to gain privileges
  • Referer based access control:
    • HTTP referer header grants access
    • User can modify that field to gain privilege
  • Location based access control:
    • Often uses geolocation of user’s IP address
    • Using web proxy based in required location might bypass this
    • Using VPN that terminates in required location might bypass this
    • Using mobile device that supports data roaming might bypass this
    • Direct manipulation of client-side mechanisms for geolocation can bypass this

ATTACKING ACCESS CONTROLS

Testing With Different User Accounts

  • Map contents of app using two user accounts and compare them

Testing Direct Access to Methods

  • Might be able to guess other methods from the ones you see
  • Test them to see if access is properly limited

Testing Controls Over Static Resources

  • Walk through app while logged in as admin
  • Note URLs of high privilege resources
  • Login as low privilege user
  • Try to access those URLs found earlier
  • Try to guess other sensitive URLs from the patterns of URLs you have found

Testing Restrictions on HTTP Methods

  • Login as admin and find sensitive requests
  • Try other methods, POST, GET, HEAD, invalid
  • Test with low privileged account

SECURING ACCESS CONTROLS

  • Do not rely on user’s ignorance of URLs or identifiers
  • Do not trust any user-supplied parameters like admin=True
  • Do not assume users will access pages in intended sequence
  • Do not trust user not to tamper with data; revalidate it before using it

Best Practices

  • Explicitly evaluate and document access control requirements for every unit of app functionality
  • Drive all access control decisions from user’s session
  • Use a central app component to check access controls; use it for every client request and mandate that every page must include an interface to this component
  • For sensitive functionality, restrict access by IP address
  • Protect static content by – passing filename to server side page that implements access control logic, or use HTTP authentication or other feature to restrict access
  • Do not trust resource id from client, validate them on server
  • Consider requiring re-authentication or two factor authentication for security-critical app functions
  • Log events using sensitive data or actions

Advantages of Central Access Control

  • It increases clarity of access control within application.
  • It makes maintainability more efficient and reliable, required changes are needed to be done once.
  • It improves adaptability. New access controls can be added and used easily.
  • It results in fewer mistakes and omissions.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s