When encoding saves the day
Out of most penetration tests I do, XSS vulnerabilities are still probably the most common ones we encounter (if I don’t count missing Secure and HttpOnly flags on cookies :)).
Even web application vulnerability scanners have become increasingly successful in finding XSS vulnerabilities so the next question (besides why do we still see them) is related to their exploitation.
I recently encountered a simple, but interesting XSS vulnerability, which demonstrated yet again how standardization is important. So, let’s see what this is about.
The vulnerability in question is a very simple reflected XSS vulnerability where contents of a user supplied parameter from a GET HTTP request are copied directly into the resulting HTML.
However, there was a simple catch – here is what the resulting HTML code looks like and where the user supplied parameter is injected:
...
form action="/myform/action/post" id="myform" method="post" name="myform"
...
The contents of the injected parameter are highlighted in the HTML code shown above (also there should be < at the beginning and > at the end of the line, but ISC diary editor is giving me issues so just imagine those two characters). So, when the user submits a GET HTTP request such as this one:
GET /myform/action/post?myparam=123
The vulnerable application creates the following HTML code:
...
form id="myform" action="/myform/action/post?myparam=123" method="post" name="myform"
...
Ok – hopefully all of you see where this is going to. If we insert the " character we will close the action parameter and are practically free to do whatever we want. If we can insert the > character it’s game over.
The vulnerability shown is very simple and in most cases even web application vulnerability scanners will detect is as such.
So what’s the story here you might ask? Well, the tricky thing is in getting the victim to click on a link which will exploit the vulnerability. Remember how we need to send the " character? Well, that turns out not to be all that straightforward with modern browser. If our attacker link looks like this:
http://www.vulnerable.application/myform/action/post?myparam="> Test
the browsers will send the following GET requests (you can test it with your own browser easily):
Mozilla Firefox: GET /myform/action/post?myparam=%22%3E%20Test
Google Chrome: GET /myform/action/post?myparam=%22%3E%20Test
Internet Explorer: GET /myform/action/post?myparam=">%20Test
Say whaat (insert image from Anchorman 2 here)? Interesting! So, in other words, Internet Explorer is the only browser (of those three I tested) that will not encode the "> characters. This effectively allows the attacker to launch a reflected XSS attack against Internet Explorer users, while those using Mozilla Firefox and Google Chrome will be safe(r)! (so Internet Explorer is indeed less secure ….. /me ducks).
Jokes aside, why is this happening? In order to dig that out we need to check URI syntax, which is specified in RFC 3986 (https://tools.ietf.org/html/rfc3986). The RFC splits characters into several groups: unreserved characters ( ALPHA / DIGIT / "-" / "." / "_" / "~" ), reserved characters ( ":" / "/" / "?" / "#" / "[" / "]" / "@" and "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=) and all the others.
We can see that ", < and > are in neither of the lists above! However, the RFC says the following:
“When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent-encoded.”
One would probably read this as the following: *everything* apart from unreserved characters should be encoded. However, while reading the RFC I missed what really “a new URI scheme” is?
In any case, it looks as Internet Explorer developers decided that they will strictly encode only reserved characters (plus some extras), but they left couple of important ones such as ", < and >.
I had a lively discussion with my colleague Marin about reporting such vulnerabilities in penetration tests. Our conclusion was to always report it (of course), even though exploitability might be more or less difficult (or even impractical) with some browsers – the underlying vulnerability is still here and should be fixed.
How does your browser behave? Let us know!
Comments
Anonymous
Dec 3rd 2022
10 months ago
Anonymous
Dec 3rd 2022
10 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
9 months ago
Anonymous
Dec 26th 2022
9 months ago
https://defineprogramming.com/
Dec 26th 2022
9 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
9 months ago
rthrth
Jan 2nd 2023
9 months ago