full-disclosure - Re: [WEB SECURITY] Unicode Left/Right Pointing Double Angel Quotation Mark bypass?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 5 Jun 2009 16:42:57 -0700
From: "Arian J. Evans" <arian.evans@...chronic.com>
To: Thierry Zoller <Thierry@...ler.lu>
Cc: Prasad Shenoy <prasad.shenoy@...il.com>,
	Full-Disclosure <full-disclosure@...ts.grok.org.uk>,
	3APA3A <3APA3A@...urity.nnov.ru>,
	"websecurity@...appsec.org" <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Unicode Left/Right Pointing
	Double Angel Quotation Mark bypass?

response inline

On Fri, Jun 5, 2009 at 1:42 AM, Thierry Zoller <Thierry@...ler.lu> 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/