11

ASP.NET offers an extra layer to protect your application from XSS attacks and injection in general which is called Request validation.

On their official topic, they mention that:

Even if you're using request validation, you should HTML-encode text that you get from users before you display it on a page.

Assuming that a web application doesn't validate or sanitize any data sent to the server but does have the feature enabled, how could one bypass this extra layer to submit malicious code? Is this feature necessary for an ASP.NET application?

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
Simon
  • 3,182
  • 4
  • 26
  • 38

2 Answers2

12

As a penetration tester I have found that "Request Validation" fails in a number of situations. Developers tend to believe that "Request Validation" == "magic", and it protects them completely from XSS, when in fact this false sense of security results in in very serious problems. All forms of DOM based XSS and Persistent XSS will bypass "Request Validation", and there are other cases where it fails:

In this next case the attacker does not need to write an HTML tag, by simply writing a JavaScript URI an attacker can execute JavaScript:

<a href="javascript:alert(1)">xss</a>
<iframe src="javascript:alert(1)" />

In this case the attacker is already writing within a script tag:

<script>
  var x=alert(1);
</script>
rook
  • 46,916
  • 10
  • 92
  • 181
  • +1, I like the example. Are you aware of a way to do some SQL injection? – Simon Jun 27 '13 at 03:04
  • @Simon yeah I've exploited probably about a thousand of them by now, you should be more specific ;) – rook Jun 27 '13 at 03:05
  • Right, haha. The feature would be triggered if you submit characters like an apostrophe which, as far as I know, is required to manipulate the query. – Simon Jun 27 '13 at 03:07
  • 2
    Yes, Request Validation does nothing against SQL injection, it's purely aimed at HTML injection. Like any attempt to deal with an output issue at the input phase, it can't catch all attacks, and will produce false positives. – bobince Jun 27 '13 at 09:26
  • @bobince O'connel, O'neal, O'Hannel, O'SQL Injection. – rook Jun 27 '13 at 15:40
  • How about injecting a tag,,and not inside an attribute or javascript – BlackFire27 Jul 07 '13 at 19:53
  • @BlackFire27: things that look tag-like are typically blocked, but if you can find two values that get injected right next to each other, you can split a tag up into pieces (eg `<` + `script`) that don't get blocked. Or any other string replacement/filtering might be vulnerable... it's very app-dependent. – bobince Jul 07 '13 at 20:29
0

Yes, the default request validation is not enough to avoid XSS, but a lot depends on the details.

The default request validation just filters standard characters like < or %, but depending on how you render the results, it is still possible to create something that will get executed. See the different attack vectors for XSS. There are plenty of possibilities to do XSS even with restricted character sets.

http
  • 127
  • 1
  • 1
  • 5