You've found vulnerabilities and you can find and exploit them on public sites (of course you won't do that). Now what? Report them to the Drupal security team. Provide a simplified test case for exploiting the weakness. Often this is very easy to do, but sometimes it can be much harder. Either way, it's important to follow through on it and give the security team enough information for them to easily confirm the bug—amid the hundreds of messages they deal with each month, a clear and easily repeatable report will make you one of their best friends.
A good report contains several specific elements:
The most important thing is a simplified set of steps to repeat the issue. This should include the specific versions of Drupal core and any required contributed modules.
It should also include a series of steps to take a site from fresh install to a demonstration of the vulnerability.
For the previous Talk module example, something like the following sample report would be wonderful:
The Talk module  contains a cross-site scripting vulnerability. This vulnerability affects the latest version of the module running on the latest version of Drupal core. It can be exploited by the following steps:
1. Install version 6x-1.4  or 5x-1.2  of the module.
2. Configure the module to be enabled for page content types.
EXAMPLE VULNERABILITY REPORT FOR TALK MODULE XSS (continued)
3. Create a new page with the title <script>alert('xss'); </script>.
4. For that newly created page, visit node/NID/talk. The results:
♦ Expected results: The page title is displayed with special characters converted to HTML entitles.
If the issue is particularly bad, you can encrypt the message prior to sending it using the security team's public key, available on http://drupal.org/node/101494. This example report for the Talk module is very simple, but it is also complete enough and would work for the majority of the problems with Drupal. A more complex exploit would need more steps in the process.
Once the report has been submitted, the security team will work with the module author to fix the issue. This can take anywhere from a few weeks to a few months depending on the complexity of the module and the fix—contributed modules are often overly complex and, because they often have only one or two maintainers, it can be difficult for the maintainer to prioritize fixing the module.
Was this article helpful?