Top vulnerabilities in Drupal and how can we make the API easier to understand / "safe by default"

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
greggles's picture
Posted by greggles on February 18, 2010 at 3:08pm

The Common Weaknesses Enumeration (CWE) has lots of information about the most common problems in web software. There is lots of information to sift through, but of the top 25 dangerous programming errors, XSS is #1.

http://cwe.mitre.org/top25/#Listing

This matches what we see within the Drupal project.

What can we (Drupal) do better to avoid this problem?

Comments

Filter input?

Posted by coltrane on February 18, 2010 at 4:19pm
coltrane's picture

We've taken a stance on passing data to subsystems, for most fields we take input as is and store it and we escape when output. What we could do is make form input fields use a default text format. Developers would have to specify the text format to use when they want to allow meta characters. This could get in the way in core, so we'd have to identify where it'd work.

"Vendors Should Be Liable for Code Security"?

Posted by dww on February 20, 2010 at 4:07am
dww's picture

--Group Publishes Top 25 Programming Errors List, Says Application Vendors Should Be Liable for Code Security
(February 16 & 17, 2010)
The 2010 CWE (Common Weakness Enumeration)/SANS Top 25 Most Dangerous Programming Errors list points to cross-site scripting (XSS), SQL injection, and buffer overflow vulnerabilities as the causes of nearly all major cyber attacks in recent years. The consortium behind the list, headed by the SANS Institute and Mitre Corp., is also publishing draft language to use in procurement documents that would hold software development organizations liable for product security.

See also:
http://www.sans.org/top25-programming-errors/press-release.php
http://news.techworld.com/applications/3212864/software-vendors-should-b...

I wonder how that would play out in an open source environment like ours. Does that mean the Drupal Association would be held legally liable for vulnerabilities found in Drupal core? What about contrib? Yikes. We might need to clarify some disclaimers somewhere... ;) What should our posture to this aspect of the proposal be? Are we in favor or against? What steps should we take (as the DA, the sec team, whatever) to let our support/opposition be known? What (if anything?) should we do to clarify who's really the "vendor" of various things you can download from d.o?

GPL is pretty clear

Posted by greggles on February 20, 2010 at 4:36am
greggles's picture

The GPL is pretty clear on the point that there is no warranty for the software. Individual service providers can provide a warranty of a certain level, but I think that the inclusion of the GPL with each download from drupal.org provides some protection for DA/Security team/etc. for the original download of the code.

That is...kinda crazy to try to say that vendors should be held liable for these kinds of things. I understand the motivation and desire for it, but given the state of most EULAs these days they are about as opposite from being liable as this thing is extreme in holding them liable...sigh

knaddison blog | Morris Animal Foundation

Security

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week

See all hot content.