The challenge for Day Eighteen is – Learn about Security Headers.
If you are testing a web application, the Developer Tools in your browser are your friend.
By pressing F12 on a Windows or Linux machine while accessing a site through a browser (or ⌥⌘I on a Mac), you can see a host of information.
If you visit the Network tab it will initially appear blank, but if you refresh the page with this tab open you will see all of the HTTP requests that were performed to load the webpage on your computer via your browser.
Putting it simply, a HTTP request is an instruction that your browser is sending to the web server, e.g. GET that image, POST my credentials etc.
HTTP requests can have an additional layer of protection in security headers.
These are like further instructions to legitimise the request that the browser is making.
I like to compare this to receiving a package via a courier.
- A customer orders an item to be delivered to their home (the client/browser).
- The sender (web server) puts the item into a courier bag and write the address on the bag.
- The courier collects the package, and checks the address written on the bag against the street name and letterbox number – if they don’t match, the request is denied.
- The sender may also request that the recipient signs for the package, and the signature is checked for authenticity, or specify that only a certain method of postage is suitable (e.g. secure courier vs public post service)
I found an article here where I learned about six common security headers:
- Content Security Policy
This header helps to reduce the likeliness of being hit by a cross-site scripting attack by defining approved content sources.
If the request you made was for something from example.com and the returned item came from an unexpected source like fakerequest.com, the request would be denied.
- X-XSS Protection
This header enables the browser’s inbuilt filter against cross site scripting
- HSTS – HTTP Strict Transport Security
This header forces browsers to use HTTPS to access the webserver rather than an insecure HTTP connection
- X-Frame Options
This header restricts the use of i-frames in an application, which can be used in “click-jacking” attacks where a malicious user can apply an i-frame over the top of a button so when a user tries to click the legitimate button they instead click whatever is in the i-frame.
- X-Content-Type options
This header restricts the browser from “sniffing” the response by specified content type.
E.g. if the response is for a .pdf file you cannot open it as a .txt file and see the code behind it, or alter it.
- Public Key Pinning
This security header is used to combat fraudulent security certificates.
The web server issues a number of public keys associated with a valid security certificate, and if the client request doesn’t include the required public key(s) the request is denied.
Thanks for reading my post and following my progress through the 30 Days of Security Testing.
Feel like joining in? Sign into the WeTest Slack group and get involved!