[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] [WEB SECURITY] Unicode Left/Right Pointing Double Angel Quotation Mark bypass?
- To: Thierry Zoller <Thierry@xxxxxxxxx>
- Subject: Re: [Full-disclosure] [WEB SECURITY] Unicode Left/Right Pointing Double Angel Quotation Mark bypass?
- From: "Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>
- Date: Fri, 5 Jun 2009 16:42:57 -0700
response inline
On Fri, Jun 5, 2009 at 1:42 AM, Thierry Zoller <Thierry@xxxxxxxxx> wrote:
> The discussion of how many inputs are vulnerable is kind of
> ludicrous isn't it? As it nearly always boils down to the same set of impacts
> even if you have a trillion of inputs vulnerable, per domain.
Measuring inputs is very valuable.
A 500 page report from a scanner or consultant listing 18,000 inputs
all vulnerable to the same 2 types of XSS attacks is certainly not,
which is what I think you were referring to.
The number of identically vulnerable inputs by density and location in
an application is itself a form of metadata:
It gives you a strong indication whether or not you have a
Conceptual/Design problem or a Particular/Implementation issue.
Nobody in Black Box land has described this correctly yet that I have
seen. The discussion quickly hits a slippery slope between issues of
Omission vs. issues of Commission.
Omission: In the broad case, where you find a type of syntax-attack
vector like these everywhere in a piece of software (n+80%?) you can
usually map that to a design omission or framework flaw.
Commission: In the particular case where you find a type of
syntax-attack vector like these in one specific location
(/noobdev.aspx) or very small percentage of inputs (n-98%?) you can
usually map this to a specifically committed implementation error or
the use of a dangerous library for a specific function.
The differences between these are important at a strategic level in
terms of how to solve/avoid the problem going forward.
Measuring "exploitable defects-to-inputs" is an effective way to
measure, over time, as you create/update/deprecate your code: are you
getting better or worse over time at Writing Secure Code?
In this sense exploitability-per-input has definite measuring-stick
value. There are certainly other ways to measure, but in a Black Box
perspective of CRUD-over-time effect on your code, I think this is the
best way we have today to measure what direction of overall
exploitability your code is moving in.
There are other tactical considerations but they are outside this discussion.
---
Arian Evans
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/