This is an interesting idea for a module, but it is not a complete solution and is very "un-Drupal" way to handle the issue.

If you haven't already, please see http://drupal.org/node/263002 and http://acko.net/blog/safe-string-theory-for-the-web

Drupal doesn't do filtering on input the way this module proposes because it is an incomplete and error-prone solution that often leaves people just as exposed but they think they are "safer."

You say

But it is clear that if there is a bug in a module (which you do not indend to fix yourself)

but that is a false premise. If there is a bug in a module it should be reported to the security team and fixed.

I'm tempted to argue that this module should simply be removed because of the false sense of feature and protection that it provides but want to have a discussion about it first.

Comments

coltrane’s picture

I think the project description could be altered (more on that in a moment), but I don't think this module is not acceptable because its a "un-Drupal" way to handle input. The description could be altered to make a user more aware that this module is not promising a completely secure site.

Gábor Hojtsy’s picture

At the very least, I think the applicability of this module is pretty limited. The project page says it is for sites, where people cannot submit anything which would not go through check_plain(). So a site with no forums, no content submission, no comments, no contact form, etc. If its a brochure site, then it would not allow any input anyway (maybe URL based input which is not processed via forms), so this module would not be useful at all.

richard_kapolnai’s picture

Thanks for the feedback.
I think we have a misunderstanding, because the documentation is not clear enough, I will improve that.

Greg wrote

but that is a false premise. If there is a bug in a module it should be reported to the security team and fixed.

Of course it should be fixed but imagine the following scenario. A module is installed which actually has a vulnerability because e.g. nobody reported it yet. Or reported, but the module is not maintained properly. Or fixed, but the administrator was unable to update the site. If a malicious user discovers this available vulnerability, this module can prevent him/her to exploit it.

Gábor wrote

it is for sites (...) with no content submission, no contact form, etc. (...) it would not allow any input anyway

No, the site would allow some input but not rich input e.g. Filtered Html.
Also the paranoid validation can be restricted to specific forms or alternatively, specific forms can be freed (white-listed) from validation, e.g. node-form could be whitelisted.

The applicability is indeed limited to simple sites with a few input possibilities but not so much you wrote. I think there are such simple sites (e.g. I have one) which can afford not letting submit '<' characters, this module is mainly for them.

If you think these events cannot occur, you are not so paranoid that I am ;)

greggles’s picture

A module is installed which actually has a vulnerability because e.g. nobody reported it yet. Or reported, but the module is not maintained properly. Or fixed, but the administrator was unable to update the site. If a malicious user discovers this available vulnerability, this module can prevent him/her to exploit it.

  • If nobody reported it yet how will the admin know to use this module to protect it?
  • If the module is not maintained then the admin using this paranoid form validator should take over maintenance - at least long enough to fix the bug and make a new release

My major problem with this module is that I don't think it really adds to the security of a site. The form validation it does may help some situations, but not others (i.e. protect against xss but not sql injection nor code execution). And it will confuse people and give them a false sense of security. We need less confusion around security, not more.

That said, I appreciate that you have updated the project page to explain more fully when this module is appropriate and have linked to this issue. That seems like enough of a fix to me, but I'm open to other's opinions on that.

richard_kapolnai’s picture

If nobody reported it yet how will the admin know to use this module to protect it?

Only in a preventive way. E.g. I have a D site with some modules and I am 99% sure that my site contains some vulnerabilities which are not discovered yet. In other words, there is a strong possibility that there will be more Security advisories in 2010 in Core or in Contrib. So I don't even know whether there exists an exploitable bug or not, but I suspect.
If a new Security advisory is released in the future, then (in some rare cases) I will be calm because my site was not exposed thanks to the paranoid validator. Not even for the short period between the security release and the update of the site.

You are right, it is only a simple module and will help only in some situations. (It can also be configured to make xss more difficult by disallowing characters ' " ; ).

A similar logic may be in IT when a system operator installs a firewall which allows traffic only in SSH and HTTP ports, however, no other service available on the server. In this case the firewall does not increase security for the moment, but if something unusual happens, it may help.