Fix security vulnerabilities in webform report

The security report states that data is not being excaped before display by Webform Report

Is this not actually a flaw in the Webform module that collects the data? If escaped safely in the db, then Webform Report would not have an issue

Wouldn't we want to safely escape the data on collection with Webform and not only when viewing with Webform Report?

The page at http://drupal.org/node/28984 further explains secure text handling in Drupal.

It explains how Drupal handles user inputed data.

When handling data, the golden rule is to store exactly what the user typed. When a user edits a post they created earlier, the form should contain the same things as it did when they first submitted it. This means that conversions are performed when content is output, not when saved to the database (be sure to read the db_query() documentation on how to use the database API securely).

The issue in http://drupal.org/node/540980 suggests that a user can input data that would compromise your admin account when an admin views the page. In short as the advisory says this module is not secure and should be disabled to prevent your site from being compromised.

I understand how input text could compromise the site.

Is there another module that presents data collected with webform?

I am using webform/webform report as a key function on a couple of web sites

My other option is to "fix" webform report...

Exactly.
Abandoning an important part of Webform is not acceptable.
Other modules also have the same security issue and they have been fixed. Why not Webform Report?
It should also be integrated in the main Webform module. Reporting is an integral part of any webform. The current results pages in Webform are not really customizable and usable.
I just hope that someone will come-up with a solution.

The reason that this has not been fixed is because the maintainer did not place a priority on it.

As part of our security service we are also offering security upgrades to modules that have been abandoned.

We feel that the best way to do this is:

1. Look for other security problems in the module
2. Fix the reported vulnerability and any others we find
3. Create simpletests that help ensure the problem never comes back
4. Update the code in general to follow Drupal best practices
5. Create a small number of additional simpletests for basic functionality of the module
6. Create a new official release of the module

As you can see, the goal is not to just fix the vulnerability, but also make sure the module is in a generally solid state. We don't want to fix something and have our name associated with a low quality module.

It's also always possible that someone else could fix the vulnerability and become the maintainer. By paying us to fix it people can be certain that a new release will be created on a specific timeline, otherwise you must wait and hope for someone else in the community to take care of it.