4 Common HTTP Security headers

Transferred from: http://blog.jobbole.com/60143/

It was the beginning of a world library dream, and now it is a global gathering place of knowledge, it is currently the most popular, people will apply to deploy on the World Wide Web.

It is the representative of agile, it is not a single entity, it consists of the client and the service side, its function is constantly strong, it also has the standard.

While more and more solutions are well suited to discovering what works and what is not, it has little consistency and no easy-to-use programming model. As the saying goes: the easier things are, the safer they become. Simple things can be hard to have a loophole like xss,csrf or clicking on a hostage.

Because HTTP is an extensible protocol, browser vendors are the first to roll out effective headers to prevent exploits or improve the difficulty of exploiting vulnerabilities. Knowing what they are and how they are applied can improve the security of the system.

1.content-security-policy, why is it so good?

How can I try not to suffer from XSS attacks? If someone wrote the following code on your server, the browser might not parse it? <script>alert(1);</script>,

The following is a description of the content security specification.

Add the Content security specification header and assign the appropriate values to limit the source of the following properties:

12345678

script-src: JavaScript code (biggest reason to use this header)connect-src: XMLHttpRequest, WebSockets, and EventSource.font-src: fontsframe-src: frame ulrsimg-src: imagesmedia-src: audio & videoobject-src: Flash (and other plugins)style-src: CSS

Special designations are required:

Content-security-policy:script-src ' self ' https://apis.google.com

This means that the script file can only be from the current file or apis.google.com (Google's JavaScript CDN)

Another useful feature is that you can automatically apply sandbox mode to the entire site. If you want to try it out, you can run it with the "content-security-policy-report-only" head and let the browser return a URL of your choice. It is recommended to read an introduction to CSP on Html5rocks.

What do you have to pay attention to?

Unfortunately, IE only supports sandbox mode and uses the "X" prefix. An Andro It supports the latest version 4.4.

Of course, it is not omnipotent, if you dynamically generate a JavaScript, hackers can still put malicious JS into your server. Including it is harmless and protects users in Chrome, Firefox, and iOS.

Which browsers are supported?

Where can you learn more about it?

Html5rocks has a good introduction to it. The standard is also a good choice.

2. X-frame-options What's good about it?

It can prevent click hijacking attacks, just one sentence:

X-frame-options:deny

This causes the browser to reject the data that is requested for the page. It also has a value of "Sameorigin", which allows data from the same source. As well as "Allow from http://url-here.example.com", it can set the source (ie is not supported).

What do you have to pay attention to?

Some vendors do not support this head, and it may be integrated into Content-security-policy 1.1. But so far, no one has given enough reason to say that it cannot be used.

Which browsers are supported?

Ie	Firefox	Chrome	IOS Safari	Android Browser
8+	3.6.9+	4.1.249+	?	?

(Data source Mozilla Developer Network)

Where can you learn more about it?

There's not much to learn, but to learn more, you can visit the Mozilla Developer Network article on this issue. Coding Horror also have a relatively good article.

3. X-content-type-options What's good about it?

Getting users to upload files is risky, providing file upload services at a greater risk, and it's hard to be foolproof.
It is not easy for a browser to Content-type two guesses, even if the content is obtained through MIME sniffing.
The X-content-type-options header allows you to more effectively inform the browser that you know what you are doing and when its value is "Nosniff" is only to indicate that Content-type is correct.
This head is applied on GitHub and you can try it.

What do you have to pay attention to?

Although it depends on your users, they account for 65% of the visitors you are protecting, but the head is only useful in IE and chrome.

Which browsers are supported?

IE	Firefox	Chrome	IOS Safari	Android Browser
8+	-(Bug 471020)	1 +	-	-

Where can you learn more about it?

FOX it has an excellent article on MIME sniffing: MIME sniffing: feature or vulnerability? There is also a topic on IT Security stackexchange: Can x-content-type-options really prevent content sniffing attacks?

4. Strict-transport-security What's good about it?

My online bank uses HTTPS to ensure authenticity (I do connect to my own bank) and security (the transfer process is encrypted). However, this is still problematic ...

When I enter "onlinebanking.example.com" in the Address bar, the default is to use simple HTTP. It is only possible to use HTTPS that provides security when the server is redirected to the user (it is theoretically not secure, but it is actually very useful). Pianqiao is the redirection process that gives hackers a man-in-the-middle attack. In order to solve this problem, Strict-transport-security head was born.

The HTTP strict-transport-security (HSTS) header forces the browser to use HTTPS at the specified time. For example, if you enter https://hsts.example.com, it will return such a head:

strict-transport-security:max-age=31536000; Includesubdomains

Even if you are typing http://hsts.example.com, the browser will automatically become https://hsts.example.com. As long as the HSTs head has been active, the browser will do so by default. In the case above, it remains valid for 1 years after the last HTTP reply that contains the HSTs header. So, if I visited a website on January 1, 2013, I knew that the browser would use HTTPS on January 1, 2014. But if I visit again on December 31, 2013, it will become December 31, 2014.

What do you have to pay attention to?

Currently it only applies to Chrome and Firefox,ie users who still have this vulnerability. However, it has become the IETF standard, so it should be used as soon as possible to use the strict-transport-security head.

Of course, if you use HTTPS, you do not have to use this head, so why not https it? Keep in mind that HTTPS not only ensures that your content is encrypted, is not intercepted, but also provides authenticity. Promise to the user that the content really comes from you.

There are different debates about using HTTPS, in fact, blogs and the head are not based on HTTPS, so the argument will continue for a long time.

Which browsers are supported?

Where can you learn more about it?

Mozilla Developer Network has a Good article: http Strict Transport Security head

If you are working on SYMFONY2 or Drupal development

Learn more Symfony2 can look at the Nelmio security pack, and Drupal is detailed in the security component module. Reading them will give you a better understanding of the head of the above introduction.

The Hall of Shame: X-requested-with

jquery sends the X-requested-with header by default. It believes that this head can prevent the forgery of cross-site requests. However, this header does not produce a request, and a user session can be initiated by a third party, such as XMLHttpRequest in the browser to customize the header.

Unfortunately, the fast creation of Ruby on Rails's Ruby framework and the Django Python framework can be a good defense, but it doesn't depend entirely on the third-party plugins like Java or Adobe Flash.

Summarize

Using the above HTTP headers will help you quickly and easily prevent XSS attacks, click-to-hold attacks, mime sniffing, and man-in-the-middle attacks. If you haven't used it yet, you can use it on your app or server by introducing it to you.

Please ensure the user's security.

4 Common HTTP Security headers