During a bugbounty hunt Sebastian discovered a script-context XSS with the injection point being a string. As you know, all modern browsers like Firefox, Chromium, IE automatically encode the apostroph. However, this issue still remains exploitable.
1 2 3
The value of a parameter - let’s call it
';+alert(1)+', because all other approaches should fail. (If you know a cool bypass, please let us know :)) If you want to play around with an example take a look at our challenge. Sebastian wrote a small webserver in python which simulates the situation.
Most modern browsers (afaik FF, Chrome, IE, but not Safari) encode the apostrophe automatically due to security reasons. This bugs usually bughunter, because an application seems to be secure (to the vendor), but in real it’s still exploitable in some browsers.
You can easily check if you’re browser does automatically encode the apostrophe with the following two steps (in the console):
nc -l -p 1337first
- Connect to
1 2 3 4 5 6 7 8
As you can see, the apostrophe changed from
%27. ( int(0x27) = 39 = apostrophe’s position in ASCII table)
The RFC 1738 states that the apostrophe doesn’t need to be encoded by default, because it isn’t a reserved URL-character.
Thus, only alphanumerics, the special characters “$-_.+!*’(),”, and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
Taking a look at this bugreport @ Mozilla the developers argued that this “feature” would add another layer of security by preventing “apostroph”-based XSS attacks.
Next time you come across a XSS like this and the webapplication does not automatically decode the apostrophe for you, don’t forget that there might be other browsers in which the issue remains exploitable.
We thought it’d be a nice idea to make a comprehensive list about which browsers do (not) encode the apostroph automatically.
If you know/discover any other browsers, please send a small tweet @internetwache and we’ll update the list :)
- IE (>=11)
the team of internetwache.org