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.

Improve this question
5
  • 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
    Commented Jun 5, 2014 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
    Commented Jun 5, 2014 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
    Commented Jun 5, 2014 at 12:47
  • Why not just use an actual content filtering function from your web language? Or OWASP's filter engine?
    – Polynomial
    Commented Jun 6, 2014 at 7:16
  • Ploynomial, Please give me a link
    – KatariaA
    Commented Jun 6, 2014 at 13:39

3 Answers 3

Reset to default
4

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.

Improve this answer
1
  • 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
    Commented Jun 6, 2014 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.

Improve this answer
1
  • 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
    Commented Jun 6, 2014 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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .