Is it possible to execute xss under the following conditions?

The following blocked characters and words are replaced with _.

characters: > , : , ; , " , ' , # , ~ , \ , % , ( , ) , [ , ] , { , } , [space]

keywords: alert, confirm, prompt, href, body, onload, src=

The input into the get variable will be echoed back to the user and will not be in any attributes or tags, it will be displayed as it is.

  • If you know the answer then why you are asking question that itself is not clear. You are adding stuff in subsequent posts.
    – user30428
    Sep 5, 2013 at 20:32
  • <input autofocus onfocus=codehere – Tabs over spaces and > isn't needed if there are more tags in the following code.
    – copy
    Sep 5, 2013 at 21:44
  • I'm not quite sure what your purpose is here, but it would probably be better for you to set up a server that behaves as you describe, and challenge people to create a working XSS exploit. You may want to put some restrictions on what browser (and settings) the exploit is to work in.
    – paj28
    Oct 23, 2013 at 10:37

1 Answer 1


First and foremost XSS is entirely dependent on context. Forcing all input though the same filter will never work all of the time. This is just not how web applications deal with the problem of XSS. The biggest problem with this method of XSS protection is that it is not binary safe. HTML Entity encoding will preserve the value without leading to XSS.

Most of these proposed restrictions have no impact on a given web applications susceptibility to XSS. The most obvious problem is checking for alert and prompt, as these are strings that will never appear in a real attack. This is because a real attacker wants to be undetected, an alert box is a dead give away.

To answer your question, YES, there are numerous conditions in which an attacker could obtain XSS given these arbitrary restrictions. What comes to mind first is DOM Based XSS and DOM Event Injection.

Plain old reflective XSS will also work in a number of situations, the following is a PoC payload, assuming the attacker is already writing within a <script> tag:


In this casedocument.referrer is where the reflective XSS payload originated from lets call it http://attacker/cookie_thief.php?c=. In this payload the victim's browser will be redirected back to http://attacker/cookie_thief.php?c= by the XSS payload, and the c GET variable will be populated with the cookie value.

  • You are wrong on the examples you gave, i said that it would be displayed as it is. So the case of it being inside <script> tags is out of the question and thus there would be no dom based xss. Second you need to realize + is a space, so that would get replaced with _ and therefore mess up the xss vector. Now as for prompt,alert,confirm, of course that will not be used by the attacker, that is to show a poc, regardless if it's actually exploitable or not. I'm referring to all possible cases, regardless if it's exploitable or not exploitable.
    – user30332
    Sep 3, 2013 at 18:04
  • I know the real answer to this question, i'm just interested into what people thought of this case. The actual filter even filtered the keyword "document" case-insensitive and many other keywords.
    – user30332
    Sep 3, 2013 at 18:04
  • @Bob DOM based XSS happens when JavaScript is working with attacker controlled input. Writing attacker controlled input within a script tag with server-side code, is just reflective XSS. Perhaps you should familiarize yourself with the types of XSS before attempting to home-brew a protection system. Keyword based detection is a waste of processing power, and it does not address the root of the problem. Almost no web apps use this method of XSS defense for these reasons. You should be using HTML entity encoding of control characters.
    – rook
    Sep 3, 2013 at 19:15
  • @Bob, '+' is a space in a URL. Rook was providing code that appears in a page. '%2b' in a URL parameter will be a '+' when seen by the app.
    – Jeff
    Sep 4, 2013 at 14:12
  • @Rook I appreciate you tried you answer my question, but please, you know you're wrong. I know a lot about xss, a lot more than you, i'm just simply pointing out your explanation would not work as there are no other things on the webpage and it is NOT in attributes or tags, it is displayed as it is after going through the filter. I didn't "home-brew" an xss system LOL there's a reason why htmlspecialchars exists, this was an xss challenge i made.
    – Bob
    Sep 6, 2013 at 19:33

You must log in to answer this question.

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