CORS, CSP, HTTPS, HSTS: About Web Security Technologies
The author of the material, the translation of which we publish today, says that there are many reasons to study web security. For example, users of web sites who are concerned about the possibility of theft of their personal data are interested in security issues. Security is concerned with web developers who strive to increase the level of protection for the projects they create. The same can be said about novice programmers who are looking for work and preparing for interviews. The purpose of this article is to explain some important web security technologies in an understandable language. Before we start talking about these technologies, at the mention of which they usually operate on abbreviations like CORS, CSP and HSTS, consider a couple of basic security concepts.
In the security world, there is no such thing as “100% protection against hacking”. If anyone ever tells you about this level of protection, know that he is mistaken.
Suppose someone believes that by implementing CSP, he completely protected his project from XSS attacks. It is possible that someone perceives that absolute protection does not exist as a given, but thoughts like the one described above can be visited by anyone. If we talk about programmers who have decided to understand security issues, then perhaps the reason for the emergence of such thoughts is the fact that, when writing software code, they mainly operate with such concepts as "black" and "white", 1 and 0, "true" and "false." But security is not so simple.
')
Let's start a conversation about web security with technology, to which developers usually pay attention very early, say, at the very beginning of their professional path. By the way, if you set a goal to bypass this protection method, on StackOverflow you can find a lot of information about how to do this. This is about CORS.
Have you ever seen such an error:
When you meet with a similar one, you think that you are certainly not the first with whom it happened. Googling, you find out that, in order to solve this problem, it is enough to install some kind of extension. Isn't it great? However, the CORS (Cross-Origin Resource Sharing) technology, the sharing of resources between different sources, does not exist in order to prevent developers, but in order to protect their projects.
In order to understand how CORS allows you to protect web projects, we first talk about cookies, in particular, cookies used to authenticate users. Such cookies are used, when working with a certain web resource, to inform the server that the user is logged in. They are automatically sent with requests made to the corresponding server.
Suppose you are logged in to your Facebook account, with Facebook using authentication cookies. While working on the Internet, you click on the bit.ly/r43nugi link, you are redirected to a malicious website, say, to something like
In a world without CORS, a script with
However, in a world where there is CORS, Facebook would only allow requests to change account data from the source
Here you may have the following question: “But superevilwebsite.rocks can simply change the source title in its queries, and they will look like they are coming from facebook.com?”.
A fraudulent site may try to do this, but it will not work, as the browser will ignore such a header and use real data.
“What if superevilwebsite.rocks performs a similar request from the server?”, You ask.
In such a situation, CORS can be bypassed, but there will be no sense from this, since, by executing a request from the server, it will not be possible to transfer the Facebook authentication cookie. Therefore, the script, for the successful execution of such a request, must be executed on the client side and have access to the cookies stored on the client.
In order to understand what is CSP (Content Security Policy, content protection policy), you first need to talk about one of the most common web vulnerabilities. This is XSS (cross-site scripting, crossite scripting).
When performing an XSS attack, an attacker injects special JavaScript code into the client part of a certain site. You might think: “So what will this script do? Change the colors of the page elements?
Suppose that someone successfully implemented his JS script into the pages of the site you visited. What dangerous can make such a script? In fact, a lot of things:
In fact, the possibilities offered to an attacker with a successful XSS attack are endless.
The content protection policy attempts to prevent this by applying the following restrictions:
How does the CSP work?
When you click a link or enter a website URL in the address bar of your browser, the browser makes a GET request. The request comes to the server, which sends the browser some HTML-code along with the HTTP headers. If you are interested in looking at these headers, open the Network tab in the browser’s developer tools and visit several sites. The response header might look something like this:
This is the
Consider the CSP directives presented here:
Note that, in fact, there are many such directives. The browser reads the CSP header and applies the appropriate rules within the loaded HTML file. Properly configured directives allow only those actions that are necessary for the correct operation of the page.
If the page has no CSP header, then no restrictions are applied to it. The * characters in the CSP header are wildcard characters. Such a sign can be replaced by anything, and what happens will be allowed.
Surely you've heard about HTTPS (HTTP Secure). Perhaps you have seen something like this: “Why should I worry about HTTPS if I just play the game on the site?”. Or perhaps you’ve come across this idea: “If you don’t have HTTPS, then this is just insane. In the yard in 2018! Do not believe anyone who says that you can do without HTTPS. ”
You may have heard that Chrome now marks the site as insecure if it does not use HTTPS.
The main difference between HTTPS and HTTP is that, when transmitting data over HTTPS, they are encrypted, but when transmitting over HTTP they are not.
Why is it worth paying attention to when transferring valuable data? The thing is that when organizing data exchange over an unprotected communication channel, there is the possibility of a MITM-attack (Man In The Middle, attack of the mediator, or attack "man in the middle").
If you are sitting in a cafe, go to the Internet through an open Wi-Fi access point, someone, quite simply, can pretend to be a router through which all your requests and responses go. If your data is not encrypted, the mediator can do whatever he wants with them. Let's say it can edit HTML, CSS, or JavaScript code before it arrives from the server to your browser. Given what we already know about XSS attacks, you can imagine what the consequences could be.
“How is this possible: my computer and server know how to encrypt and decrypt the data we exchange, and the attacker-intermediary does not?”, You ask. This is possible through the use of the SSL (Secure Sockets Layer) protocol and the more recent TLS (Transport Layer Security) protocol. TLS replaced SSL in 1999 as the encryption technology used in HTTPS. TLS features are beyond the scope of this material.
The HSTS technology (HTTP Strict-Transport-Security, the mechanism for forcing a secure connection via the HTTPS protocol) is quite simple. As an example, consider the corresponding Facebook header again:
Let's analyze it:
This header applies only if you access the site using HTTPS. If you work with the site via HTTP, this header is ignored. The reason for this is quite simple: HTTP data exchange is so weakly protected that such a header cannot be trusted.
Again, let's use Facebook as an example to demonstrate the practical usefulness of the HSTS mechanism. Suppose you log into facebook.com for the first time and at the same time know that HTTPS is safer than HTTP, so you use this link:
Today we discussed some technologies that are commonly used to ensure the security of web projects. We believe that security issues are very important, as they concern absolutely everyone who is connected with the Internet. The topic of web security is huge, so you can’t say that after reading a few articles, someone will become an expert in this field or at least find out enough to effectively protect your web project or your personal data. But, as in any other field, knowledge in the field of security, if there is a desire to receive them, is accumulated and their quantity gradually turns into quality. Hopefully this material has contributed to your knowledge of web security.
Dear readers! Have you encountered irresponsible safety concerns from web developers?
Two basic web security concepts
â–Ť100% protection is a myth
In the security world, there is no such thing as “100% protection against hacking”. If anyone ever tells you about this level of protection, know that he is mistaken.
â–ŤA level of protection is not enough
Suppose someone believes that by implementing CSP, he completely protected his project from XSS attacks. It is possible that someone perceives that absolute protection does not exist as a given, but thoughts like the one described above can be visited by anyone. If we talk about programmers who have decided to understand security issues, then perhaps the reason for the emergence of such thoughts is the fact that, when writing software code, they mainly operate with such concepts as "black" and "white", 1 and 0, "true" and "false." But security is not so simple.
')
Web Security Technologies
Let's start a conversation about web security with technology, to which developers usually pay attention very early, say, at the very beginning of their professional path. By the way, if you set a goal to bypass this protection method, on StackOverflow you can find a lot of information about how to do this. This is about CORS.
â–ŤCORS
Have you ever seen such an error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. When you meet with a similar one, you think that you are certainly not the first with whom it happened. Googling, you find out that, in order to solve this problem, it is enough to install some kind of extension. Isn't it great? However, the CORS (Cross-Origin Resource Sharing) technology, the sharing of resources between different sources, does not exist in order to prevent developers, but in order to protect their projects.
In order to understand how CORS allows you to protect web projects, we first talk about cookies, in particular, cookies used to authenticate users. Such cookies are used, when working with a certain web resource, to inform the server that the user is logged in. They are automatically sent with requests made to the corresponding server.
Suppose you are logged in to your Facebook account, with Facebook using authentication cookies. While working on the Internet, you click on the bit.ly/r43nugi link, you are redirected to a malicious website, say, to something like
superevilwebsite.rocks . The script, loaded with the page of this site, performs a client request to facebook.com using your authentication cookie.In a world without CORS, a script with
superevilwebsite.rocks could secretly make changes to your FB profile, could steal some information, with all the ensuing consequences. In such a world, an “epidemic superevilwebsite.rocks” could easily arise, when a script that seizes user account management publishes a link on its page, clicking on which friends of this user “infect” themselves, and through the links published on their pages, an epidemic As a result, covers the entire Facebook.However, in a world where there is CORS, Facebook would only allow requests to change account data from the source
facebook.com . In other words, the site administration would limit the sharing of resources between different sources.Here you may have the following question: “But superevilwebsite.rocks can simply change the source title in its queries, and they will look like they are coming from facebook.com?”.
A fraudulent site may try to do this, but it will not work, as the browser will ignore such a header and use real data.
“What if superevilwebsite.rocks performs a similar request from the server?”, You ask.
In such a situation, CORS can be bypassed, but there will be no sense from this, since, by executing a request from the server, it will not be possible to transfer the Facebook authentication cookie. Therefore, the script, for the successful execution of such a request, must be executed on the client side and have access to the cookies stored on the client.
â–ŤCSP
In order to understand what is CSP (Content Security Policy, content protection policy), you first need to talk about one of the most common web vulnerabilities. This is XSS (cross-site scripting, crossite scripting).
When performing an XSS attack, an attacker injects special JavaScript code into the client part of a certain site. You might think: “So what will this script do? Change the colors of the page elements?
Suppose that someone successfully implemented his JS script into the pages of the site you visited. What dangerous can make such a script? In fact, a lot of things:
- It can perform HTTP requests to other sites, pretending to be you.
- It can redirect you to a site that looks exactly like the one you are logged in to, but designed, for example, to steal credentials.
- It is able to add
<script>tags to pages that contain some JavaScript code or are designed to load some JS files. - It can add an
<iframe>element to the page, which will, for example, look exactly the same as the fields for entering the name and password to access the site. At the same time, the real fields for entering such data will be hidden.
In fact, the possibilities offered to an attacker with a successful XSS attack are endless.
The content protection policy attempts to prevent this by applying the following restrictions:
- Restrictions on what can be opened in the
<iframe>. - Restrictions on which style sheets can be loaded.
- Restrictions on what queries can be performed.
How does the CSP work?
When you click a link or enter a website URL in the address bar of your browser, the browser makes a GET request. The request comes to the server, which sends the browser some HTML-code along with the HTTP headers. If you are interested in looking at these headers, open the Network tab in the browser’s developer tools and visit several sites. The response header might look something like this:
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm; This is the
facebook.com content security policy. Let's transform it to a more readable form: content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm; Consider the CSP directives presented here:
default-src- prohibits everything that is not explicitly specified.script-src- imposes restrictions on downloadable scripts.style-src- imposes restrictions on loadable style sheets.connect-src- introduces restrictions on URLs from which resources can be loaded using script interfaces, such asfetch,XHR,ajax, and so on.
Note that, in fact, there are many such directives. The browser reads the CSP header and applies the appropriate rules within the loaded HTML file. Properly configured directives allow only those actions that are necessary for the correct operation of the page.
If the page has no CSP header, then no restrictions are applied to it. The * characters in the CSP header are wildcard characters. Such a sign can be replaced by anything, and what happens will be allowed.
â–ŤHTTPS
Surely you've heard about HTTPS (HTTP Secure). Perhaps you have seen something like this: “Why should I worry about HTTPS if I just play the game on the site?”. Or perhaps you’ve come across this idea: “If you don’t have HTTPS, then this is just insane. In the yard in 2018! Do not believe anyone who says that you can do without HTTPS. ”
You may have heard that Chrome now marks the site as insecure if it does not use HTTPS.
The main difference between HTTPS and HTTP is that, when transmitting data over HTTPS, they are encrypted, but when transmitting over HTTP they are not.
Why is it worth paying attention to when transferring valuable data? The thing is that when organizing data exchange over an unprotected communication channel, there is the possibility of a MITM-attack (Man In The Middle, attack of the mediator, or attack "man in the middle").
If you are sitting in a cafe, go to the Internet through an open Wi-Fi access point, someone, quite simply, can pretend to be a router through which all your requests and responses go. If your data is not encrypted, the mediator can do whatever he wants with them. Let's say it can edit HTML, CSS, or JavaScript code before it arrives from the server to your browser. Given what we already know about XSS attacks, you can imagine what the consequences could be.
“How is this possible: my computer and server know how to encrypt and decrypt the data we exchange, and the attacker-intermediary does not?”, You ask. This is possible through the use of the SSL (Secure Sockets Layer) protocol and the more recent TLS (Transport Layer Security) protocol. TLS replaced SSL in 1999 as the encryption technology used in HTTPS. TLS features are beyond the scope of this material.
â–ŤHSTS
The HSTS technology (HTTP Strict-Transport-Security, the mechanism for forcing a secure connection via the HTTPS protocol) is quite simple. As an example, consider the corresponding Facebook header again:
strict-transport-security: max-age=15552000; preload Let's analyze it:
max-agesets the time during which the browser must forcibly transfer the user to work with the website via HTTPS.preload- for our purposes it does not matter.
This header applies only if you access the site using HTTPS. If you work with the site via HTTP, this header is ignored. The reason for this is quite simple: HTTP data exchange is so weakly protected that such a header cannot be trusted.
Again, let's use Facebook as an example to demonstrate the practical usefulness of the HSTS mechanism. Suppose you log into facebook.com for the first time and at the same time know that HTTPS is safer than HTTP, so you use this link:
https://facebook.com . When your browser receives HTML, it also receives a header that tells the browser that it should force you to HTTPS when performing future requests. A month later, someone sends you an HTTP link to Facebook, http://facebook.com , and you click on it. Since the month is less than the time limit of 15552000 seconds, set by the max-age directive, the browser sends a request for HTTPS, preventing a potential MITM attack.Results
Today we discussed some technologies that are commonly used to ensure the security of web projects. We believe that security issues are very important, as they concern absolutely everyone who is connected with the Internet. The topic of web security is huge, so you can’t say that after reading a few articles, someone will become an expert in this field or at least find out enough to effectively protect your web project or your personal data. But, as in any other field, knowledge in the field of security, if there is a desire to receive them, is accumulated and their quantity gradually turns into quality. Hopefully this material has contributed to your knowledge of web security.
Dear readers! Have you encountered irresponsible safety concerns from web developers?
Source: https://habr.com/ru/post/421347/
All Articles