Cross-Site Scripting flaws are quite unexciting from the technical point of view. Don't you think?
Most of the time, it is not challenging to look for XSS vulnerabilities since lot of applications do not provide input validation at all against this specific attack. In addition, the application entry points are so copious that it is like to shoot in a crowded square (well, never tried).
However, they still exist and we still have to report them.
We will probably all agree about the dangerous effects of such client side attack. We have seen several real life threats (e.g. CriticalPath Vulnerability, Twitter Worm Attack, StrongWebmail) as well as we know efficient (sufficient?) protection mechanisms (e.g. NoScript, OWASP ESAPI, Secure Coding).
Having said that, I would like to point out a couple of trivial security flaws I have discovered in the last months: (A) Sun Java Web Console Multiple Cross Site Scripting and yet another (B) Oracle Application Server 10g (v9.x) Cross Site Scripting.
(A) Just because I believe in full disclosure, let's specify the unspecified input (as reported by the vendor). Due to the lack of input filtering within the "HELP" resources, it is possible to inject JS code and trigger XSS attacks. During my audit, several attack vectors were found:
/console/faces/com_sun_web_ui/help/helpwindow.jsp
Parameters: windowTitle, helpFile, pageTitle, mastheadUrl, mastheadDescription, jspPath
/console/faces/com_sun_web_ui/help/masthead.jsp
Parameters: mastheadUrl, pageTitle
PoC example: https://IP:PORT/console/faces/com_sun_web_ui/help/helpwindow.jsp?&windowTitle=&helpFile=%22%3E%3C/FRAMESET%3E%3CFRAME%20SRC=%22javascript:alert(%27XSS%27);%22%3E%3C!--
(B) In case of OC4J, the problem is triggered with malformed requests containing invalid HTTP methods.
G<script>alert(123);</script>ET /servlet/ HTTP/1.1Versions 10.1.3.4.0 and likely all the 10.x releases are not vulnerable.
Host: 127.0.0.1:5500
501 Not Implemented
Method G<script>alert(123);</script>ET is not defined in RFC 2068 and is not supported by the Servlet API
Oracle support for the J2EE application container 9.x ended in December 2008, according to the Oracle's Lifetime Support Policy. However, they still provide this insecure software here. From my experience, I've seen several installations of such outdated and unsupported software within corporations. As you can easily imagine, it means no patch...sad indeed.
4 comments:
July 23, 2009 at 1:54 AM
Actually, I would have said it the other way around, damage caused aside, straight xss flaws are just as boring as your typical stack based buffer overflow, but xss flaws can and do get more interesting if you simply pretend those bugs don't exist and try to look for other problems :p
What most people can't agree on is what the impact is, how useful they are at being used against specific targets, especially those that aren't social networks, etc.
In any case, I don't see how the OC4J issue is an xss issue, from what I know of browsers, there is no way to force such a request to be sent and the response then _rendered_ by a browser. Hence there is no xss.
To draw some parallels before you get the chance (:p), I realise that in some cases we assume that an exploit couldn't be crafted, even if we cannot, and we cry foul when exploitable bugs are classed as DoS, this is based on previous experience with the intricate and maleable nature of memory corruption exploits (and many people's failure to grasp that when std. techniques do not work it doesn't mean it's not exploitable), and a wide array of examples where supposedly non-exploitable bugs were exploited.
However, to exploit the OC4J 'bug', we would need a way to specify an arbitrary method name cross-domain and have the result rendered. Now, given that this functionality does not exist in any well known places (browser js, flash, java), we can probably assume it's hidden away somewhere unaudited. In which case, we can probably agree that it will allow TRACK/TRACE requests, in which case, you just throw your payload into the URL component and it will come back unfiltered, viola.
Does that mean TRACK/TRACE is a bug? Ok this is subjective, but I think: No it means browsers/whatever shouldn't be letting people make such requests.
Also, since I'm not a sysadmin, just a hacker, if you can't make an exploit out of it, it's useless.
Now that I've gotten off my soapbox, I hope you can pull out some tricks to make an exploit out of your bugs and prove me wrong :p
July 28, 2009 at 5:27 AM
XSS flaws, per se, are boring. The exploitation of such flaws is interesting and challenging indeed.
Even if I tend to agree that there's no way (as of today) to exploit such finding, I disagree with a few other things.
Actually, using proprietary ActiveX Objects (e.g. Msxml2.XMLHTTP.3.0), we can easily specify an arbitrary HTTP request method (including our payload) as well as we can read data back. Due to the same origin policy for XMLHttpRequest, we still require a cross-domain flaw in order to exploit the finding. Fortunately, browser bugs may help us.
Even if the XSS requires the same pre-conditions as for exploiting the TRACE method, I don't fully agree with the parallel. The TRACE method is a server-side configuration that can be easily disable. It is considered an insecure HTTP method thus best practices suggest disabling it. This is rather a bug. It may be not so easy to fix it and a patch is likely required (e.g. the default response page is hardcoded).
Besides the specific OC4J issue, it is worth to mention that it is important to disclose such kind of flaws (XSS, XST, ...). It's time consuming or maybe lame but it makes sense for a couple of reasons. First of all because we need complete knowledge bases in our automatic tools (e.g. Nikto), which makes our job less painful. This is especially true if you have to audit several systems a day. Moreover, the web technologies are changing all the time and we cannot ensure the non-exploitability of some issues. As you know very well, it is just a matter of time before the next weak technology will appear.
See ya in the next sec conference. Cheers!
September 12, 2015 at 3:56 AM
September 12, 2015 at 3:56 AM
Post a Comment