How many security holes

[Erik Frèrejean]

That is BEGGING to be hacked.

Besides that the only serious leak I could find was $PHP_SELF and maybe some minor issues if the data in the $_SESSION varriable isn't properly checked. Aside from that the code is just horrible

$_SERVER is user input, never trust user input. Therefore you must validate those variables before using them in a query. I'm not sure whether you can actually inject malicious stuff into $_SERVER['REMOTE_ADDR'] but even so you shouldn't trust any data that is influenced one way or an other by the user.

[WyriHaximus Cees-Jan]

That is BEGGING to be hacked.

Besides that the only serious leak I could find was $PHP_SELF and maybe some minor issues if the data in the $_SESSION varriable isn't properly checked. Aside from that the code is just horrible

$_SERVER is user input, never trust user input. Therefore you must validate those variables before using them in a query. I'm not sure whether you can actually inject malicious stuff into $_SERVER['REMOTE_ADDR'] but even so you shouldn't trust any data that is influenced one way or an other by the user.

Well you could insert something into $_SERVER['REMOTE_ADDR'] if you manage to trick apache to accept some faulty IP. I wouldn't take everything in $_SERVER for granted but $_SERVER['REMOTE_ADDR'] is a pretty safe one. Still it's wise to check and escape it if needed there are several tools/frameworks that already do that for you and for the sake of humanity in doubt always double check to be sure .

[Erik Frèrejean]

if you manage to trick apache to accept some faulty IP.

Or just a bug in the apache version that is running on the server.

I wouldn't take everything in $_SERVER for granted

And you shouldn't as its user input.

but $_SERVER['REMOTE_ADDR'] is a pretty safe one.

Sure its "pretty" save, but that is an assumption on data that comes from the user.

[WyriHaximus Cees-Jan]

if you manage to trick apache to accept some faulty IP.

Or just a bug in the apache version that is running on the server.

I wouldn't take everything in $_SERVER for granted

And you shouldn't as its user input.

but $_SERVER['REMOTE_ADDR'] is a pretty safe one.

Sure its "pretty" save, but that is an assumption on data that comes from the user.

Exactly .

[zaphod Mike]

Actually, I would be prone to trust $_SERVER['REMOTE_ADDR'] , as if that is incorrect, the server will not know where to send the response (as in a spoofed IP). I have yet to have a problem with that.

The function you should be wary of, is $_SERVER["REMOTE_HOST"] . If there has been some DNS poisoning going on, this will steer you wrong, and even gethostbyaddr($detected_ip) can't be perfectly trusted. However, once they started hopping DNS ports, this is alot more sure. Of course, if global variables are on, all bets are off.

But other than that, the lack of variable sanitization before playing with SQL, is atrocious in the example script. Skiddies dream of stuff like that being exposed.

Zap

[Erik Frèrejean]

Actually, I would be prone to trust $_SERVER['REMOTE_ADDR'] , as if that is incorrect, the server will not know where to send the response (as in a spoofed IP). I have yet to have a problem with that.

Sure it is unlikely to be exploited though the $_SERVER array is user input and you can not trust user input. Besides that why take the risk cause if someone finds a way around it you'll smack yourself in the face. This is simply a case of good coding practice, data that somehow *could* be changed by the user should be sanitised before you can use it.

[zaphod Mike]

Sure it is unlikely to be exploited though the $_SERVER array is user input

I disagree, while the $_SERVER array is global in SCOPE, it is not registered to where user input is accepted. Please see http://www.php.net/manual/en/reserved.v ... server.php , and http://www.php.net/manual/en/language.v ... lobals.php , where it is said...

Several predefined variables in PHP are "superglobals", which means they are available in all scopes throughout a script. There is no need to do global $variable; to access them within functions or methods.

I do not see where [REMOTE_ADDR] can have false information injected by the user. It seems to be a variable directly set by the server software, which detects IP from the TCP/IP stack of the server. Elsewise, I see no other way to derive IP safely within the script.

Can you please give me an example, of how this variable can be tampered with? I really need to know this as it would affect ZB Block to it's core.

Zap

[zaphod Mike]

I disagree, while the $_SERVER array is global in SCOPE, it is not registered to where user input is accepted.

Should have read...

I disagree, while the $_SERVER array is global in SCOPE, it is not registered to where user input is accepted, where it is not looked for.

Hope that makes it clearer.

Zap

[Aureax]

I counted 18 SQL injects, 1 way to hack.