Marc Slemko writes: > Note that the following is a valid SSI: > > <!--#include file="/foo1" > file="/foo2" > file="/foo3" --> > > Apache does "reject" invalid SSIs, but does not validate that a > SSI is valid before it begins processing it so the rejection only > happens after it has been partially processed. ... Understandable. And, of course: > As always, don't enable SSIs unless you need them. If you do need them, > use IncludesNOEXEC (which does not allow random files to be executed, but > does allow CGIs in ScriptAliased directories to be executed) unless you > really need to allow exection of other things. If you really do need > to allow execution of other things, don't do it globally, but only where > it is absolutely necessary. Similar warnings apply for malicious users who may inject PHP (also server side threat) and javascript (client side threat) into data that might wind up on a web page. If the intent is to disallow HTML altogether, escape "<" and "&" at least, preferably also ">" and perhaps even double quotes. "&" needs to be first. E.g., s/\&/\&\;/g; s/\</\<\;/g; s/\>/\>\;/g; s/\"/\"\;/g; A side effect of doing this is that it will be obvious when someone tries to hack your page with SSI, PHP, etc. -- and fails. If you *must* allow HTML tags in user input _at all_, limit them to specific tags. Something like: @okTags= ($userInput =~ s,(\</?(?:B|I|Whatever\>?)|\&(?:copy|amp)\;),\0,gi); $userInput=~ s/\&/\&\;/g; $userInput=~ s/\</\<\;/g; # Escape remaining "<"s. # Note that ">"s are *not* escaped because only the beginnings of # tags are matched when attributes exist. $userInput=~ s/\0/shift(@okTags)/ge; The above example is to allow the tags <b>, </b>, <i>, </i>, <whatever attribute=value>, </whatever> and © and & -- and disallow all other tags and comments by turning them into ordinary content. If you want to silently remove certain tags first, do that. If you want to completely disallow an entry because of *any* undesirable content, do that. As others have stated, try not to anticipate everything that might possibly be bad. Rather, filter out anything that isn't good whenever possible. Blue Boar's criticism of the guest book script is certainly valid, but only scratches the surface of possible exploits. IMHO, the main problem regarding both HTML comment *and* HTML tag removal, is that this script assumes all undesirable content -- in a guest book -- will be syntatically valid HTML. :-) For people who don't consider Javascript a threat, consider malicious web pages (e.g., Active X, the recent MS JVM exploit) that Javascript can call up without your explicit consent (e.g., mouseover event). Also consider Javascript-enabled mail readers, but that's another topic. Chuck
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:10:12 PDT