This notes is for learning/educational purpose only. Use it at your own risks.
Core elements of defense mechanisms usually employed by Web Applications:
- Handling user access to app’s data and functionality to prevent unauthorized access
- Handling user input to prevent malformed input from causing undesirable behavior
- Handling attackers by taking suitable defensive and offensive measures
- Administrative monitoring and configuring application
HANDLING USER ACCESS
- Authentication : Process contains core authentication mechanism, plus authentication related functions. Often it contains defects in both design and implementations.
- Session Management : Using cookies for tracking user and requests. User is identified with session token. Session management is highly dependent on security of token. Defects in how tokens are generated enables token guessing and defects in how tokens are handled enables attacker to capture other users token.
- Access Control : To make and enforce correct decisions about whether individual request should be permitted or denied. Due to complex nature of access control requirements it becomes source of security vulnerabilities.
HANDLING USER INPUT
Various types of inputs include arbitrary texts like blog posts, cookies, hidden form fields, parameters and http header fields like user agent.
Approaches to input handling
- Rejecting Known bad or ‘Blacklisting’
- Least effective method due to difficulty of identify all bad input.
- If SELECT is blocked, try SeLeCT
- If ‘or 1=1–‘ is blocked, try ‘or 2=2–‘
- If alert(‘xss’) is blocked, try prompt(‘xss’)
- Accepting Known Good or ‘Whitelisting’
- Most effective technique
- Sometimes not feasible in cases where input is blog post or names containing quotes.
- Render dangerous input harmless
- URL Encoding
- Difficult is several kinds of data is present within input. So Boundary validation is a better option.
- Safe Data Handling
- Code that cant be fooled by malicious input i.e. SQL parameterized queries, not passing input to OS command line.
- May be impossible to achieve it due to requirement of intensive training for all developers, often settled with devices like WAF etc.
- Semantic Checks
- Malicious input is identical to valid input like providing different user id.
- Data must be validated in context i.e. input user id belongs to logged in user?
Note: In context where NULL bytes act as string delimiter, it can be used to terminate file name or query string. In context where NULL byte is ignored, arbitrary NULL bytes can be used to defeat some black-list based filters.
Problem with Simple Input Validation
- User input is untrusted
- Server side app is trusted. Apps may chain several processing steps together. Data may be harmless at one stage but can be harmful at another stage.
- Trust boundary is required.
- Clean data that passes a boundary
- Each component treats its input as malicious
- Data validation should be performed at each trust boundary. Not just between client and server.
- Username and password is input. Allow only good characters, limits length, remove known attack signatures.
- Escape dangerous characters in SQL query performing credential verification.
- App server passes user profile data to SOAP service. XML metacharacters are encoded to block SOAP injection.
- App displays user account information back to browser. User supplied data is HTML encoded to block XSS known as Output Sanitization.
Simple Filtering Issues:
- Rejecting ‘<script>’ can be bypassed by ‘<sc<script>ript>’
- Multistep filtering: First removing ‘../’, then ‘..\’ can be bypassed by ‘….\/’
Canonicalization is process of converting or decoding data into common character set. If any canonicalization is done after filters have been applied, an attacker may use suitable encoding scheme to bypass validation mechanism.
- App gets URL-encoded data from browser. To block apostrophe, app filters %27. But data is decoded twice by mistake so app gets %2527 as apostrophe which bypasses app filters.
- If app strips apostrophe instead of encoding then performs canonicalization then %%2727 can be effective.
Attackers are handled by implementing following measures:
- Handling errors
- Maintaining audit logs
- Alerting administrators
- Reacting to attacks
- Show appropriate error messages
- Unhandled errors lead to overly-informative error messages
- Authentication events like login success or failure, password change etc.
- Key transactions like credit card payments or fund transfer
- Access attempts that is blocked by Access control mechanisms
- Requests containing known attack strings
- For high security, log every client request in full with IP, time, cookie etc.
- Store audit log to autonomous system that accepts only update messages from main app
- Poorly protected log can be gold mine, disclosing sensitive info like session tokens and request parameters.
- Use anomalies for alerting, like large number of requests from same IP or user
- Business anomalies, like large number of fund transfers to/from same account
- Requests containing known attack strings
- Requests where hidden data has been modified.
- WAF can detect generic attacks but not subtle ones.
- Most effective security control is integrated with app’s input validation mechanisms.
Reacting to Attacks:
- Attackers probe for vulnerabilities. Sending many similar requests.
- Automated defenses include responding increasingly slowly to requests or terminating attacker’s session. Like Bro tool does.
To manage and monitor applications, administrative interfaces are often built in app itself or accessible through some other interface which may perform user account and roles management, access monitoring and audit functions, perform diagnostics and log management. So it is primary attraction for attacker as vehicle for PE (privilege escalation).
Attacking Admin interfaces:
- Defeat weak authentication mechanisms
- Poor implementation of access control mechanisms, provides access to admin functions with low privileges
- Cookie theft and session hijack with XSS compromises admin level privileges/account