At my work, we have a policy of using HP's WebInspect to scan our applications before they are allowed to go into production and I just got an interesting finding this week. The WebInspect scanner tried to perform a XSS (cross site scripting) attack by putting something into the HTTP header's Accept Language! Now, I'm not really sure how exploitable this is (perhaps some security expert can comment?) since all our traffic is via https, so there's really no way to inject some scripts into the http header unless the host machine making the request has been compromised?
This was the http request used....
and the end result was this....
Anyways, I was tasked with checking this out. After some digging, I found that the html tag in our application was being generated by the struts taglib's html tag. According to the specifications, it seems that the lang attribute of the html tag has the following behaviour...
So with the Accept-Language not being validated for special characters, we were getting XSS-ed!
The solution? In this case, we used a filter to provide a default locale into the user's session if non is detected to avoid using the Accept-Language in the HTTP header. This may not be the best or most correct solution, but it is one that fits our needs and timeline.
This was the http request used....
GET /programmingPanda/someUrl.jsp HTTP/1.1
Accept: */*
Referer: https:///programmingPanda/someUrl
Accept-Language: "><script>alert('hi')</script>
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Host: www.programmingPandaHost.com
Pragma: no-cache
Connection: Keep-Alive
Cookie:
JSESSIONID=0021w1Z_9Fg27Vg1xhKHDgX1YLR:1244ioqb0;CustomCookie=WebInspect30127ZXC16B0
44F25944608B21BBFFEC74B3453YE540
and the end result was this....
<html xmlns:"http://www.w3.org/1999/xhtml" lang=""><script>alert('hi')</script>" xml:lang=""><script>alert('hi')</script>">
Anyways, I was tasked with checking this out. After some digging, I found that the html tag in our application was being generated by the struts taglib's html tag. According to the specifications, it seems that the lang attribute of the html tag has the following behaviour...
Renders a lang attribute with the locale stored in the user's session.
If not found in the session, the language from the Accept-Language HTTP header is used.
If still not found, the default language for the server is used.
So with the Accept-Language not being validated for special characters, we were getting XSS-ed!
The solution? In this case, we used a filter to provide a default locale into the user's session if non is detected to avoid using the Accept-Language in the HTTP header. This may not be the best or most correct solution, but it is one that fits our needs and timeline.
//provide some default locale and set it into the struts defined attribute, Globals.LOCALE_KEY
session.setAttribute(Globals.LOCALE_KEY, locale);
great