[adn258]

So I scared the crap out of myself earlier. I created a comment system on my site where each comment has an id that increments and another id that corresponds to a username which are ALL UNIQUE and the poster whom posted it.

Everything works fine, but I created a comment deletion page where a user can check their past comments check mark them and hit delete to delete them. This worked fine but I programmed it to only bring up the comments they posted via their username and then I set them to delete on the action php script via that comments unique incremental ID as well; BIG MISTAKE!!

I forgot to use and to compare the current user in session AND check the comment ID instead I just deleted comments based on the comment ID and not the comment ID and the poster i.e. user.

So I tried it I fired up XAMMP and starting throwing PHP $_POST actions from my own machine 127.0.0.1 at the remote PHP action script hosted on my site by go daddy and since there was no checking of the user someone could simply delete ANY comment from the table by POSTING a any comment ID they wanted...If I left this alone I'd soon get my own comment moderator and I might not even know it(Oh Great!).

I'm not quite used to web programming based stuff yet and this just came to me tonight. Nobody exploited this vulnerability but it scares the crap out of me. I really never thought about users posting their own malicious stuff out of the bounds of what I thought they can do.

So I know a lot of you are like this guys an idiot but I'm learning. I know about SQL injection but what the heck is it called when someone sends MALICIOUS POSTS to an action php script?

The last part of my question is what can I do besides (pay more attention to checks and bounds of a MYSQL commands) to keep this kind of scary crap from happening? I'm scared!!

This post has been edited by adn258: 03 October 2012 - 02:11 AM

[JackOfAllTrades]

You could start by reading the PHP and Security Links topic pinned at the top of the PHP forum.

[RudiVisser]

Erm just make people log in to post a comment and log in to delete their comments.

If there's no login system then you have no real way to fix this cos cookies can be deleted/spoofed for client side auth and whatever else.

[CTphpnwb]

adn258, on 03 October 2012 - 05:09 AM, said:

So I know a lot of you are like this guys an idiot but I'm learning. I know about SQL injection but what the heck is it called when someone sends MALICIOUS POSTS to an action php script?

It's called cross site scripting (xss) and it can also be used to insert malicious Javascript into your site. Never trust user input. Validate everything. And use prepared statements, not deprecated mysql functions!

[adn258]

JackOfAllTrades, on 03 October 2012 - 02:27 AM, said:

You could start by reading the PHP and Security Links topic pinned at the top of the PHP forum.

Thanks I will read this.

To CTphpnwb this wouldn't have helped in my case I checked the prepared statement would have come back true and would have gotten executed thus deleting the comment by ID. The thing that saved me here which I added is checked the user in session with the comment ID both so a user can't delete comments using their own crafted POST instead of check boxes OUTSIDE their username. Correct me if I am wrong?

This post has been edited by adn258: 03 October 2012 - 11:57 AM

[CTphpnwb]

Prepared statements protect against SQL injection attacks and should be used as a matter of policy. There is no point in protecting against this attack but leaving open the more (or at least as) common method of attack.

[adn258]

CTphpnwb, on 03 October 2012 - 12:17 PM, said:

Prepared statements protect against SQL injection attacks and should be used as a matter of policy. There is no point in protecting against this attack but leaving open the more (or at least as) common method of attack.

Ok thanks guys I appreciate that. So just messing around with this stuff *trying to learn* I have a few questions that desperately need answering

So I get the whole SQL injection thing and in this example let's take for simplicity sake the below where bloggedin when set to true shows pages private user only content

$query = "SELECT username FROM users WHERE username = '$username' AND password = '$password';";
$result = $mysqli->query($query);
if ($result->num_rows != 0)
{
	session_start();
	$_SESSION['bloggedin'] = true;
	$_SESSION['user'] = $_POST['username'];
	
	header("Location:index.php?Msg=You Have Logged In Successfully Look At Our Private Data");
	die();
}
else
{
	echo "Incorrect Username Or Password Combination";
}

