Securing Cookies Using HTTP Headers
In the previous articles in this series on defending against web attacks using HTTP headers, we have seen the usage of X-Frame-Options and X-XSS-Protection headers. In this article, we will explore using HTTP headers to secure cookies.
Introduction:
Cookies are one of the most sensitive items during a user's session. An authentication cookie is as powerful as a password. Security of these authentication cookies is an important subject. This article demonstrates how we can implement some of the cookie attributes in PHP applications in order to protect cookies from certain attacks.
Cookie protection using HTTP Headers:
HttpOnly:
It is a known fact that, Cross Site Scripting is one of the dangerous vulnerabilities that allows an attacker to steal cookies from the user browser. HttpOnly is introduced to disable the ability to read cookies using external JavaScript. Even if an application is vulnerable to XSS, it is not possible to read cookies when HttpOnly flag is enabled.
Let us launch our sample application we used in the previous articles to see how it can be accomplished.
First, lets look at the headers from the HTTP response.
[plain]
HTTP/1.1 200 OK
Date: Sun, 12 Apr 2015 15:07:14 GMT
Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0
X-Powered-By: PHP/5.6.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=a2ed2bf468dd811c09bf62521b07a023; path=/
Content-Length: 820
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
As we can see, there are no additional flags with the Set-Cookie header and thus an attacker can read this session id if the application is vulnerable to XSS.
In order to avoid this, we can implement HttpOnly flag, which enables us to send cookies only over http protocol but not JavaScript.
Enabling HttpOnly flag in your application:
The sample code snippet below shows a way to set HttpOnly flag in PHP applications.
[php]
<?php ini_set("session.cookie_httponly", "True"); session_start(); session_regenerate_id(); if(!isset($_SESSION['admin_loggedin'])) { header('Location: index.php'); } if(isset($_GET['search'])) { if(!empty($_GET['search'])) { $text = $_GET['search']; } else { $text = "No text Entered"; } } ?>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Admin Home</title>
<link rel="stylesheet" href="styles.css">
</head>
<div id="home">
<center>
</br>
</br>
<form action="" method="GET">
<div id="search">
<text id="text">Search Values</text><input type="text" name="search" id="textbox"></br></br>
<input type="submit" value="Search" name="Search" id="but"/>
<div id="error"><text id="text2">You Entered:</text><?php echo $text; ?></div>
</div>
</form>
</center>
</div>
</body>
</html>
As we can see in the above piece of code, the following line is used to enable HttpOnly.
[plain]
ini_set("session.cookie_httponly", "True");
Let us now observe the headers and see if HttpOnly is enabled. Below are the response headers intercepted using Burp proxy.
[plain]
HTTP/1.1 200 OK
Date: Sun, 12 Apr 2015 15:03:15 GMT
Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0
X-Powered-By: PHP/5.6.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=36cb82e1d98853f8e250d89be857a0d3; path=/; HttpOnly
Content-Length: 820
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
As we can see in the headers above, set-cookie header looks as shown below with HttpOnly flag enabled.
Set-Cookie: PHPSESSID=36cb82e1d98853f8e250d89be857a0d3; path=/; HttpOnly
The real use of this HttpOnly flag is shown below. When an attacker finds an XSS and tries to read the cookies using JavaScript, it won't work.
As we can see in the above figure, the script we executed is unable to read the cookies though the application is vulnerable to XSS.
Secure:
The next cookie attribute is "secure". We often see websites that run on both HTTP and HTTPS. When an application sends its cookies over HTTP, it is possible that they can be hijacked using various ways since they are transmitted in clear text format. "secure" attribute on set-cookie header forces your application to send cookies only over HTTPS.
Below is the code snippet that shows how we can use "secure" flag in PHP applications.
[php]
<?php ini_set("session.cookie_secure", "True"); session_start(); session_regenerate_id(); if(!isset($_SESSION['admin_loggedin'])) { header('Location: index.php'); } if(isset($_GET['search'])) { if(!empty($_GET['search'])) { $text = $_GET['search']; } else { $text = "No text Entered"; } } ?>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Admin Home</title>
<link rel="stylesheet" href="styles.css">
</head>
<div id="home">
<center>
</br>
</br>
<form action="" method="GET">
<div id="search">
<text id="text">Search Values</text><input type="text" name="search" id="textbox"></br></br>
<input type="submit" value="Search" name="Search" id="but"/>
<div id="error"><text id="text2">You Entered:</text><?php echo $text; ?></div>
</div>
</form>
</center>
</div>
</body>
</html>
The following line from the above code enables secure attribute on the cookies.
[plain]
ini_set("session.cookie_secure", "True");
Let's look at the response headers to see how it looks like when the above code is run.
[plain]
HTTP/1.1 200 OK
Date: Sun, 12 Apr 2015 15:14:30 GMT
Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0
X-Powered-By: PHP/5.6.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=f95afc96ecb7acc6c288d31f941e682f; path=/; secure
Content-Length: 820
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
As we can see from the above headers, the secure attribute has been enabled on set-cookie header. In my localhost, I didn't enable HTTPS support for this application. When we refresh the page, since we do not have HTTPS to send this cookie over a secure channel, the session will not be active anymore over HTTP. This is because, this session cookies are not sent to the server because it requires HTTPS.
Killing the session upon closing the browser:
It is quite common for the user to close the browsers without clicking the logout button. When we use sensitive applications, it is necessary that the session has to be expired when we close the browser forcibly without logging out.
The following lines of code can be used in PHP to accomplish this.
[plain]
session_set_cookie_params(0);
session_start();
Assume that we are running the application with the above property set. Now, login to the application and close the browser. If we reopen the page now, the session will be inactive.
To check if this property is enabled or not, we can use a cookie editor like "EditThisCookie" in chrome.
Login to the application and open "EditThisCookie" extension as shown below.
As we can see in the above figure, "Session" is checked. This ensures that our session will not be active upon closing the browser.
The same can also be seen from chrome's developer tools as shown below.
Following are some other cookie attributes
Domain: This attribute gives control on the domains that can access the cookies.
Path: it specifies the path of the domain that can have access to the cookie set by the server.
Expiration: It specifies when this cookie has to be expired. So that the cookie won't be valid anymore.
We can set all these attributes in PHP applications just with three lines of code as shown below.
[plain]
ini_set("session.cookie_secure", "True"); //secure
ini_set("session.cookie_httponly", "True"); //httponly
session_set_cookie_params(3, '/', '.localhost'); //This cookie is valid for 3 seconds (max age)
// “/” ensures that this cookie is valid on all //paths of this domain
session_start();
[/plain]
When we load the page with the above attributes, the response headers will be as shown below.
[plain]
HTTP/1.1 200 OK
Date: Thu, 30 Apr 2015 03:04:11 GMT
Server: Apache/2.2.29 (Unix) mod_fastcgi/2.4.6 mod_wsgi/3.4 Python/2.7.8 PHP/5.6.2 mod_ssl/2.2.29 OpenSSL/0.9.8y DAV/2 mod_perl/2.0.8 Perl/v5.20.0
X-Powered-By: PHP/5.6.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=f4d99777d9810bfedb6869acd556bc66; expires=Thu, 30-Apr-2015 03:04:14 GMT; Max-Age=3; path=/; domain=.localhost; secure; HttpOnly
X-XSS-Protection: 1
Content-Security-Policy: script-src 'self'
Content-Length: 820
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
What should you learn next?
In this article, we have seen how cookies can be secured using various attributes available with set-cookie response header. Though, these concepts can drastically improve the security of a web application, we cant solely depend on those headers to protect an application, rather we should consider using them to add additional layer of security.
In this Series
- Securing Cookies Using HTTP Headers
- Free Valentine's Day cybersecurity cards: Keep your love secure!
- How to design effective cybersecurity policies
- What is attack surface management and how it makes the enterprise more secure
- Is a cybersecurity boot camp worth it?
- The aftermath: An analysis of recent security breaches
- Understanding cybersecurity breaches: Types, common causes and potential risks
- Breaking the Silo: Integrating Email Security with XDR
- What is Security Service Edge (SSE)?
- Cybersecurity in Biden’s era
- Password security: Using Active Directory password policy
- Inside a DDoS attack against a bank: What happened and how it was stopped
- Inside Capital One’s game-changing breach: What happened and key lessons
- A DevSecOps process for ransomware prevention
- What is Digital Risk Protection (DRP)?
- How to choose and harden your VPN: Best practices from NSA & CISA
- Will immersive technology evolve or solve cybercrime?
- Twitch and YouTube abuse: How to stop online harassment
- Can your personality indicate how you’ll react to a cyberthreat?
- The 5 biggest cryptocurrency heists of all time
- Pay GDPR? No thanks, we’d rather pay cybercriminals
- Customer data protection: A comprehensive cybersecurity guide for companies
- Online certification opportunities: 4 vendors who offer online certification exams [updated 2021]
- FLoC delayed: what does this mean for security and privacy?
- Stolen company credentials used within hours, study says
- Don’t use CAPTCHA? Here are 9 CAPTCHA alternatives
- 10 ways to build a cybersecurity team that sticks
- Verizon DBIR 2021 summary: 7 things you should know
- 2021 cybersecurity executive order: Everything you need to know
- Kali Linux: Top 5 tools for stress testing
- Android security: 7 tips and tricks to secure you and your workforce [updated 2021]
- Mobile emulator farms: What are they and how they work
- 3 tracking technologies and their impact on privacy
- In-game currency & money laundering schemes: Fortnite, World of Warcraft & more
- Quantitative risk analysis [updated 2021]
- Understanding DNS sinkholes - A weapon against malware [updated 2021]
- Python for network penetration testing: An overview
- Python for exploit development: Common vulnerabilities and exploits
- Python for exploit development: All about buffer overflows
- Python language basics: understanding exception handling
- Python for pentesting: Programming, exploits and attacks
- Increasing security by hardening the CI/CD build infrastructure
- Pros and cons of public vs internal container image repositories
- CI/CD container security considerations
- Vulnerability scanning inside and outside the container
- How Docker primitives secure container environments
- Top 4 Zapier security risks
- Common container misconfigurations and how to prevent them
- Building container images using Dockerfile best practices
- Securing containers using Docker isolation
- Introduction to container security
Get certified and advance your career
- Exam Pass Guarantee
- Live instruction
- CompTIA, ISACA, (ISC)², Cisco, Microsoft and more!
General security
Free Valentine's Day cybersecurity cards: Keep your love secure!
General security
General security