Defending against web attacks with HTTP headers

Brief introduction

Cookies are a very important thing in a user session, and an authenticated cookie is the equivalent of a password. Protecting these authenticated cookies is a very important topic. In this article, we will demonstrate how to implement certain cookies in PHP applications to protect our cookies in certain attacks.

Protect cookies with HTTP headers

This is a known fact that a cross-site scripting attack is a very dangerous vulnerability that could allow an attacker to steal cookies from a user's browser. The introduction of HttpOnly can disable external JavaScript scripts to read cookies. Even if an XSS vulnerability exists in the application itself, cookies cannot be read as long as the httponly tag is turned on.

Now we'll open the simple application that we used in the previous article.

First, observe the header information in the HTTP response

http/1.1 Okdate:sun, APR 15:07:14 gmtserver: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.0x-powered-by:php/5.6.2expires:thu, 19 Nov 1981 08:52:00 Gmtcache-control:no-store, No-cache, Must-revalidate, post-check=0, Pre-check=0pragma: no-cacheset-cookie:phpsessid=a2ed2bf468dd811c09bf62521b07a023; Path=/content-length:820keep-alive:timeout=5, max=100connection:keep-alivecontent-type:text/html; Charset=utf-8

As we can see, there is no extra tag in the Set-cookie header. If an XSS vulnerability exists in the app, the attacker can easily access the cookie information.

To avoid this situation, we can use the HttpOnly tag. This allows us to send cookies only via the HTTP protocol, not JavaScript.

Enable HttpOnly tagging

One way to enable the httponly tag in a PHP app is shown in the sample code snippet below:

Admin Home
Welcome to Dashboard ...
You is logged in as:
[Logout]
Search Values
You entered:

From the code snippet above we can see that the following line of code is used to open the HttpOnly:

Ini_set ("Session.cookie_httponly", "True");

Next we'll take a look at the HTTP header information obtained after the HttpOnly tag is opened

http/1.1 Okdate:sun, APR 15:03:15 gmtserver: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.0x-powered-by:php/5.6.2expires:thu, 19 Nov 1981 08:52:00 Gmtcache-control:no-store, No-cache, Must-revalidate, post-check=0, Pre-check=0pragma: NO-CACHESET-COOKIE:PHPSESSID=36CB82E1D98853F8E250D89BE857A0D3; path=/; Httponlycontent-length:820keep-alive:timeout=5, max=100connection:keep-alivecontent-type:text/html; Charset=utf-8

In the above information we can see from the Set-cookie header information that has been successfully opened HttpOnly

SET-COOKIE:PHPSESSID=36CB82E1D98853F8E250D89BE857A0D3; path=/; HttpOnly

The effect of the HttpOnly tag is as follows, and when an attacker exploits an XSS vulnerability, attempts to read cookies using JavaScript scripts are not executed.

From what we can see, we can't read cookies by executing scripts, even if there is an XSS bug!

Secure tag

Another cookie attribute is "Secure", and we are often able to see a website that has both HTTP and HTTPS protocols. When the app transmits its cookies over HTTP, the attacker can hijack the information in a variety of ways because of the use of the plaintext transmission. The "Secure" attribute is also set in the Set-cookie header, which ensures that all cookies are transmitted only through the HTTPS protocol.

One way to enable secure tagging in a PHP application is shown in the sample code snippet below:

Admin Home
Welcome to Dashboard ...
You is logged in as:
[Logout]
Search Values
You entered:

From the code snippet above we can see that the following line of code is used to open secure:

Ini_set ("Session.cookie_secure", "True");

Let's take a look at the HTTP Headers that was obtained after the code was executed.

http/1.1 Okdate:sun, APR 15:14:30 gmtserver: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.0x-powered-by:php/5.6.2expires:thu, 19 Nov 1981 08:52:00 Gmtcache-control:no-store, No-cache, Must-revalidate, post-check=0, Pre-check=0pragma: no-cacheset-cookie:phpsessid=f95afc96ecb7acc6c288d31f941e682f; path=/; Securecontent-length:820keep-alive:timeout=5, max=100connection:keep-alivecontent-type:text/html; Charset=utf-8

From the header information above, we see that the secure property has been successfully enabled. My localhost does not turn on HTTPS support, and when I refresh the page, there is no HTTPS protocol support for cookies that do not pass the secure channel, and the session does not pass through the HTTP protocol. This is because the session is not sent to the server because the HTTPS protocol must be available.

Close the browser end session

It is common for users to not click the Logout button before closing the browser. When we are using a sensitive app, it is necessary to force the logout of cookies when we close the browser.

The following two lines of code can implement this procedure in PHP

session_set_cookie_params (0); session_start ();

Let's say we run a page that sets the properties above. Login to the app and close the browser, if we reopen this page, the session will not be active.

In order to detect whether this property has been successfully enabled, we can use a cookie editor like "Editthiscookie" in the Chrome browser.

Login page and enable Editthiscookie extension

For example, by ticking the session option, this will ensure that our session will not remain active after the browser is closed.

We can also set up in Chrome's developer tools

The following are some of the other properties of cookies

Domain: This property controls which cookies have access to domains

Path: Specifies the path to the domain that the cookie can access

Expiration: This property specifies that the cookie will no longer be available after it expires

You can add these three attributes to your PHP application with just 3 lines of code:

ini_set ("Session.cookie_secure", "true");//secureini_set ("Session.cookie_httponly", "true");// Httponlysession_set_cookie_params (3, '/', '. localhost ');
This cookie was valid for 3 seconds (max Age)//"/" ensures the this cookie was valid on all//paths of this domain//sin Ce the domain is prefixed with dot, this
Cookies are accessible from the subdomains. Session_Start ();

Reload the page to see the response header

http/1.1 Okdate:thu, APR 03:04:11 gmtserver: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.0x-powered-by:php/5.6.2expires:thu, 198 1 08:52:00 gmtcache-control:no-store, No-cache, Must-revalidate, post-check=0, Pre-check=0pragma:no-cacheset-cookie: PHPSESSID=F4D99777D9810BFEDB6869ACD556BC66;
Expires=thu, 30-apr-2015 03:04:14 GMT;
max-age=3; path=/; Domain=.localhost; Secure Httponlyx-xss-protection:1content-security-policy:script-src ' self ' content-length:820keep-alive:timeout=5, max= 100connection:keep-alivecontent-type:text/html; Charset=utf-8

In this article, we learned how to use HTTP headers to defend our cookies. While these headers can help us improve the security of our web applications, we cannot rely entirely on these headers to protect our web security, and we should consider adding additional layers of security.

This article is from the "Phenex" blog, make sure to keep this source http://phenex.blog.51cto.com/10579566/1680772

Defending against web attacks with HTTP headers