How to protect other files in Login folder etc

Wow, you guys are an incredible wealth of information! Thank you!

My only real experience with magic quotes was a nightmare. I had just moved a new client's Webcalendar database from one host to another. The new host had magic quotes OFF so every time a user submitted an event or a name with an apostrophe in it, it was interpreted as a delimiter and threw a SQL error and refused to load the record. The owners were freaking out. I had to call the guy who originally installed the database and he told me to turn on magic quotes - end of problem.

I always have total control of the php.ini file, but I'm afraid to turn off magic quotes. Especially if there is no step taken to handle the delimiter problem, how can this possibly work? Wherever it caused a problem, I had to use addslashes to fix it.

Regarding sessions, this is one place I was hoping to use them... imagine an art gallery with 3 art consultants all using the same computer to input client info and sales. If they each login under their own login, can sessions keep track of who is who? Or on one computer there can be only one session at a time? Does a system restart end a session?

Thanks, e :)

A session is unique to an individual connection based on the session_id. I guess technically two users could be sharing a session (in weird circumstances) if they had the same session_id, such as by "hijacking a session" by stealing the cookie from someone's computer. Or you could just intentionally give your id to a friend so you could have the same session. But that never happens accidentally.

In short, there's never information shared between users. Sessions don't replace databases or anything like that. If you need to communicate between multiple users, you'll need to use the other techniques you already know for that.


As for magic_quotes, yes, that's why it is "useful" and why it was created. But the problem is that it's like trying to fight a war with rocks (rather than guns)-- it can do the same thing, but often isn't as efficient or accurate. Relying on magic_quotes often leads to systems that miss something else that needs to be escaped and can cause the double escaping problem. So rather than finding a problem and fixing it with magic_quotes, I highly recommend that you fix it manually-- addslashes is one way. But realize that there are other things that may need to be escaped depending on how the data is being used.

Here's a quick list of escaping:
strings (for example, outputting Javascript): addslashes()
html: htmlspecialchars()
mysql: mysql_real_escape_string()
That's not a complete list.

which characters are unsafe varies depending on the database. mysql is different than oracle, is different than mssql, etc. (if you look at the documentation, you'll see that magic_quotes escapes ' " \ and NULL - a different list than mysql_real_escape_string()).

That's why you should be using database-specific functions, like mysql_real_escape_string() - but using both leads to the "double-escaping" problem.

Aside from that, not all submitted data is destined to be sent to the database anyway. Unnecessary backslashes can cause problems in other code. Consider this:

HTML Code:

---

<form method="post">
    <p>is your name <b>Adrian</b>?</p>
    <input type="submit" name="submit" value="That's my name!">
    <input type="submit" name="submit" value="No, it's not">
</form>

---

PHP Code:

---

<?php
if( $_POST['submit'] == "That's my name!" ){ /* won't work if magic_quotes is on */ }
elseif( $_POST['submit'] == "No, it's not" ){ /* won't work either */ }

---

I guess the short version of all of this is simple: escaping is always context dependent. You can't pre-escape everything because escaping by definition is within a certain situation (such as a string in PHP, a query in MySQL or HTML output), and escaping must be based on which characters are active for that context.
magic_quotes is therefore logically badly designed, and it will work, but only if it correctly guesses the potential future context for your use of the data. That's because magic_quotes is context independent.
The secondary problem is that some servers have it and others don't, so inconsistencies are common, and that might be the biggest source of the double escaping problem.

using htacess helps me a lot!

Quote:

---

Originally Posted by ayamkampung

using htacess helps me a lot!

---

...helps you do what?
we aren't discussing any htaccess methods here.

if you're talking about turning off magic_quotes_gpc, you should be doing so in your php.ini file.

If that's not possible, then it's likely that you'd also have problems changing the setting via htaccess - but at that point, using a runtime script like the one I posted would be a better (more universally reliable) option anyway.

OK, I'll turn off magic quotes in php.ini. Then the only way I can see of preventing errors from apostrophes in user input is to addslashes. For example, if lastname is "O'Brian"...

$_POST['lastname'] = addslashes($_POST['lastname'])

And, if I understand correctly, adding slashes accomplishes exactly the same thing as if magic quotes were on. So someone could still use SQL injection unless I use mysql_real_escape_string(), yes? I understand how double escaping can happen but have never had a problem.

So are you saying the very best solution that covers all contingencies is to:
1. Turn of magic quotes in php.ini
2. Use addslashes for user input form fields
3. use mysql_real_escape_string() before loading to database

So I would end up with something like this??...

Code:

---

$lastname =  mysql_real_escape_string(addslashes([$_POST['lastname']))

---

There's no need to use addslashes() here. addslashes is a function for escaping only in a context where those characters as defined by addslashes() need to be escaped. That's not the escaping function for mysql: the escaping function for mysql is only mysql_real_escape_string(). Any direct user input can be put through that single function and then is safe.

There are cases where you should use addslashes, although honestly very few. Use it when you're looking specifically to fix just the quotes, not any other control characters. For example, if you're creating a string for PHP. If you want to dynamically create a .php file, then you can write the following code to that file (as the contents of that file):

PHP Code:

---

$myvar = addslashes($_POST['myvar']);
$contents = '<?php $myvar = "'.$myvar.'"; ?>';
fwrite($file,$contents);

---

The same would apply if you were outputting Javascript strings (the text to be assigned to a variable, generated within PHP).
But these situations aren't very common. The most common cases of escaping are mysql_real_escape_string() for MySQL and htmlentities() for HTML.


The double escaping would happen if you used addslashes() when magic_quotes is on.

(Technically, as far as I know, mysql_real_escape_string() won't ever result in double escaping because its' a 'smarter' function than addslashes()-- it's designed to make data safe, rather than just logically adding slashes to certain characters.)

1 & 3.

Whatever you put into MySQL_real_escape_string() will come out ready to be treated as literal data by MySQL. Use it - no other functions.

Addslashes() is not suitable for this purpose.

So are you saying that MySQL_real_escape_string() would take malicious code and render it inert by turning it into a literal?

So you might find something in your database like:

Lastname: DELETE FROM clients; DROP table clients;

Currently I have magic quotes ON and if I don't add this bit of code:

Code:

---

$clientname = addslashes($client['lastname'].", ".$client['firstname']);

---

the data will not load to the database for names like O'Reilly, O'Brian, etc. Are you saying it would be better for me to use this? ie. it serves both functions at once?

Code:

---

$clientname = MySQL_real_escape_string($client['lastname'].", ".$client['firstname']);

---

Thanks