Being very ugly and simplistic this works but it's vulnerable to the classic ' OR 1=1 # and I get the comment part etc. and I get why it works. Now I know you can use the whole
$mysqli->real_escape_string(

AND THAT DOES PREVENT that and it probably would prevent most attacks (I've used this) and I get why that works. What I don't get is the whole prepared statement thing and why it works. Goes back to my example if you use

$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT password FROM users WHERE username = ? AND password = ?;";
$result = $mysqli->prepare($query);
$result->bind_param("ss",$username,$password);
$result->execute();
$result->store_result();

if ($result->num_rows != 0)
{
	session_start();
	$_SESSION['bloggedin'] = true;
	$_SESSION['user'] = $_POST['username'];
	
	header("Location:index.php?Msg=You Have Logged In Successfully Look At Our Private Data");
	die();
}
else
{
	echo "Incorrect Username Or Password Combination";
}

You guys are correct that SQL injection statements like ' OR 1=1 # NO LONGER WORKS...BUT WHY?? I don't get it?
What magic thing happens when you bind those parameters?

This leads me to a few other questions and I appreciate the help. Using the above is there any reason to use the real_escape_string ?? I'm assuming for extra security it doesn't hurt right?

Okay and then for whatever reason whenever I use prepared statements like the above I can't use

(using my example)

$result->bind_param("ss",$username,$password);
$result->execute();
$result->store_result()
$result->bind_result($the_user)

The binding result stores NOTHING in the variables that it's supposed to why? I know this is a lot but if these questions are answered I think I really get a starting good grasp of this!!

[CTphpnwb]

Prepared statements are "prepared" in advance. Everything that comes after preparing the statement is just data and cannot affect the SQL so no matter what the user enters only the prepared SQL will be executed.

[e_i_pi]

When using Prepared Statements, you are automagically protected against injection strings like OR 1=1 #. This is because, in the process of preparing a statement, the PDO driver treats statement as a query string, with the ? placeholders as variables, not as part of the query string. Once the query is reduced to a statement that takes parameters, then malicious alteration attempts to your query string are no longer possible, as "malicious" data is in the form of variables. This doesn't mean you shouldn't verify and validate incoming user data, but it does mean that any data that comes in will no longer be able to alter the query string, and hence the query result expectation, itself.

Another way of thinking of it is that Prepared Statements are like functions, rather than evaluated code.

This post has been edited by e_i_pi: 03 October 2012 - 08:19 PM

[adn258]

Thanks guys. This makes sense now to me. The last thing though which was part of my last question is for added security should I still use real escape string functions, and lastly why when I used prepared statements like above I can't use

$result->bind_param("ss",$username,$password);
$result->execute();
$result->store_result()
$result->bind_result($the_user)

The bind_result doesn't seem to work after that? Thanks guys this was very helpful

[e_i_pi]

Is that's the code pasted verbatim, then I would say check you semi-colons

[Dormilich]

adn258, on 04 October 2012 - 07:01 AM, said:

The last thing though which was part of my last question is for added security should I still use real escape string functions

if you want the escape characters (\) in your data ...

[adn258]

There is one part of my site and I don't want to go into too many details but essentially I CAN'T USE PREPARED STATEMENT very well because I'm trying to return from a class an array of data and I use
fetch_assoc to retrieve and associative array and return it from the method.

I can't use things like fetch_array or get_result apparently because I was reading you need some sort of DRIVER or something to make those mysqli param functions work and you have to work with bind_result and bind_param basically...makes me mad, but this is a part of my site where $_GET is used and it has to do with bringing up content based on an ID and echoing things out so I'm assuming this is way more LOW RISK than a login page

I still use the real escape string on the $_GET variable because the user could still try to type malicious links in? I'm assuming this is probably enough for this case but I would love suggestions.

[CTphpnwb]

adn258, on 04 October 2012 - 04:50 PM, said:

There is one part of my site and I don't want to go into too many details but essentially I CAN'T USE PREPARED STATEMENT very well because I'm trying to return from a class an array of data and I use fetch_assoc to retrieve and associative array and return it from the method.

That's just wrong. You need to study prepared statements. Here's a great PDO tutorial.

adn258, on 04 October 2012 - 04:50 PM, said:

I can't use things like fetch_array or get_result apparently because I was reading you need some sort of DRIVER or something to make those mysqli param functions work and you have to work with bind_result and bind_param basically...makes me mad, but this is a part of my site where $_GET is used and it has to do with bringing up content based on an ID and echoing things out so I'm assuming this is way more LOW RISK than a login page

Also wrong. Get is easily manipulated. Session variables are not.

[adn258]

CTphpnwb, on 04 October 2012 - 05:15 PM, said:

adn258, on 04 October 2012 - 04:50 PM, said:

There is one part of my site and I don't want to go into too many details but essentially I CAN'T USE PREPARED STATEMENT very well because I'm trying to return from a class an array of data and I use fetch_assoc to retrieve and associative array and return it from the method.

That's just wrong. You need to study prepared statements. Here's a great PDO tutorial.

adn258, on 04 October 2012 - 04:50 PM, said:

I can't use things like fetch_array or get_result apparently because I was reading you need some sort of DRIVER or something to make those mysqli param functions work and you have to work with bind_result and bind_param basically...makes me mad, but this is a part of my site where $_GET is used and it has to do with bringing up content based on an ID and echoing things out so I'm assuming this is way more LOW RISK than a login page

Also wrong. Get is easily manipulated. Session variables are not.

But I read somewhere that you can't use the functions I was talking about in mysqli without some like mysdli driver in the server or something? Seriously I tried to use get_result it doesn't work function is undefined. I could use PDO instead for this one part of my site (maybe I'll have too) but on a personal note whenever possible for what I'm trying to do I don't like using PDO I prefer mysqli