Introduction to web security

There are many reasons to learn about web security such as:

• You are a user worried about your personal information being leaked.
• You are a web developer who wants to make your website more secure.
• You are a web developer looking for a job, and you want to be ready if the interviewer asks you about web security. …

This article will explain some common terms about web security.

Before getting into the details, first understand the core concepts of security.

Two concepts in security

Nobody is 100% safe

Does not exist the concept is 100% protected from being hacked.

A layer of protection is not enough

You can’t just say …

Oh, because I’ve implemented CSP, I’m safe. I can remove cross-site scripting from my vulnerability list because it cannot happen now.

It may be the thinking of some people, but it’s also easy for you to think in the same way. Security is not simple.

We will start with something that people encounter quite early in their web development journey.

Cross-Origin Resource Sharing (CORS)

Have you ever encountered an error like this?

Search for it on google, some people recommend that you install an extension that can remove all problems.

CORS is there to protect you, not harm you.

To explain how CORS helps you, first talk about cookies, especially authentication cookies . Authentication cookies are used to tell the server that you are logged in, and it will automatically send any requests to the server.

Suppose you log into Facebook, and they use authentication cookies. You click on bit.ly/r43nugi and it redirects you to superevilwebsite.rocks . A script on superevilwebsite.rocks makes a request to facebook.com and superevilwebsite.rocks authentication cookie.

Without CORS, such behavior could change account information without your knowledge, until someone posts with the link bit.ly/r43nugi on your timeline, and all of you Your friends click on that link. And then, the above post is again posted on the timeline of your friends. Such a cycle continues and conquers all Facebook users.

However, with CORS, Facebook can only allow requests with origin facebook.com to edit data on their server. In other words, they can limit the sharing of cross-origin resources. Then you can ask …

Can superevilwebsite.rocks change the origin header in their request and it looks like it came from facebook.com ?

They can try it, but it won’t work because the browser will ignore it and use real origin.

Ok, but what if superevilwebsite.rocks makes a server-side request?

In this case, they may be able to bypass CORS, but cannot send with your authentication cookie. The script needs to be executed on the client side to gain access to your client side cookies.

Content Security Policy (CSP)

To understand CSP, we first need to talk about the most common vulnerability in the web: XSS – cross-site scripting.

XSS is when some bad guy injects Javascript into the client side code. You may think …

What they intend to do? Change color from red to green?

Suppose someone successfully injects JavaScript into the website you visit. What can they do?

• They can make HTTP requests to other websites and impersonate you.
• They may add an anchor tag that takes you to the same web page you are on but is a malicious website.
• They can add script tags with inline JavaScript.
• They can add script tags loaded to the JavaScript code from a certain source.
• They can add an iframe that covers the page and looks like part of the site asking you to enter a password.

There are many other possibilities that can occur.

CSP tries to prevent this from happening by restricting:

• What can be opened in an iframe
• Which stylesheets can be loaded.
• Places where requests are made.

So how does it work?

When you click on a link or type a url into the address bar of the web browser, the browser makes a GET request. The server will process the request and return the HTML along with some HTTP headers. If you want to know what header is returned, inspect your browser and open the Network tab, then access some websites.

You can see the response header looks like this:

That is the content security policy of facebook.com . Try reformatting the paragraph above to make it easier to see:

Now consider the top-down.

• default-src : default policy for loading content such as JavaScript, Images, CSS, Fonts, AJAX requests, Frames, HTML5 Media.
• script-src : defines valid sources of Javascript
• style-src : defines valid sources of stylesheet.
• connect-src : use with XMLHttpRequest (AJAX), WebSocket or EventSource . If not enabled, the browser will return a status code of 400.

There are many other CSP directives other than the ones listed above. The browser will read the CSP header and apply those directives to all HTML files.

Without the CSP header, everything is allowed and unrestricted.

HTTPS or HTTP

You’ve probably heard of HTTPS. Maybe you heard someone say …

Why should I care about using HTTPS if I only visit a gaming site.

You’ve probably heard that Chrome will mark your site as insecure if it’s not HTTPS.

At its core, HTTPS is quite simple. HTTPS is encrypted and HTTP is not.

So why is this important if you’re not sending sensitive data?

If you use public wifi at a cafe without a password, it will be easy for someone to track your requests and responses. If the data is not encrypted, someone can do whatever they want with it. They can edit HTML, CSS, or JavaScript before it is accepted by the browser.

Ok, but how does my computer and server know how to encrypt / decode but MITM (Man in the Middle) does not?

That’s why SSL (Secure Sockets Layer) and more recently TLS (Transport Layer Security) was born. TLS replaced SSL in 1999 when encryption technology was used in HTTPS. How TLS works is beyond the scope of this article.

HTTP Strict-Transport-Security (HSTS)

This is quite simple. Take the Facebook header as an example:

• max-age specifies the time the browser remembers to force users to access websites using HTTPS.
• preload is a service hosted by Google and is not part of the HSTS specification.

This header is only applied when you access the website using HTTPS. If you access the site via HTTP, this header will be ignored.

When you visit facebook.com for the first time, and you know HTTPS is more secure than HTTP, you use HTTPS, https://facebook.com . When the browser receives HTML, it receives the above header and forces you to redirect to HTTPS during the following requests. A month later, a friend sent you a link to Facebook using HTTP, http://facebook.com and you clicked on it. Because 1 month is less than 15552000 seconds specified by max-age , the browser will send requests using HTTPS, preventing MITM attacks.

summary

Web security is important no matter where you are on your web development journey. The more you expose it, the better it gets for you.

Refer

https://medium.com/free-code-camp/a-quick-introduction-to-web-security-f90beaf4dd41