Very frustrating situation on a pentest I am currently doing - I have found a place where I can inject almost all characters into a piece of javascript from a parameter.

But the web developers seem lucky - the piece of code that I can alter never executes because there is a javascript syntax error before my injection point. Argh!

So I thought I might just end the javascript block by doing </script> and then appending my attack. However - I can't use the / character - just about the only char that is filtered out. Tried a long list of variations but none seem to work. I can manage <&#47;script> but the browser doesn't pick that up as </script>.

Any ideas? Can I tweak something such that my script is executed anyway? Or is there another way to end a block of script, other than </script>? Some other encodings of the / character that I can try? Any help much appreciated. :)

  • What browser are you using? Chrome tends to block XSS's... – Bubble Hacker Jul 7 '16 at 9:54
  • Firefox with XSS protection disabled. – Mark Koek Jul 7 '16 at 9:55
  • 1
    Even if you do not manage to exploit this, you should still report it. What happens when someone fix the error? Relying on syntax errors is not a valid XSS defence strategy... I would say that the finding is just as good (or perhaps I should say bad) even if it is not practically exploitable. – Anders Jul 7 '16 at 10:40
  • 1
    I agree. But a report with a working example is so much more powerful... – Mark Koek Jul 7 '16 at 11:08
  • 1
    Agreed. Accidentally fireing your gun into the ground is a quite different experience from getting shot in the foot, even if it is only pure luck that separates the two. – Anders Jul 7 '16 at 11:15

I am not aware of any way to end a <script> without the presence of </script. (case insensitive, no encoding)

If there is a syntax error anywhere in a particular script, then that whole script will not execute. (of course you seem to already know this, and thus you are trying to insert </script>)

However, this is still serious because it is likely that a future developer will fix that syntax error, unknowingly making a vulnerability out of this injection flaw you discovered.

If however, you caused the syntax error with your own injection (i.e. broken out of quoted string), it is possible that you could resolve it as well before adding your exploit.

  • Thank you for helping me accept that this will not work. :) – Mark Koek Jul 8 '16 at 12:51
  • 1
    I have been fortunate though, have found another place to do the same thing where the syntax error does not occur, and I now have a beautiful working XSS to show off. :)) – Mark Koek Jul 8 '16 at 12:52

Server side:

As a security procedure they encoded the "/" in the "&#47" in order to avoid any directory path traversal or XSS (no luck mate). Try other methods of getting around the "/".

Cheat-sheet: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Client side:

Your browser is having a sort of XSS protection enabled. Try to disable that protection.

  • 1
    No, the server is cutting off the parameter value at / (not including the / itself). So if I give it "12345</script>" it will emit "12345<" – Mark Koek Jul 7 '16 at 10:32
  • 1
    So 'other methods of getting around the "/"', as you say, is what I'm looking for here. :) – Mark Koek Jul 7 '16 at 10:34
  • 1
    As a starting point you can go to: owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet and I also updated the answere :) – Lucian Nitescu Jul 7 '16 at 10:44
  • Thanks! Can't see anything in there that will help me. I even read the formal specs of HTML and XML. And they seem to confirm that I am not going to be able to make this work. An 'end tag' is really defined as starting with a literal </ (hex 3C2F), no tricks. :( – Mark Koek Jul 7 '16 at 11:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.