php security

Important!

Testing that lead me to a thought about Koobi's code above. If php automatically escapes those characters Koobi's code would make it go back the other way. As a result I in fact decided to try using Koobi's function and found some staggering results!

I hate to say it but using the function koobi said above is sceptable to sql injection attacks . Don't try any thing fancy just make sure you put the users input into the quotes and php will take care of the rest!!!

Another way to prevent an sql injection attack from deleting your db or table. Use a different mysql username that has limited rights (cannot delete or alter) on the db during the login. Once the user is logged in, its likely they will need to alter/add/delete records, so you'll probably have to go back to using a mysql username that has full access rights. But, it's just my two cents.

I've never really had a problem with this kind of thing, the worst that has happened was last week someone hacked a vBulletin board I webmaster for.. It was a quick and easy fix. After we figured out what was wrong.

Brett

Ok I am figuring things out as I go here.

get_magic_quotes_gpc -- Gets the current configuration setting of magic quotes gpc
If this is on (1) php automatically adds slashes. If it is off (0) php does not add slashes so you should automatically addslashes.

Koobi's code does add slashes if it is off which is good. The problem is it strips slashes if it is on which is bad.

I will rewrite a better way of doing it in the next post:

I think this is all you really need to do but I haven't tested it nor thought of other types of queries that might stuff this up. When I get a chance I will test it and think about it a bit more.

If you're allowing the user to input data, and you're not being wary of quotes, you are open for SQL injection. The links I provided you with explain this in better detail than I am capable of
In the example you posted above, SQL injection is possible.

Originally Posted by Travis I think that included files can be solved by setting the permissions to the included files so that only the server can access them? I think maybe the php.ini is setup initially so that this cannot happen. It's just a matter of figuring out how your host is set up really.

