2

I have a reflected XSS vulnerability in my Web application. I have decided to take the black-list approach instead of the popular white-list approach.

My question is can there exist a malicious javascript call without opening parenthesis(\u0028) and close paranthesis(\u0029)?
By malicious, I mean something that can impact the user.
If your answer is YES, then please give an example code that can be injected into an XML.

  • Interesting solution to prevent function calls. :-) location.href = "..." for example, or document.cookie = "...". If it is possible to add <script> then everything is possible. If it is possible to add data URL, then everything is possible with a javascript content type at least in firefox... – inf3rno Jun 5 '14 at 12:20
  • 3
    Blacklisting should never be considered as solution, take a look how Filter Evasions exist: owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet – D. Schalla Jun 5 '14 at 12:40
  • inf3rno, you have suggested good examples but how are you going to execute these scripts. You need to use a "(&quot;) followed by some code to actually execute a document.cookie. I am preventing XSS via XML injection. Correct me if I am wrong. – KatariaA Jun 5 '14 at 12:47
  • Why not just use an actual content filtering function from your web language? Or OWASP's filter engine? – Polynomial Jun 6 '14 at 7:16
  • Ploynomial, Please give me a link – KatariaA Jun 6 '14 at 13:39
3

I found some weblinks which may give you an answer:

http://www.thespanner.co.uk/2012/05/01/xss-technique-without-parentheses/

http://blog.cinu.pl/2013/07/xss-parentheses-and-brackets-filter.html

Let me conclude the answers:

<img src="fileThatDoesNotExist" onerror="javascript:window.onerror=alert;throw 'XSS'" dummyParam=""; ?> >

or

<img src="fileThatDoesNotExist" onerror="location.href='data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD4='" dummyParam=""; ?> >

However, you can see that Blacklisting doesn't work. The XSS Filter Evasion List shows tons of possibilities how to trick a filter. You should rather escape the input proper.

  • These links are extremely useful. I am still trying to get any one of them to work as the payload can only be inserted in request in an semi-encoded format. – KatariaA Jun 6 '14 at 6:40
1

Apart from the JavaScript examples which have already been mentioned, parentheses can also be hidden with different encodings of both XML and JavaScript.

But even if nobody knew how to bypass your filter, that wouldn't prove anything. It could simply be a lack of knowledge or creativity on our part. Who knows all crazy JavaScript features and browser quirks?

Blacklisting simply isn't the answer. Many smart people tried it and thought they had finally written the perfect XSS filter, but then an even smarter attacker came along and proved them wrong. It's an infinite arms race.

As tempting as it may be to accept the challenge, it's much better to avoid it. Simply don't allow your users to inject any JavaScript code, and you won't have to worry about finding the bad parts.

  • My application does not allow users to insert javascript code. I am preventing XML injection where an attacker is intercepting the request and inserting an encoded payload. – KatariaA Jun 6 '14 at 6:37
1

As the others said, it is not as simple as blacklisting. Code obfuscation can get past it. I don't really feel like showing an example being that I'm not that great with JavaScript. Also, there are lots of nasty tricks to bypass these filters. If you have the time would suggest reading XSS injection: Attack and Defense.

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.