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 < co...@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 _______________________________________________
