Simple SQL question

[pushVTEC]

I get:

You have an error in your SQL syntax near 'AND pword=d41d8cd98f00b204e9800998ecf8427e' at line 1

every time I try to run this php

$query = "SELECT username, pword, userid from AUSER WHERE username=$username AND pword=".md5($password);

anyone know why? I am connected to the database fine and everything what's wrong?

 

[mugs]

$query = "SELECT username, pword, userid from AUSER WHERE username='$username' AND pword='".md5($password)."'";

(single quotes around the username and password values)

 

[UCJefe]

Mugs is right.

By the way, I hope you are doing some good checking on your $username and $password variables if they are coming from user input. You have to VERY careful building your SQL like this or you'll leave yourself wide open to SQL injection attacks. I STRONGLY recommend either using parameterized queries or stored procs.

 

[stndn]

^ what he said

btw, for password and md5(), i like to use mysql's MD5() instead of that from PHP. Either way works, though.

If you're using mysql's MD5, put the single quotes around your $password:
$query = "SELECT username, pword, userid from AUSER WHERE username = '$username' AND pword = MD5('$password')";

As a general rule, anything that's text in SQL query needs to be 'single-quoted'

 

[mugs]

Originally posted by: UCJefe
Mugs is right.

By the way, I hope you are doing some good checking on your $username and $password variables if they are coming from user input. You have to VERY careful building your SQL like this or you'll leave yourself wide open to SQL injection attacks. I STRONGLY recommend either using parameterized queries or stored procs.

Is there any easy way to prevent SQL injection attacks with PHP/MySQL? Seems to me that using addslashes() on any string inputs would go a long way to preventing them. is_numeric() would cover numeric inputs. Is anything else necessary?

 

[torpid]

Originally posted by: UCJefe
Mugs is right.

By the way, I hope you are doing some good checking on your $username and $password variables if they are coming from user input. You have to VERY careful building your SQL like this or you'll leave yourself wide open to SQL injection attacks. I STRONGLY recommend either using parameterized queries or stored procs.

Why would he need to worry about injection in the password if he's running an md5 algorithm on it?

 

[Bulldog13]

Originally posted by: mugs

Originally posted by: UCJefe
Mugs is right.

By the way, I hope you are doing some good checking on your $username and $password variables if they are coming from user input. You have to VERY careful building your SQL like this or you'll leave yourself wide open to SQL injection attacks. I STRONGLY recommend either using parameterized queries or stored procs.

Is there any easy way to prevent SQL injection attacks with PHP/MySQL? Seems to me that using addslashes() on any string inputs would go a long way to preventing them. is_numeric() would cover numeric inputs. Is anything else necessary?

Don't know if this helps...


http://www.vbmysql.com/article...rity/sqlinjection.html

 

[UCJefe]

Originally posted by: torpid

Originally posted by: UCJefe
Mugs is right.

By the way, I hope you are doing some good checking on your $username and $password variables if they are coming from user input. You have to VERY careful building your SQL like this or you'll leave yourself wide open to SQL injection attacks. I STRONGLY recommend either using parameterized queries or stored procs.

Why would he need to worry about injection in the password if he's running an md5 algorithm on it?

Yeah, that's fine for the password, but what about the username.

The easiest ways to combat SQL injection are by either using parameterized queries or stored procs. I believe mySQL supports both but I'm not 100% sure on that. Your other option is to cleanse the input by running a regex on it or something; making sure the input only contains alphanumeric and not the dangerous characters like ' or --. The problem with that, is that there will probably always be some sort of input that can slip by you and that is generally not a good solution. Avoiding dynamically constructing SQL strings is always a good idea.