Re: Food for thought on app sec

[Rohit Sethi <rklists () gmail com>]

Hi Steven, thanks for your response. I absolutely agree that part of the
reason we see high false positive rates  / false negative rates in automated
tools out of the box is because these tools are being measured against
domain-specific vulnerabilities when really they should be primarily used
for domain-agnostic vulnerabilities. Fine tuning can certainly help in this
area.

In your example, I'd still argue that XSS is domain-agnostic. The issue is
simply that in certain contexts you may accept the risk of XSS - after all,
the administrator could be malicious in inserting those script tags. You
could make a similar argument for a tool that allows users to create
arbitrary SQL statements as being vulnerable to SQL injection. We can still
use domain agnostic tools, people, and processes to find XSS and SQL
Injection even if in some cases the risk is acceptable for the use of the
application.

On Mon, Jan 24, 2011 at 7:09 PM, Steven M. Christey <
coley () rcf-smtp mitre org> wrote:

> Rohit,
>
> Excellent article!  For the Top 25, we've had lots of people assume that
> the entire list is about domain-specific issues, when it also covers
> domain-agnostic issues as well.  My first guess is that domain-specific has
> a loose association with implementation, and domain-agnostic has a loose
> association with design.  Better modeling the differences between
> domain-agnostic and domain-specific might also partially explain the
> false-positive rates in automated code scanners [1] and why scanners seem to
> be very limited for domain-specific issues without sufficient tuning.
>
> There may be some subtleties with how to classify things like XSS, which is
> arguably both domain-agnostic and domain-independent; a CMS admin often has
> the privileges to insert script, thus no XSS (which requires a
> domain-specific assessment).  You might also have requirements that are
> specific to a particular product; for example, path traversal might be fine
> for an application if it's provided as a command-line argument for startup,
> but not when reading a pathname from remote input.  This suggests an
> application-layer notion of "domain-specific".
>
> We do not have this type of distinction for weaknesses in CWE, though it
> may be useful for some consumers (SC-L readers can contact cwe@mitre if
> you think this would be useful, and why).
>
> - Steve
>
>
> [1] See NIST's SATE project for why "false positive" and "true positive"
> are not fine-grained enough for classifying the correctness/utility of
> automated scanning findings.



-- 
Rohit Sethi
Security Compass
http://www.securitycompass.com
twitter: rksethi

_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________