evildojo

Web App Hacker's Handbook Notes



2. Core Defense Mechanisms

Questions:

  1. Why are an application’s mechanisms for handling user access only as strong as the weakest of these components?
  2. What is the difference between a session and a session token?
  3. Why is it not always possible to use a whitelist-based approach to input validation?
  4. You are attacking an application that implements an administrative func- tion. You do not have any valid credentials to use the function. Why should you nevertheless pay close attention to it?
  5. An input validation mechanism designed to block cross-site scripting attacks performs the following sequence of steps on an item of input:
    1. Strip any <script> expressions that appear.
    2. Truncate the input to 50 characters.
    3. Remove any quotation marks within the input.
    4. URL-decode the input.
    5. If any items were deleted, return to step 1.

Can you bypass this validation mechanism to smuggle the following data past it?

"><script>alert("foo")</script>

Answers:

In a typical application, access is handled using a trio of mechanisms relating to authentication, session management, and access control. These components are highly interdependent, and a weakness in any one of them will undermine the effectiveness of the overall access handling mechanism. For example, a defective authentication mechanism may enable an attacker to login as any user and so gain unauthorized access. If session tokens can be predicted, an attacker may be able to masquerade as any logged in user and gain access to their data. If access controls are broken, then any user may be able to directly use functionality that is supposed to be protected.

A session is a set of data structures held on the server, which are used to track the state of the user’s interaction with the application. A session token is a unique string that the application maps to the session, and is submitted by the user to reidentify themselves across successive requests.

There are many situations where an application may be forced to accept data for processing that does not match a list or pattern of input that is known to be “good”. For example, many people’s names contain characters that can be used in various attacks. If an application wishes to allow people to register under their real names, it needs to accept input that may be malicious, and ensure that this is handled and processed in a safe manner nevertheless.

Defects in the any of the core mechanisms for handling access may enable you to gain unauthorized access to the administrative functionality. Further, data that you submit as a low privileged user may ultimately be displayed to administrative users, enabling you to attack them by submitting malicious data designed to compromise their session when it is viewed.

Yes. If it were not for Step 4, this mechanism would be robust in terms of filtering the specific items it is designed to block. However, because your input is decoded after the filtering steps have been performed, you can simply URL-encode selected characters in your payload to evade the filter:

%22>%3cscript>alert(%22foo%22)</script>

If Step 4 were performed first (or even not at all) then this bypass would not be possible.


3. Web Application Technologies

Questions

  1. What is the OPTIONS method used for?
  2. What are the If-Modified-Since and If-None-Match headers used for?
    • Why might you be interested in these when attacking an application?
  3. What is the significance of the secure flag when a server sets a cookie?
  4. What is the difference between the common status codes 301 and 302?
  5. How does a browser interoperate with a web proxy when SSL is being used?

Answers

  1. The OPTIONS method asks the server to report the HTTP methods that are available for a particular resource.
  2. The If-Modified-Since header is used to specify the time at which the browser last received the requested resource. The If-None-Match header is used to specify the entity tag that the server issued with the requested resource when it was last received.
    • In the two ways described, these headers are used to support caching of content within the browser, and they enable the server to instruct the browser to use a cached copy of a resource, rather than responding with the full contents of the resource if this is not necessary.
    • When you are attacking an application, your browser may already have cached copies of resources that you are interested in, such as JavaScript files. By removing these two headers, you can override the browser’s caching information and ensure that the server responds with a fresh copy of the resource you wish to view.
  3. The secure flag is used to instruct the browser that the cookie should only ever be resubmitted over HTTPS connections, and never unencrypted HTTP.
  4. The 301 status code tells the browser that the requested resource has moved permanently to a different location. For duration of the current browser session, if your browser needs to access the originally requested resource, it will use the location specified in the 301 response instead. The 302 status code tells the browser that the requested resource has moved temporarily to a different location. On the next occasion that the browser needs to access the originally requested resource, it will request this from the originally requested location.
  5. The browser sends a CONNECT request to the proxy, specifying the destination hostname and port number as the URL within this request. If the proxy allows the request, it returns an HTTP response with a 200 status, keeps the TCP connection open, and from that point onwards acts as a pure TCP-level relay to the specified destination.

4. Mapping the Application


5. Bypassing Client-Side Controls


6. Attacking Authentication


7. Attacking Session Management


8. Attacking Access Controls


9. Attacking Data Stores


10. Attacking Back-End Components


11. Attacking Application Logic


12. Attacking Users: Cross-Site Scripting


13. Attacking Users: Other Techniques


14. Automating Customized Attacks


15. Exploiting Information Disclosure


16. Attacking Native Compiled Applications


17. Attacking Application Architecture


18. Attacking the Application Server


19. Finding Vulnerabilities in Source Code