RE: [PHP] PHP Security Leak (plaintext)
> $my_val_a = addslashes($HTTP_POST_VARS["val_a"]); > $my_val_b = addslashes($HTTP_POST_VARS["val_b"]); > $query = "INSERT INTO foo (a,b) VALUES ($my_val_a,$my_val_b)"; > > Or if you have magic_quotes_gpc turned on (the default) all vars passed > in from forms/cookies are quoted and SQL injection is not possible. Actually, this way you are not doing anything. By the format of your INSERT statement, you are assuming that $my_val_a and $my_val_b are numbers, since there are no quotes around them. Therefore addslashes() does nothing to prevent the user from putting a value like --> 12,'bad value')# <-- into $my_val_a and putting a bad value into the second column. Now if you validate that the two are numbers, then you won't have this problem. And if you are validating a string, yes then use addslashes(), and the # won't be able to act as a comment, then. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Security Leak (plaintext)
At 4:00 PM -0500 25/4/02, Joshua b. Jore wrote: >"INSERT INTO foo (a,b) VALUES (?,?)" $my_val_a = addslashes($HTTP_POST_VARS["val_a"]); $my_val_b = addslashes($HTTP_POST_VARS["val_b"]); $query = "INSERT INTO foo (a,b) VALUES ($my_val_a,$my_val_b)"; Or if you have magic_quotes_gpc turned on (the default) all vars passed in from forms/cookies are quoted and SQL injection is not possible. ...R. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Security Leak (plaintext)
> I think you misunderstood me. I already have a AuthenticateUser(TEXT,TEXT) > function that works great. What I don't understand is how to get PHP to > use place holders for data binding. This is more generic database issue. I > could have also written: > > "INSERT INTO foo (a,b) VALUES (?,?)" > > where again, the values are passed separately and are *not* interpolated > into the query. That's the point - not interpolating your values to > protect against insertion attack. I'm sure you are already doing this, but enough can't be said for validation. Make sure what you think is a number really is, and that a string is properly quoted...then this won't be a problem. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Security Leak (plaintext)
It's not PHP's place to do this. That being said, check out ADODB. It's a data abstraction layer for several different databases that will give you this functionality. =C= * * Cal Evans * Journeyman Programmer * Techno-Mage * http://www.calevans.com * -Original Message- From: Joshua b. Jore [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 25, 2002 4:00 PM To: Maxim Maletsky (PHPBeginner.com) Cc: [EMAIL PROTECTED] Subject: RE: [PHP] PHP Security Leak (plaintext) Foo. Somehow I encrypted the last message. --[PinePGP]--[begin]-- I think you misunderstood me. I already have a AuthenticateUser(TEXT,TEXT) function that works great. What I don't understand is how to get PHP to use place holders for data binding. This is more generic database issue. I could have also written: "INSERT INTO foo (a,b) VALUES (?,?)" where again, the values are passed separately and are *not* interpolated into the query. That's the point - not interpolating your values to protect against insertion attack. Joshua b. Jore http://www.greentechnologist.org On Thu, 25 Apr 2002, Maxim Maletsky (PHPBeginner.com) wrote: > Create yourself an SQL function that does that :-) > > > > Sincerely, > > Maxim Maletsky > Founder, Chief Developer > > www.PHPBeginner.com // where PHP Begins > > > > > -Original Message- > > From: Joshua b. Jore [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 25, 2002 10:26 PM > > Cc: [EMAIL PROTECTED] > > Subject: RE: [PHP] PHP Security Leak > > > > This brings up another issue, how the heck do you get data binding? > For > > the life of me I don't see where the _query functions support SQL > like: > > > > "SELECT AuthenticateUser(?,?)" where then the first param might be a > > usernamd and the second would be a password. The idea is that without > this > > sort of thing you are vunerable to SQL insertion attacks. > > > > Joshua b. Jore > > http://www.greentechnologist.org > > > > On Thu, 25 Apr 2002, Maxim Maletsky (PHPBeginner.com) wrote: > > > > > > -Original Message- > > > > From: Liam Gibbs [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, April 25, 2002 8:20 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [PHP] PHP Security Leak > > > > > > > > I'm wondering if anyone has any ideas on how to make a > > > > login site more secure. Since I'm not really sure if > > > > I've explained myself well enough and don't really > > > > know how else to say it, I'll just give examples and > > > > then you guys can follow suit and mention some > > > > oversights: > > > > > > > > I have a regular logon: username and password. What it > > > > does is, when the user types in a name and pword, it > > > > forwards to another PHP page (a 'middleman' page that > > > > is there just to compare usernames and pwords), > > > > validates by checking the SQL database, then header > > > > forwards to the login page. A cookie is created, and > > > > voila, you're allowed into what we'll call the > > > > 'account pages'. Now, here's my 'security' (notice the > > > > quotes): > > > > 1. You can't log in when the URL includes a username > > > > and/or a password (so that no one can make direct > > > > links). > > > > 2. Same with an account page: you're redirected to the > > > > login page if you include a username and pword when > > > > linking to an account page. > > > > 3. The 'middleman' page also has this protection: you > > > > cna't directly link to it with a username and pword in > > > > the URL. Basically, users can't get into anything when > > > > they include a username and pword in the URL. > > > > 4. Obviously, you don't get access if your username > > > > and password don't match anything in the database > > > > (thought I'd mention it even though it goes without > > > > saying). > > > > 5. You can't login from a page that isn't on the > > > > server. > > > > > > > > Is there any validation or security holes that I'm > > > > overlooking? > > > > > > > > > > > > > > at least this two: > > > > > > 1. Use SSL > > > 2. Store passwords MD5 encrypted in the DB > > > > > > > > > > > > Sincerely, > > > > > > Maxim Maletsky > > > Founder, Chief Developer > > > > > > www.PHPBeginner.com // where PHP Begins -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Security Leak (plaintext)
Foo. Somehow I encrypted the last message. --[PinePGP]--[begin]-- I think you misunderstood me. I already have a AuthenticateUser(TEXT,TEXT) function that works great. What I don't understand is how to get PHP to use place holders for data binding. This is more generic database issue. I could have also written: "INSERT INTO foo (a,b) VALUES (?,?)" where again, the values are passed separately and are *not* interpolated into the query. That's the point - not interpolating your values to protect against insertion attack. Joshua b. Jore http://www.greentechnologist.org On Thu, 25 Apr 2002, Maxim Maletsky (PHPBeginner.com) wrote: > Create yourself an SQL function that does that :-) > > > > Sincerely, > > Maxim Maletsky > Founder, Chief Developer > > www.PHPBeginner.com // where PHP Begins > > > > > -Original Message- > > From: Joshua b. Jore [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 25, 2002 10:26 PM > > Cc: [EMAIL PROTECTED] > > Subject: RE: [PHP] PHP Security Leak > > > > This brings up another issue, how the heck do you get data binding? > For > > the life of me I don't see where the _query functions support SQL > like: > > > > "SELECT AuthenticateUser(?,?)" where then the first param might be a > > usernamd and the second would be a password. The idea is that without > this > > sort of thing you are vunerable to SQL insertion attacks. > > > > Joshua b. Jore > > http://www.greentechnologist.org > > > > On Thu, 25 Apr 2002, Maxim Maletsky (PHPBeginner.com) wrote: > > > > > > -Original Message- > > > > From: Liam Gibbs [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, April 25, 2002 8:20 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [PHP] PHP Security Leak > > > > > > > > I'm wondering if anyone has any ideas on how to make a > > > > login site more secure. Since I'm not really sure if > > > > I've explained myself well enough and don't really > > > > know how else to say it, I'll just give examples and > > > > then you guys can follow suit and mention some > > > > oversights: > > > > > > > > I have a regular logon: username and password. What it > > > > does is, when the user types in a name and pword, it > > > > forwards to another PHP page (a 'middleman' page that > > > > is there just to compare usernames and pwords), > > > > validates by checking the SQL database, then header > > > > forwards to the login page. A cookie is created, and > > > > voila, you're allowed into what we'll call the > > > > 'account pages'. Now, here's my 'security' (notice the > > > > quotes): > > > > 1. You can't log in when the URL includes a username > > > > and/or a password (so that no one can make direct > > > > links). > > > > 2. Same with an account page: you're redirected to the > > > > login page if you include a username and pword when > > > > linking to an account page. > > > > 3. The 'middleman' page also has this protection: you > > > > cna't directly link to it with a username and pword in > > > > the URL. Basically, users can't get into anything when > > > > they include a username and pword in the URL. > > > > 4. Obviously, you don't get access if your username > > > > and password don't match anything in the database > > > > (thought I'd mention it even though it goes without > > > > saying). > > > > 5. You can't login from a page that isn't on the > > > > server. > > > > > > > > Is there any validation or security holes that I'm > > > > overlooking? > > > > > > > > > > > > > > at least this two: > > > > > > 1. Use SSL > > > 2. Store passwords MD5 encrypted in the DB > > > > > > > > > > > > Sincerely, > > > > > > Maxim Maletsky > > > Founder, Chief Developer > > > > > > www.PHPBeginner.com // where PHP Begins -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
