XSS vulnerabilities are the most common inside web applications.
This proposal regards a series of improvements on existing modules, such as "Security Scanner" module and "Coder" module, and a series of small tools to make XSS research (or maybe other vulnerability research, such as CSRF) more comprehensive and easier to execute.
Security scanner: Currently only finds XSS based on data stored in the DB and displayed back to users, so it will miss XSS that is displayed back to the user immediately after form submission. Make it able to find XSS inside drupal_set_message or in a search result page.
Coder: add more test to find XSS. See this initial issue for examples.
Other new stuff that could be great to have:
Tainted Bugs (or, Automatically detecting XSS security holes), from Barry Jaspan. Create the script that Barry explain here http://jaspan.com/tainted-bugs-or-automatically-detecting-xss-security-h... and make it public. Or, if Berry agree, take his script, complete it, and make it public.
CSRF finder, from Barry Jaspan (again =) ). I know that he developed a perl script to find CSRF vulnerabilities. Enhancing it and creating documentation/process around running it would be a great idea.
This is a wiki page as I hope the security team could come here to add some features or ideas.
Comments
Taint is in C
Just because Barry is proficient in perl, C and PHP all that does not mean we should expect a student to do all three.
But we should
But we could expect a student that could understand how taint works and write it in php as a new feature for the security scanner or the coder module.
neither possible dor desireable
Rewriting taint in userland is... almost impossible and i would not want to meet the code that does it.
I would like to see better
I would like to see better APIs to make these issues hard to code in the first place, instead of cleaning up the mess.
You could have...
You could have the powerful APIs in the world but if you ignore them you make an horrible work with thousand of exploit. I think the actual APIs are fine, and the section "write secure code" on the handbook is great, problems comes when someone doesn't read it.
Instead, I would like to have something that checks my module for basic security problems before uploading to the module page and releasing a new version that anyone could download.
room for both
I think there is room for both. We've seen that when we make it easier to use the API than do things incorrectly it tends to get used and people are protected.
Some examples of API inconsistencies which could be improved:
* drupal_set_message doesn't do filtering while drupal_set_title does
* in the Forms API select options are filtered while checkbox, checkboxes, and radio, and radios are not
* It's way too easy to mess up input format filters and permissions. Way too easy. Needs UI help and text improvements, probably.
When inspected I can see the logic of not providing filtering, but it also feels inconsistent and is very likely to lead to mistakes. A student who is new to Drupal is a perfect candidate to analyze the API, find inconsistencies that are likely to cause mistakes, and fix them.
That said, I agree with Dario that people will always make mistakes and creating tools to find those mistakes is worthwhile.
Why not both as separate projects?
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation