9. Front End Security Basics: Secure Cookie Flag

August 6, 2020 Amal Mammadov

1. VULNERABILITY INTRODUCED

Properly implemented data protection is an essential component of the security of any web application. It allows the users to know who they are communicating with, whether or not their communication channel is encrypted, and that the data is not manipulated in transit.
Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive data transmitted through the network. For example, when HTTP protocol is used, the traffic (including cookies) is sent in plain text. It allows the attacker to see and modify the traffic, performing a man-in-the-middle attack. A secure version of HTTP – HTTPS – uses SSL/TLS to protect the data of the application.
Cookies often contain sensitive information like session identifiers and must be secured. To secure a cookie during the transmission, it’s usually sent encrypted using HTTPS. To ensure the cookie is sent only via the secure connection, a Secure flag should be used. But what could happen if the flag is not set?

2. VULNERABILITY EXPLAINED

Let’s consider an example where the attacker can take advantage of the fact that the site is available over both HTTPS and HTTP, and send the link to the HTTP version of the site to the user. The user clicks the link, and the HTTP request is sent. Since HTTP traffic is transmitted in plain text, the attacker eavesdrops on the communication channel and reads the authentication cookie of the user.
Even if the website explicitly uses HTTPS and redirects the user to HTTPS version of the site, the initial HTTP request would contain that user’s cookies, and, if the user was authenticated, may allow the attacker to steal the user’s session.
Or, if an attacker is aware of some popular website that is missing the Secure flag, they may attempt to intercept any HTTP requests the users make to other websites and send an HTTP redirect to that vulnerable popular website in response, ensuring the cookie leaks when the user’s browser tries to follow the redirect.

3. SETTING UP THE ENVIRONMENT

Bob is an attacker. He opens up a malicious hotspot in an airport and bridges it to some internet connection. Passengers looking for free WiFi see Bob’s hotspot, connect to it, and begin browsing the web while Bob-the-attacker reads all the traffic conducting the Man-in-the-Middle attack.
Bob knows that a popular social network FriendsList doesn’t set the Secure flag to its cookies, so Bob wants to take a chance to steal someone’s authentication cookie. He analyzes the traffic that is going through his hotspot with a Proxy tool, looking for a4. EXERCISE BACKGROUND

The vulnerable application pane loads the FriendsList.me website, a popular social network where people communicate with each other and share content. It is available over HTTPS, but unfortunately, the authentication cookie for the application doesn’t have a Secure flag set in server settings.
Alice is a legitimate user of the FriendsList website. She is making a business trip and wants to check her account to read her friends feed. After finding a nice free hotspot in the airport, she opens the application at https://friendslist.me.
Enter the following credentials to sign in as Alice:
Email: [email protected]
Password: 12345!

ny kind of HTTP requests to which he can send a specially crafted malicious response.

Alice is successfully redirected to her HTTPS-served FriendsList.me page. She gets the following response from the server with an authentication cookie:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: sessionid=8cec3cea-8c0b-466d-8c34-c79b0f849a97;

5. NORMAL FLOW

After the FriendsList page opens, Alice starts reading her favorite group: “GoT lovers”. There she sees a link to the quiz Which Game of Thrones Character Are You? and browses to the corresponding website to pass the quiz. This site works over HTTP.

As Alice, click the link to go to the QuizMonster web page.

5. NORMAL FLOW

When Alice clicks the link, the web page with the quiz opens in a new window and loads as expected.

6. VULNERABILITY DETECTED

In the meantime, Bob notices that from the same IP address there were requests to https://friendslist.me first, and after that to http://quizmonster.com. This is a great opportunity to steal the cookie!
Bob crafts an HTTP response that redirects user’s browser to the http://friendslist.me website. Then he returns this response to the owner of that IP instead of the response from http://quizmonster.com.

ACTION

Help Bob create a malicious payload. Click ADD to paste the following response into the Proxy window.
HTTP/1.1 301 Moved Permanently
Date: Thu, 10 May 2018 09:14:11 GMT
Content-Length: 0
Connection: close
Location: http://friendlist.me

7. VULNERABILITY EXPLOITED

After Alice’s browser receives this malicious redirect response, it tries to connect to the server provided and sends the HTTP request to http://friendslist.me along with all the cookies for the FriendsList website, including the authentication cookie.
Bob sees this request in his Proxy tool, and now he has Alice’s cookie and can impersonate her in interactions with the https://friendslist.me website!

8. ATTACK EXPLAINED

This attack was made possible because the Secure flag was not set for the authentication cookie.
After Alice’s browser receives this cookie via the SSL/TLS-secured connection from the https://friendslist.me server, it continues sending it with all requests to this server, even if the protocol changes to http://friendslist.me.
If this flag is enabled, then the browser will never send the cookie via an unencrypted connection.
When a server sets a Secure flag for the cookie it looks like this in a server response:
Set-Cookie: SessionId= LcD2GAkviCs5RiG7qtaOUsETKYNEqcXf; Path=/; Domain=.mydomain.com; Secure; HttpOnly
And after Alice’s browser receives redirect response from Bob, it would send a request to that redirect website without a secured cookie.

Source, Destination, Protocol, Info

180.256.13.51, 208.97.315.10, DNS, https://friendslist.me

180.256.13.51, 208.97.315.10, TLS, Application data

208.97.315.10, 180.256.13.51, TLS, Application data

180.256.13.51, 208.97.315.10, TLS, Application data

208.97.315.10, 180.256.13.51, TLS, Application data

180.256.13.51, 208.97.315.10, DNS, http://quizmonster.com

180.256.13.51, 208.97.315.10, HTTP, GET /quiz.php?name=GoT HTTP/1.1

…

Response from http://quizmonster.com:80/

HTTP/1.1 301 Moved Permanently

Date: Thu, 10 May 2018 09:14:11 GMT

Content-Length: 0

Connection: close

Location: http://friendslist.me

…

Request to http://friendslist.me:80/

GET / HTTP/1.1 Host: friendslist.me User-Agent: AlicesBrowser Connection: close

9. REMEDIATION

To mitigate the vulnerability, enforce strict HTTPS on all application components to ensure nothing is usable without HTTPS and set the Secure flag for all user cookies.
You may also consider setting HTTP Strict Transport Security (HSTS) policy that prevents user’s browser from accessing the website via unsecure connection and thus from being manipulated by some malicious party.
Once a browser that supports HSTS receives the Strict-Transport-Security header returned in HTTPS response (if it will be returned over HTTP, the browser will ignore it), it will only issue subsequent requests to that site over the HTTPS protocol.
HSTS policy has several directives:

max-age directive sets a time frame in seconds during which the browser will automatically translate any HTTP requests into HTTPS versions for the same website.
includeSubDomains directive spreads HSTS policy to all subdomains of the website.
preload directive notifies the browser that the site is in the HSTS preload list.

Source, Destination, Protocol, Info

180.256.13.51, 208.97.315.10, DNS, https://friendslist.me

180.256.13.51, 208.97.315.10, TLS, Application data

…

Response from https://friendslist.me:443/ HTTP/1.1 200 OK Strict-Transport-Security: max-age=31536000; includeSubdomains; preload