Security HTTP headers you must know about

Author: Larry Lu
Translator: Front-end Xiaozhi
Source: stackabuse

If you have dreams and dry goods, search [Moving the World] attention to this Shawanzhi who is still washing dishes in the early morning.

This article has been included in GitHub https://github.com/qq449245884/xiaozhi , and there are complete test sites, materials and my series of articles for interviews with first-tier manufacturers.

With more and more web applications on the network, in order to improve security, there are too many HTTP headers related to security. Because there are too many HTTP headers for various functions, I want to introduce a few simple and easy-to-set security headers. As long as these headers are added, the website will suddenly become safe~

Content Security Policy (CSP)

The first is the time-honored CSP, this header is used to limit where the browser can only load resources. For example, if I set Content-Security-Policy: default-src larry.com , it means that I restrict the browser to only load images, CSS, fonts and other resources from the domain name larry.com

Of course, it is also possible to set up many domain names, as long as you keep going down. The content of the developer tool in the picture below is the CSP setting in the response header when I went to the Github homepage. He just added many domains such as uploads.github.com , api.github.com and so on. Although it looks very long, there is at least one whitelist. Doesn't inexplicably load things from other domains

If you want to have different policies for different types of resources (although it is more troublesome but safer), you can also write it in the form of Content-Security-Policy: img-src a.com; font-src b.com , then the browser will know that you want to only load images from a.com and load fonts from b.com

If you want to see what other attributes can be set, you can refer to the Directives on MDN

So what's the point of restricting domain names? If a hacker finds an XSS vulnerability on my website one day and allows him to add a paragraph of <script src=“hacker.com/evil.js”> to the HTML of the home page, then every user to my website will load the malicious evil.js in the browser, so that the hacker can Do bad things like redirects, steal account passwords, etc.

But if the CSP is set to Content-Security-Policy: default-src larry.com , the browser will refuse to load evil.js (below) because the script is from hacker.com . Therefore, although CSP cannot completely prevent XSS, it can reduce the impact of XSS, because if the attacker cannot load malicious resources from the outside, there are relatively few things that can be done.

Strict Transport Security (HSTS)

The full name of HSTS is HTTP Strict Transport Security. There may be fewer people who have heard this header. It is used to force browsers to use the secure HTTPS protocol to connect to , but not HTTP

For example, many websites actually use HTTP and HTTPS to connect, but considering the security, of course, users are expected to use HTTPS. At this time, as long as Strict-Transport-Security: max-age=31536000; includeSubDomains is added to the header, in the next 31536000 seconds (actually a year XD), as long as the user's browser sees this domain name or his subdomain name, it will all be changed to HTTPS It's really easy to connect

Also because almost all websites now have HTTPS, so Google, Medium, and Facebook, which are usually used, can see the traces of HSTS, but the max-age set by everyone is slightly different. The more commonly seen ones are probably Numbers like 31536000 (one year), 15552000 (180 days)

X-Content-Type-Options

There may be fewer people who have heard of this header. Before talking about this header, we have to talk about what content sniffing is: Generally speaking, browsers will use Content-Type to determine the type of the requested resource, like transparent The Content-Type obtained through <script src="script.js"> is generally text/javascript , so the browser will execute it after seeing it

However, some websites (especially old websites more than ten or twenty years ago) did not set the Content-Type properly during development, resulting in the Content-Type of some JS files being text/plain , that is, plain text files. In order to make these websites work smoothly, the browser will not only refer to Content-Type, but also do content sniffing to analyze what type it is from the content of the file. If it is JS, it will be executed, so that the old website will not be broken. Lose

But the action of sniffing seems intimate, but it is also a weakness. For example, if some websites allow users to upload resources, the attacker can maliciously upload some JPG files with JS features (these pictures will be judged as scripts by the browser). Then find a way to let this picture be loaded into the front end, causing the malicious script inside to be executed, causing XSS attack

In order to prevent the browser from guessing what the C ontent-Type of the resource is (and the trouble is that each browser guesses in different ways), we need to add headers to X-Content-Type-Options: nosniff to tell the browser to directly use the one provided in the header. Content-Type is just fine, don't guess there, so that there will be no such thing as plain text and pictures being judged as scripts.

But also because nosniff is added, so be sure to pay attention to whether the Content-Type of various resources is set, because the browser will not help you guess, if you really set the Content-Type of JS and CSS wrong, then browse The browser won't run it, and the site will look weird

X-Frame-Options

Usually when writing a webpage, if you want to use the content of other webpages (below), you can use <iframe src="https://website.com"> to embed it; on the contrary, if someone else wants to embed the website I made into his website, it is also possible

So what are the security concerns? In case of a bad website, he embedded the Weather Bureau webpage through iframe , made the iframe transparent with CSS, and put some buttons behind the transparent iframe (below). When the user clicks on the bad bad website I am handsome and I am handsome, they will accidentally click on the website of the Weather Bureau. This kind of attack is called Clickjacking

If you only click on the website of the Meteorological Bureau, it will not be so good, anyway, it is just like that. But what if it is embedded in a bank's website? Then the user may be deceived by the well-designed button, and press the transfer, withdrawal, etc. buttons in the iframe unconsciously.

In order to avoid such problems, the best way is to add the header X-Frame-Options: deny , which means to tell the browser that my website does not want to be embedded (most banks will add this header for security)

So when I want to embed the page of Yushan Bank on my own website, the browser will spew the ebank.esunbank.com.tw "It is not allowed to be embedded by other websites". Because the page of Yushan Bank is not allowed to be embedded at all, so Avoid iframe based Clickjacking attacks

Summarize

Today, I introduced four security-related HTTP headers, including CSP, HSTS, X-Content-Type-Options, and X-Frame-Options. These headers are not only easy to use, but also take no more than ten minutes, and they can be used to a large extent. Improve security, so it is already an indispensable HTTP headers for website development

In addition to these four, there are actually many headers such as X-XSS-Protection, Expect-CT, Public-Key-Pins, Feature-Policy, etc., but because some of the effects are not so great, some have been announced to be deprecated , so I won't mention it here. If you are interested, you can go to Owasp Secure Headers to see it~

---

The possible bugs after the code is deployed cannot be known in real time. In order to solve these bugs afterwards, a lot of time is spent on log debugging. By the way, I recommend a useful bug monitoring tool Fundebug .

https://medium.com/starbugs/must-know-surity-http-headers-be78aeb93200

communicate with

If you have dreams and dry goods, search [Moving the World] Follow this Shawanzhi who is still washing dishes in the early morning.

This article has been included in GitHub https://github.com/qq449245884/xiaozhi , and there are complete test sites, materials and my series of articles for interviews with first-tier manufacturers.