Learn to examine web requests and consider what types should be allowed and how to respond to them.
- 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 checkpoint implement defense in depth. A passenger shows their ID and boarding pass to an agent, and then they pass 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 and 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's allowed through while bad data is allowed 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 back a response 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 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 with 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're expecting a form submission, then you should require a post request. This ensures the request methods match your expectations. Get and post aren't the only two types of request methods. There's also connect, delete, head, options, put, trace, and probably more coming soon. Make sure that your application accepts only the request methods that 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. 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 of these are html, json, xml, or text, but the format can be any MIME type including rss, pdf, image, audio, or video. a website should accept in request and which data formats it's able to send back as a response. These values can be faked, but it's still worth filtering out data formats which are unacceptable. Other attributes of requests that can be examined include IP address, URL, Query parameters, User-Agent, and Size. A request from an IP address, which has been a problem in the past, can be added to a deny list. A URL that includes unexpected strings or parameters, maybe username, password, or session could be rejected. The User-Agent string could be used to disallow WebCrawlers 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 could use firewalls and proxies, which are powerful, specialized tools for regulating requests. Regulating requests can provide a good first line of defense.
- Threat models
- Least privilege
- Defense in depth
- Validating and sanitizing input
- Credential attacks
- SQL injection
- Cross-site scripting