Re: [PHP] is $HTTP_REFERER worth trusting?
> Then, it is not safe to do IP-based blocking, right? Any alternative? As I mentioned in an earlier post (my original reply to you): > If I can't trust $HTTP_REFERER, how can I deny malicious attack like > that? The best way is authentication... that is asking the user for a username and password before doing getting the data (then you can block out specific users should they attack you - but you can only do that after the incident). There are other methods - I dont know what the load on your server is generating, but Im pretty sure there will be an alternative way of doing it. eg: on request do the load-based method and dump the details into a temporary table with a timestamp of the last time it was updated. If you get the same request within x minutes (or hours / days) then serve up the generated information from the table. This would mean that your db no longer gets hammered if malitious users were to launch 5000 requests at it in the space of 10 mins, it would just do the big DB operation the once. -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software & Systems Engineer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] is $HTTP_REFERER worth trusting?
Hello "Dan Hardiker" <[EMAIL PROTECTED]>, Then, it is not safe to do IP-based blocking, right? Any alternative? On Thu, 16 May 2002 10:10:44 +0100 (BST) "Dan Hardiker" <[EMAIL PROTECTED]> wrote: > > Craig Vincent wrote: > > The best thing you can do is temporarily record the > > IPs of connections to your script, and then block IPs that connect to > > the script too often directly from your routing table. It doesn't > > necessarily stop those using proxies but definately is more reliable > > than an HTTP_REFERER protection scheme. > > If you are expecting to have a wide (uncontrolled) audience for the data > you are outputting I would strongly suggest against doing this as the > majority of major ISPs operate transparent web proxies - where everyone > from that ISP will appear to be coming from the same IP. > If I was a malitious user, I would get a block of 50 IPs, place them on a > unix box and then bind randomly to the IPs when making the calls... making > the work around for this security measure trivial. > Im not saying you shouldnt implement any method of security, as some > security is far better than none! Just making sure that everyone is aware > of the consequences and implications. > > -- > Dan Hardiker [[EMAIL PROTECTED]] > ADAM Software & Systems Engineer > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php -- Patrick Hsieh <[EMAIL PROTECTED]> GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] is $HTTP_REFERER worth trusting?
> Craig Vincent wrote: > The best thing you can do is temporarily record the > IPs of connections to your script, and then block IPs that connect to > the script too often directly from your routing table. It doesn't > necessarily stop those using proxies but definately is more reliable > than an HTTP_REFERER protection scheme. If you are expecting to have a wide (uncontrolled) audience for the data you are outputting I would strongly suggest against doing this as the majority of major ISPs operate transparent web proxies - where everyone from that ISP will appear to be coming from the same IP. If I was a malitious user, I would get a block of 50 IPs, place them on a unix box and then bind randomly to the IPs when making the calls... making the work around for this security measure trivial. Im not saying you shouldnt implement any method of security, as some security is far better than none! Just making sure that everyone is aware of the consequences and implications. -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software & Systems Engineer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] is $HTTP_REFERER worth trusting?
> Is it possible for a hacker to make an identical $HTT_REFERER > in the header? I have no idea how $HTTP_REFERER is made, is it made > from the http client and put in the http header? Thats exactly how its done. The user agent (browser) takes the URL it was on when a link was clicked / form submitted etc and places that into a HTTP header which is sent back to the server. This information can be very easily faked and is widely implemented into spam / attack bots. > If I can't trust $HTTP_REFERER, how can I deny malicious attack like > that? The best way is authentication. I dont know what the load on your server is generating, but Im pretty sure there will be an alternative way of doing it. eg: on request do the load-based method and dump the details into a temporary table with a timestamp of the last time it was updated. If you get the same request within x minutes (or hours / days) then serve up the generated information from the table. This would mean that your db no longer gets hammered if malitious users were to launch 5000 requests at it in the space of 10 mins, it would just do the big DB operation the once. -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software & Systems Engineer -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] is $HTTP_REFERER worth trusting?
> I have a php program which executes a heavy mysql query upon request. > Normally, it should not be requested too often, but I am afraid > malicious user trying to massively call this program. I am considering > to use $HTTP_REFERER to restrict the connection source, but is it worth > trusting? Is it possible for a hacker to make an identical $HTT_REFERER > in the header? I have no idea how $HTTP_REFERER is made, is it made from > the http client and put in the http header? > > If I can't trust $HTTP_REFERER, how can I deny malicious attack like > that? An HTTP_REFERER header is sent by the client browser...which means it is mimicable (and quite easily I might add). Although adding HTTP_REFERER restrictions to a script may add a small bit of security against script kiddies it by no means is a true method of defence against hackers. The best thing you can do is temporarily record the IPs of connections to your script, and then block IPs that connect to the script too often directly from your routing table. It doesn't necessarily stop those using proxies but definately is more reliable than an HTTP_REFERER protection scheme. Sincerely, Craig Vincent -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
