techsupport There are many reasons to learn web security. For example, security issues are of interest to website users who are concerned about the possibility of their data being stolen. Security is a concern for web developers who strive to increase the level of security of the projects they create. The same applies to aspiring programmers looking for work and preparing for interviews. This article aims to explain some critical web security technologies in clear language. Before discussing these technologies, usually referred to with acronyms like CORS, CSP, and HSTS, let’s look at some basic security concepts.
Two Basic Web Security Concepts
100% protection is a myth
In the security world, there is no such thing as “100% hack-proof.” If anyone ever tells you about this protection level, know they are wrong.
More than one level of protection is required.
Let’s say someone believes that implementing CSP has completely protected their project from XSS attacks. Perhaps someone takes for granted that absolute protection does not exist, but thoughts like the one described above can occur to anyone. If we are talking about programmers who decided to understand security issues. Then perhaps the reason for the emergence of such thoughts is the fact that. When writing program code, they mainly operate with such concepts as “black” and “white”, 1 and 0, true and false. But security is not that simple.
Web Security Technologies
Let’s start the conversation about web security with a technology that developers usually pay attention to very early at the beginning of their professional careers. By the way, if you set out to bypass this protection method, you can find a lot of information on how to do this on StackOverflow. We are talking about CORS.
CORS
Some errors can be resolved by installing an extension. Well, isn’t it wonderful? However, CORS (Cross-Origin Resource Sharing) technology exists not to hinder developers but to protect their projects.
To understand how CORS allows you to secure web projects, let’s first talk about cookies, particularly cookies used to authenticate users. Such cookies are used when working with a particular web resource to inform the server that the user is logged in. They are automatically sent with requests made to the appropriate server.
Let’s say you’re logged into your Facebook account, and Facebook uses authentication cookies. While surfing the Internet, you click on the link, you are redirected to some malicious site, say something like abcd.well. The script loaded with this site’s page makes a client request to facebook.com using your authentication cookie.
In a world without CORS, a script from abcd.well. could secretly make changes to your FB profile and could steal some information, with all the ensuing consequences. In such a world, an “abcd.well epidemic” could quickly arise when a script that takes control of a user’s account publishes a link on his page. By clicking on this user’s friends become “infected” themselves, and through the links posted on their pages, an epidemic, eventually covering all of Facebook.
However, in a CORS world, Facebook would only allow requests to change account data originating from facebook.com. In other words, the site administration would limit the sharing of resources between different sources.
At this point, you might be wondering, “But abcd.well could just change the source header in its requests to make them look like they were coming from facebook.com?”
A fraudulent site may try to do this, but it will fail because the browser will ignore such a header and use accurate data.
“What if abcd.well makes a similar request from the server.” You ask.
In a situation like this, you can bypass CORS, but it won’t do any good because when you request the server. You won’t be able to pass the authentication cookie to Facebook. Therefore, to complete such a request, the script must be executed on the client side and have access to cookies stored on the client.
CSP
To understand CSP (Content Security Policy), we first need to talk about one of the most common web vulnerabilities. We are talking about XSS (cross-site scripting, cross-site scripting).
When performing an XSS attack, an attacker injects unique JavaScript code into the partner side of a website. You might think: “Well, what will this script do? Change the colors of page elements?
Let’s assume that someone has successfully embedded their JS script into the pages of the site you are visiting.
What dangerous things can a script like this do? A lot of things:
- It can make HTTP requests to other sites, pretending you are making them.
- It may redirect you to a place that looks exactly like the one you are logged into but is designed to, for example, steal your credentials.
- It can add <script> tags to pages that contain some JavaScript code or are designed to load some JS files.
- He can add an <iframe> element to the page, which will, for example, look the same as the username and password fields for logging into the site. The actual fields for entering such data will be hidden in this case.
- In reality, the possibilities available to an attacker when they successfully execute an XSS attack are endless.
How does CSP work?
When you click a link or enter a website URL into your browser’s address bar, the browser makes a GET request. The request comes to the server, which sends the browser some HTML code and HTTP headers. To look at these headers, open the Network tab in your browser’s developer tools and visit several sites.
We discussed some technologies that are widely used to ensure the security of web projects. Security issues are critical since they concern everyone connected to the Internet. Especially those who visit sites and leave their bank card details there. The topic of web security is vast, so it cannot be said that after reading a few articles. Someone will become an expert in this field or at least know enough to protect their web project or personal data effectively.
