[RESOLVED] Re-designing a flash site in (x)html

[kows]

uhhh.. I have no idea what you're thinking, or what you misunderstood from what your lecturer told you, or what you misunderstood from reading the PHP manual, but you need to step back and just ... read. you seriously are not getting this.

magic_quotes_gpc being defaulted to off in newer versions of PHP doesn't mean you don't need to worry about anything. magic_quotes_gpc being off means you DO need to worry about SQL injection. it's a deprecated feature that is still being used by many users and many hosts, and this is bad. it provides a false sense of security (like mentioned above).

let me break it down. take this example of code:

<?php
  print_r($_POST);
?>
<form action="<?php echo __FILE__; ?>" method="post">
  <input type="hidden" name="test" value="'Hello' &quot;there&quot;" />
  <input type="submit" value="POST" />
</form>

now, if you are using magic_quotes_gpc, then all user input ($_POST, $_GET) basically has addslashes() ran on it. this adds a slash to every single quote, double quote, backslash, and null byte. this means that when you submit the script above, it will produce the following:

Array ( [test] => \'Hello\' \"there\" )

this means that the input to this script has been sanitised. however, this is an unreliable sanitation because it relies on a server variable being set. without that variable being set, this script is vulnerable. that's bad. magic_quotes_gpc being on also means that you would need to use stripslashes() on anything you want to output to the browser. if you're not even using a database, this is completely unnecessary and is a waste of resources (even if the resource usage isn't very taxing). anyway, if you don't have magic_quotes_gpc on, you would just get plain text:

Array ( [test] => 'Hello' "there" )

this is where you might be asking yourself what exactly is bad about this? well, if you actually read through my last post, you should be able to piece it together. if not, I'll go through it again. it's all about A) SQL injection, and B) that someone entering a certain character can break your script altogether. how? take the following script for example (magic_quotes_gpc off):

<?php
  $sql = "SELECT * FROM users WHERE username='{$_POST['username']}' AND password='{$_POST['password']}'";
  echo $sql;
?>
<form action="<?php echo __FILE__; ?>" method="post">
  <input type="text" name="username" value="test" />
  <input type="password" name="password" value="test" />
  <input type="submit" value="POST" />
</form>

for a legitimate user, we can submit the script like normal. we will get the following query:

SELECT * FROM users WHERE username='test' AND password='test'

this is fine. right? right. a legitimate user can use this script to login, or do whatever, and everything will be fine. but what if he has a typo, and types his username as test' instead of test? our SQL changes:

SELECT * FROM users WHERE username='test'' AND password='test'

this will simply produce an error because our SQL is invalid. if errors are suppressed, then the user will just see something about not finding a username match, or whatever. that's kind of fine, too, but not ideal. now, what if an illegitimate user wants to gain access to this system? well, you're not escaping anything in this script. if the user types in the username as ' OR 1=1 # instead of test, then our SQL changes again:

SELECT * FROM users WHERE username='' OR 1=1 #' AND password='test'

this statement will always be true because either the username needs to be blank, or 1 needs to be equal to 1. 1 is, obviously, always equal to 1. the hash represents a comment, and the rest of the query is simply ignored at this point. this will let an illegitimate user log into your system. this is, for obvious reasons, bad.

so, how do we stop it? introducing the function I've been trying to teach you about for much longer than I think I should have needed to -- mysql_real_escape_string(). what does this function do? it's very similar to magic_quotes_gpc/addslashes(), in that it escapes special PHP characters. however, this function is made for MySQL specifically (meaning you need a MySQL connection in your script to even use it), and so it actually escapes some other MySQL specific characters, too. you can see the list here. now, what if we use this function to escape our variables in the previous script? "how to use" example:

<?php
  $username = mysql_real_escape_string($_POST['username']);
  $password = mysql_real_escape_string($_POST['password']);
  $sql = "SELECT * FROM users WHERE username='$username' AND password='$password'";
  echo $sql;
?>
<form action="<?php echo __FILE__; ?>" method="post">
  <input type="text" name="username" value="test" />
  <input type="password" name="password" value="test" />
  <input type="submit" value="POST" />
</form>

so, what has this done for us? let's see. if we submit the script as is (the legitimate user), we get this:

SELECT * FROM users WHERE username='test' AND password='test'

this will log the test user in. if our legitimate user makes a typo (test' instead of test), we get this:

SELECT * FROM users WHERE username='test\'' AND password='test'

this will be a valid query that returns a result set of 0. this is ideal. and what if we have an illegitimate user trying to break into our system? (' OR 1=1 # instead of test)

SELECT * FROM users WHERE username='\' OR 1=1 #' AND password='test'

so what does this do? well, the quote was escaped by the function, and thus MySQL is searching for a user that is actually named the string "' OR 1=1 #" -- this will most likely come up as a result set of 0. an illegitimate user can no longer break into your system.

so that's it. that's how you use the function, and why you might need to use the function. having magic_quotes_gpc turned off in the future does NOT automatically make you safe. actually, it makes you more vulnerable than if you had it on. that doesn't mean you should have it on, though; it just means that you should be aware of the way your scripts might be exploited so that you can prevent it.

if you get into object oriented programming in PHP, you might run into either PDO or MySQLi, which are object based database handlers. they both support prepared statements that do not require you to use mysql_real_escape_string(). if you're having this much trouble with this function, though, you do not want to start poking your head in that direction yet.

if you don't understand at this point, I simply give up.