Friday, 20 June 2014

Please come and play with the OWASP Band AppSec EU at the CB2 (Tuesday 24th,7pm)

Next week the OWASP Band is getting back together and as always we need players. 

So, If you are coming to the conference (or are in the area), please let me know (ASAP) what instrument you can play, and I'm sure we can find a way to make it work.

Due to Adrian relentless efforts there is a full PA + Amps + Guitar + Bass + Keyboard + Drums available, what we now need is players :)

The show starts at at 7pm and we will do the soundcheck (i.e. the rehearsal) from 5pm.

The venue is the CB2 ( which is just walking distance from the main conference location:

Sunday, 1 June 2014

Bypassing request validation detection, but it is a vulnerability?

Defence in Depth is a good strategy, specially since part of its core principles is the idea that some of the security measures applied will fail. The problem with NOT doing defensive-in-depth coding, is that if there is a way to bypass the security control, then the app can be exploited.

Asp.NET Request Validation is one of those security measures that can sometimes backfire, since it can be used instead of output encoding (in context) the data shown to users (i.e. there is a false sense of security provided by the use of that 'outside-of-the-application security filter').

But since fixing vulnerabilities has a real cost, one must be able to make the business case for the fix (i.e. show that there is a significant risk for the target application).

For example, do you think that following scenario is a 'real-vulnerability' (which should be fixed?):
  • website has Request Validation Enabled
  • There is a page with a reflected XSS (quasi)vulnerability
  • There is a bypass for the Request Validation that only works in IE
  • On the scenario where Request Validation can be bypassed (in IE) the same IE version is able to detect it via its current Anti-XSS detection (and disable the payload)
This is one of those cases where although there a 'vulnerable' page, the number of affected users is very small, so the interesting question is: is there a business case to fix the vulnerability?

I think a more interesting (and relevant) question is: Is this an one-off vuln, or, are there other XSS vulnerabilities in that website, specially persistent XSS vulns?