Stephen White wrote: > Erm, isn't it standard practise not to enable SSI for .html for exactly > this sort of reason? That would be the smart thing to do. >When a webdesigner/sysadmin/whoever uses .shtml > with CGI enabled they need to be aware that they are giving whoever > generates the HTML a shell prompt, exactly like using the exec() command > in a Perl script, etc, Yup. >and the input should be checked accordingly. Input wasn't checked adequately in this case, that's the problem. > > This is not a fault of Apache or even Matt's script, but of it being > used incompetently. Matt's script recognizes that it may be used in an environment where SSI is enabled on .html. It tries to check for SSI commands being passed. It fails. That's a bug, and in this case the bug has security implications. The script is at fault, and can be fixed. Perversely, had the script not made any attempt to check for SSI, you could make a case that it was misused. So it goes. >It's a standard case of if you don't fully > understand the security implictations don't change the configuration. IMNSHO, SSI should just be turned off on public web servers. I believe that if it's on, the admin doesn't understand the security implications. > BTW, I have lots of .shtml of the form <a href="someurl"><!--#include > virtual="randimg.pl"--></a> and I certainly expect apache to run it. > This is the correct behaviour. Let me clarify my comment about "even in the middle of some HTML". The above example should be fine, by my thinking. The HTML and SSI are separated. There is an explicit closing SSI tag (-->). A parser should have no trouble understanding the difference between the HTML and SSI. Here's what Im talking about: sometext sometext <!#--some SSI <B> sometext </B>... to the end of the file. Now, it was pointed out that SSI can be across multiple lines. That's fine. The problem I see is that Apache (and I'm picking on Apache because that's what I tested, and that's what I care most about being correct and secure) goes ahead and processes the SSI even though there is never a closing -->, and there is a bunch of stuff following the SSI command. This is standard HTMLish behavior. I guess I would have expected the command to bomb because it was either missing the closing tag, or because it included a bunch of stuff (the rest of the file) that wasn't legal SSI commands. It just struck me as funny that it didn't seem to care about the garbage. I would have expected something with an obvious security impact like SSI to be handled more carefully. (Yes, it did complain in the logs): [Sun Nov 7 18:30:12 1999] [error] [client x.x.x.x] premature EOF in parsed file /usr/local/apache/htdocs/guestbook.shtml BB
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:09:57 PDT