Web Frontend Security: Episode 1

İçindekiler [göster]

In this post series, I’ll explain some of the most common attack methods used on web frontend and how to take precautions to prevent them. It contains an overview of frontend security related things that every web developer needs to know by heart. I will explain terms like XSS, CSRF, clickjacking, CSP, HSTS, JWT, HTTP-Only Cookies.

In this particular post, I’ll focus on the security issues that are caused by improperly established secure transport. So let’s get started!

What is a “web frontend” and why security awareness is essential

A frontend is the “customer facing” end of a product where the customer might be mass consumers or a department in a company or one single person. “Web Frontend” is a frontend product that is exposed in a web interface. Other frontends could be a mobile application, a public API and so on…

A secure product must make sure that everyone can see what they should’ve seen and execute commands that only they are allowed to. Security must always be an ongoing progress across the whole product. You can’t add “security” later, you have to bake it in.

Web Frontend, being a part of a larger product also needs to be secure. It needs to be implemented in a way where it doesn’t leak users’ data to others or execute not requested commands.

In my belief, every engineer across an organization has to be educated against common attack methods. “Being awake against misuses” should be a cultural thing in engineering teams.

Okay, I admit: This section was a little bit academic, I promise that the upcoming section is more exciting. %-)

Attacks caused by lack of properly established secure transport

Security is an end-to-end task. You need to be sure that your frontend communicates to the backend using a secure channel.

Using HTTPS

HTTPS is a secure transport protocol, where the contents of a request and response are encrypted end-to-end between the client (your frontend) and the host (your backend). In this post, I won’t explain the details of how it works. I’ll try to “go around” of it.

When a user types a web address starting with https:// the communication is done securely.

But what if I just type the site name?

The thing is people don’t always type the full address. It is common to type duckduckgo.com instead of https://duckduckgo.com. And there are a large number of websites still serve their content on both http and https, both unsecured and secured connection work in parallel. We have a vulnerability over here!

Redirecting http to https

A naive approach to overcome this vulnerability is to redirect http pages to their https equivalents via HTTP 301 Moved Permanently. This way, if someone ends up with http, they will be “upgraded”.

Imagine that at some point you had logged into the website at example.com and checked “remember me”. They issued you a cookie named token which expires in one month and helps them identify you.

At an airport, you tried to reach http://example.com on your machine and sent a request like this:

GET / HTTP/1.1
Host: example.com
Cookie: token=SECRET_HASH_THAT_IDENTIFIES_USER;

and example.com redirected you to “secure” protocol, https:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com

In your second request, you reached to https://example.com making the communication secure.

Don’t forget to take that free unsecured airport Wifi into account…

When you reached http://example.com you were at the airport, connected to the free-wifi. So does the guy next to you: Listening to all network packages in the wifi network, intercepting and reading all contents of the web pages transferred via http. Although you “upgraded” to https in your very second request, the first and insecure request contained token=SECRET_HASH_THAT_IDENTIFIES_USER and it is served in a golden plate to the guy that listens to the traffic. Now, he can use this token and to access to example.com logged in as you… ????

Secure Cookies

A solution to overcome “unsecured credential transfer” would be to send cookies only when the connection is secure. In this scenario, example.com sends a Secure cookie, so it won’t be sent unless the connection is over HTTPS.

At the airport when you reach http://example.com this time, your request will not include sensitive credentials:

GET / HTTP/1.1
Host: example.com

and you’ll be upgraded to https version:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com

where you start sending cookie this time, as it is secure:

GET / HTTP/1.1
Host: example.com
Cookie: token=SECRET_HASH_THAT_IDENTIFIES_USER;

Looks secure. The guy that listens to the network won’t be able to steal your cookie.

But…

HTTP responses can be altered

In an insecure network, a man in the middle can intercept and return a tampered, modified version of the response back to you. In our scenario, let’s assume that the guy that listens to the network tampers with the http responses and returns whatever he wants to return back.

In this scenario when you reach http://example.com, instead of getting the genuine response back (which is a redirect), you get the response back from “the guy that listens”:

HTTP/1.1 200 OK

He sent you a well prepared, genuine looking web page, where he asked for your username, password. You typed them and sent them directly to the attacker. You never got the upgrade to HTTPS and you didn’t even notice it… Don’t forget:

Even a single insecure request can be enough to steal the data!

HTTP Strict Transport Security (HSTS)

HSTS is an HTTP header which tries to overcome the problem explained above. By sending an HSTS header over a secure connection, you can tell the browser that you always expect a secure connection and tell the browser to upgrade automatically from now on, even if user types http:// explicitly.

In our scenario, as we had logged in beforehand, we at least reached to example.com before heading to the airport once. At that moment, example.com sent the following header to us:

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

Thanks to this header, the browser is aware of security precautions. At the airport, when the user tries to reach http://example.com browser upgraded it to https automatically. The guy that listens to the network didn’t have a chance to intercept as no insecure communication done.

Still, the first request is not secured…

HSTS helps us a great deal mitigating man in the middle attacks. However, HSTS header needs to served once over HTTPS to be effective. If we reach example.com for the first time at the airport, a man-in-the-middle attack is still possible as HSTS header is not effective yet.

HSTS Preloading

Google maintains an HSTS preload service which is used by all major browsers. The list contains websites that need to be reached via HTTPS only. By taking advantage of the list browsers remove need to receive HSTS header from the website itself. Therefore, even for the first reach to http://example.com communication can be upgraded to https://example.com due to the implicit knowledge of the browser about the HSTS requirement of the example.com. This eliminates man in the middle attack, even for the first reach. However, HSTS preloading is not part of the HSTS specification so it is not a standard.

You can check if your website is HSTS Preload enabled and apply for it on this website.

Wrapping Up – Recommendations

Know what you are doing.
Keep reading about HTTP, HTTPS and other protocols that the Internet mostly relies on.
Assume the worst and be prepared for man in the middle attacks.
Be sure that all data transport is encrypted. If you transfer the data from end-user to CDN via HTTPS and from CDN to the backend via HTTP it will only look secure.
Educate employees about security and work with people that care about security.
Don’t try to add security later. It should be built-in.
Don’t let urgency to deliver new features beat the urge to think and design security!