Regulate requests

- Before you can fly on a commercial airplane, you must first pass through a security checkpoint. These checkpoints are designed to detect problems early and to keep the most serious threats out. Most security checkpoints implement defense in depth. Passenger shows their ID and a boarding pass to an agent, then passes through a combination of metal detectors and x-ray machines. More agents are on hand to perform additional checks, such as to manually inspect bags or conduct swab tests to detect chemical residue. In this chapter, we'll discuss filtering input and controlling output. Filtering input is a lot like a security checkpoint, we want to stop problems early. Good data is allowed through, while bad data is kept out. Regulating requests, validating input and sanitizing data are different techniques that provide defense in depth. Let's talk about the first layer of defense, regulating requests. HTTP requests are the most fundamental component of website interaction. A browser sends a request to a web server, the web server sends a response back to the browser. Like a security checkpoint, a website should be selective about which requests it accepts. A request can be inspected and evaluated on some criteria before its content is even read. It's like examining the outside of an envelope before you open it to read the letter inside. The request method is the first criteria to consider. An unexpected request method may indicate an attempt to manipulate the website. The most common request methods are GET and POST. A GET request is typically sent when a URL is typed into a browser or when a link is clicked. A POST request is typically used when submitting a web form. A website that does not examine the request method will accept both methods for all pages. If you're not expecting a form submission, then you should require a GET request. If you are expecting a form submission, then you should require a POST request. This ensures that your request methods match your expectations. GET and POST requests aren't the only two types of request methods. There's CONNECT, DELETE, HEAD, OPTIONS, PUT, TRACE, and probably more coming soon. Make sure that your application accepts only the request methods you expect and ignores all others. Another criteria to examine is the request/response format. A request typically sends two key values, content type, and accept. Content type is used to indicate the format of the incoming data. Accept is used to specify the format of the response that the browser making the request would like to get back. The most common formats for both are HTML, JSON, XML, or text. But the format can be any MIME type including RSS, PDF, images, audio, or video. It's important to consider which data formats a website should accept in a request and which data formats it's able to send as a response. These values can be faked, but it's still worth filtering out data formats which are unacceptable. Other attributes of a request that can be examined include a request from an IP address which has been a problem in the past, could be added to a deny list. A URL that includes unexpected strings or parameters such as username, password, or session could be rejected. The user-agent string could be used to disallow web crawlers and search engines. Requests which are too large, or which contain file uploads that are too large could be rejected. Filtering requests by examining these types of criteria can be done either in the web server configuration or inside your web application. Or you can use firewalls and proxies, which are powerful, specialized tools for regulating requests. Together, these techniques can provide a solid first line of defense.