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.
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
example.com redirected you to “secure” protocol, https:
HTTP/1.1 301 Moved Permanently
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… ????
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
and you’ll be upgraded to
HTTP/1.1 301 Moved Permanently
where you start sending cookie this time, as it is secure:
GET / HTTP/1.1
Looks secure. The guy that listens to the network won’t be able to steal your cookie.
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
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.
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!
In next part, I plan to mention about CSRF. Stay tuned!