By default, PHP scripts usually have a CHMOD of 644, which means everyone can read the file but only the owner can write and on the Apache web server (I haven't worked with any other web server so I will talk about Apache only), when it is started, it is started as the root user and then forks childs with less permissions...so Apache is pretty secure, so that's one good thing about it.
Now about what you've said...if I was MaliciousUserX and I wanted to include my malicious script in your page so I can echo some important data such as DB details, I would simple give my script on my server a CHMOD of 644 which means anyone can read...
So, like I said, make sure a file exists before including it. I can post some code if anyone wants to see some.

Originally Posted by Travis Ah I just tried it... php automatically adds escape characters to quotes hence I don't really see how sql injection attacks occur (maybe this was only an old problem which was not considered in earlier versions of php)

PHP only adds slashes depending on the get_magic_quotes_gpc() directive in php.ini (GPC = GET, POST, COOKIE)
See: http://www.php.net/get_magic_quotes_gpc

Originally Posted by madpenguin2 Another way to prevent an sql injection attack from deleting your db or table. Use a different mysql username that has limited rights (cannot delete or alter) on the db during the login. Once the user is logged in, its likely they will need to alter/add/delete records, so you'll probably have to go back to using a mysql username that has full access rights. But, it's just my two cents.

madpenguin2 makes a valid point there but this won't stop someone from extracting data from the db since that would involve a simple SELECT statement which is a read and all databases must be readable.

Originally Posted by Travis Important! Testing that lead me to a thought about Koobi's code above. If php automatically escapes those characters Koobi's code would make it go back the other way. As a result I in fact decided to try using Koobi's function and found some staggering results! I hate to say it but using the function koobi said above is sceptable to sql injection attacks . Don't try any thing fancy just make sure you put the users input into the quotes and php will take care of the rest!!!

Ref. to the reply below

Originally Posted by Travis Ok I am figuring things out as I go here. get_magic_quotes_gpc -- Gets the current configuration setting of magic quotes gpc If this is on (1) php automatically adds slashes. If it is off (0) php does not add slashes so you should automatically addslashes. Koobi's code does add slashes if it is off which is good. The problem is it strips slashes if it is on which is bad. I will rewrite a better way of doing it in the next post:

You're not following my code carefully.
It addslashes() if get_magic_quotes_gpc() is not on, period.
It ONLY stripslashes() if the second parameter of the function is set to boolean FALSE which is NECESSARY to output your text otherwise it will be slash-hell.

Refer to this post:
http://talkfreelance.com/showpost.ph...62&postcount=3
I've shown you the two instances on how to use the function for both input and output. Try it out and you will understand what it does.

Originally Posted by Travis I think this is all you really need to do but I haven't tested it nor thought of other types of queries that might stuff this up. When I get a chance I will test it and think about it a bit more. PHP Code: <?php function escapeSql($badQuery) {       $badQuery = (get_magic_quotes_gpc()) ? $badQuery : addslashes($badQuery);       return $badQuery;  }  ?>

This code will only work for input, not output which is why I added the extra bit of code in my function...and you've switched the addslashes() function around...
Look this up: http://www.php.net/mysql_real_escape_string




Hope it helps



Read up about SQL injection on the net. There's many ways to do this and there's very simple ways you can prevernt this. You can bring a whole DB down or gain admin access via SQL injection. It's sad to see many sites on the net allowing SQL injection :/

I am going to analyse this carefully. You gave two example usage.

Usage 1 (Input):

Username:
// sorry for my lack of creativity
$username = my_user_name' then something else happens

Query:
$myQuery = ' INSERT INTO myPrefix_myTable
SET username='" . koobi_escapeSql($_POST['username']) . "'";

Statements from function:

$badQuery = (!get_magic_quotes_gpc()) ? addslashes($badQuery) : $badQuery;
$badQuery = (!is_numeric($badQuery)) ? "'" . mysql_real_escape_string($badQuery) . "'" : $badQuery;

Analysis:
This works fine!
Query becomes
INSERT INTO products SET thumnail ='my_user_name\\\' then something else happens'

Usage 2 (output):

Username:
// sorry for my lack of creativity
$username = my_user_name' then something else happens

Query:
$myQuery = ' SELECT *
FROM myPrefix_myTable
WHERE username=' . koobi_escapeSql($_POST['username'], false);

Analysis:
This works fine!
Query becomes
Select * FROM products WHERE category ='my_user_name\\\' then something else happens'

So why did I make such a fuss. Because I changed his queries!
The queries I prepended and appended single quotes in the code. The function mysql_real_escape_string() strips these quotes.

Sorry for saying that your code was wrong. In fact it works fine. Just becareful when you use this method to use the quotes in the query the right way. I would prefer my method though to be honest because you do not have to change the parameters for each function but because I am not using mysql_real_escape_string(), addslashes may miss some things. Again I will investigate this.

Ok The function I showed you is fine with my implementation of the queries.

$query = "Select * FROM products WHERE name ='" . escapeSql($_POST['username']) . "'";

or

$query = "INSERT INTO products SET name ='" . escapeSql($_POST['username']) . "'";

This should work for all types of queries. I haven't tested with magic quotes off though. Let me know if I am wrong please.

Originally Posted by Travis I haven't tested with magic quotes off though. Let me know if I am wrong please.

Test it out for yourself with magic quotes off with all possible instances of SQL injection. There's no better way than to try it out for yourself
If you have magic quotes off, and if you do enter data with the function you posted, then when you SELECT the data for display, you will see some extra slashes...which is why I ALWAYS use stripslashes() and that extra parameter in my function as I've explained in my first post

double post

then when you SELECT the data for display, you will see some extra slashes...

When I use the function I have above if magic quotes are on then it does nothing because slashes are already added, when off it adds the escape characters. When the insert query is executed the escape characters are stripped from what is put into the db. Therefore when you select data no extra slashes will come out. Make sense?

Now in my post above I said yours worked. However I didn't actually put the data in and test it. Look at what is generated from my above examples: 'my_user_name\\\' then something else happens'. You must realise that extra slashes have been added. When mysql goes through and gets rid of the escape characters one will be gone for the slash \ one will be going for the quote '. That means what is inserted into the db will look like this:

'my_user_name\' then something else happens'. Now I can see why you would strip the slashes now but why only when magic quotes are off. It should do that all the time because the insert query is the same whether magic quotes are on or off. Even if the insert query was not the same then it would be bad practice to use the get_magic_quotes_gpc function for a select query because this value may have been changed by the time the data needs to be retrieved.

If you can find a query for my function that results in an SQL incjection or extra slashes at all in the database tell me. I am not criticising your code for the sake of it I am doing it to try and help you and others. If what I tell you is wrong explain to me why and then we both benifit and learn from the process.