Your own site - you have a duty not just to your data and your users, but also your casual visitors - untrusted sites rapidly get blacklisted by the Internet as a whole
APIs - if you use "known APIs" [what does that mean?] you have security "guarantee" [what does that mean too?] but not if you use other functions.
Resources - drupalsecurityreport.org Cracking Drupal (book recommended by webchick, tech ed by chx)
Across all apps XSS is the largest vuln overall; SQL inj is the next
In Drupal XSS is by far the most common vuln - themers should be most worried
Update, update, update - install module for D5
Have a consistent method for updating the site and stick to it
Email address on admin/reports/updates/settings
Email every day - you'd be blind to it
ALWAYS backup before update
Don't use insecure tools - FTP, http. Use https for admin via securepages
Avoid Total Commander at all cost. It stores your FTP passwords in plain text, and there's a virus which targets it.
Server security updates
XSS - user input is dangerous. Even if you trust the user, don't trust the text.
Default format MUST be filtered. e.g. comments
check_url, check_plain etc. if you don't know the format, then filter_xss at the very minimum.
Demo
Moderated comments just make it worse
Moderated comments means that an attacker knows the admin is going to go and moderate.
So Javascript can make a form POST and replace your admin user's email address
Apache JIRA hack story
You can decrypt passwords with rainbow tables
Themers are the frontline - be careful
Preprocess functions have responsibility to escape. Modules have responsibility
So use $title in node.tpl.php and complain to module maintainers if the content is unsafe!
Theme functions in D6 can be unsafe
Use tpl.php if possible
XSRF
post IMG tags which run JS on a 3rd party site.
GET and POST are vulnerable
Use FORM tokens. Can't be accessed by browser security model.
Confirmation forms for destructive actions, to prevent people joining groups!
drupal_confirmation_form() !
Security vulns in the past and risk levels
You'll be in good company
If you have a security problem, don't fix it. Don't tell people: tell security@drupal.org
Arbitrary Code Execution using preg_replace with /e [!]
SQL injection - don't even need to be able to write, to compromise the site. Just read.
Access Bypass - complex access privileges can bypass
Directory Traversal - put locations with ".." or just simply "/" or "\" (Windows) and retrieve e.g. /etc/passwd or code execution
- What do known APIs mean? What does that mean for a given contrib module? Is that just core? Because we get SA advisories for contrib modules, so that's not clear.
- If you've got custom formats, what's the most important filters within them for avoiding malicious code? To switch on - whitelist html? To switch off - PHP interpretation?
- Can we have that demo somewhere?
- Salt encryption in Drupal re: rainbow tables?
Answers from greggles via email:
I tried to post this as a comment, but it got blocked by mollom :/
Nice notes. To answer some of your questions:
The core apis (db_query, t, l) all include security features in them. So, if you "use the api properly" then you are safe. Knowing how to use the API properly is not always easy. Reading Pro Drupal Development and Cracking Drupal helps.
You should try out the http://drupal.org/project/security_review module which will let you know which input formats on your site are safe or not (hint, yours are pretty good).
If you are worried about the password hashes, you can use http://drupal.org/project/salt or http://drupal.org/project/phpass
Check out http://groups.drupal.org/best-practices-drupal-security as well, and good luck!
