RE: [PHP] PHP Security Leak
-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 __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- 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
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 __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP Security Leak
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 __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- 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 -- 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
-BEGIN PGP MESSAGE- Comment: For info see http://www.gnupg.org owGlWL9vHMcVlmy4IcDCQIC0L2qONJZLibGS4GDrN63QpkRFRyURDEGY2527Hd3s znpmlucNYDduXLhwlyqA/4BUaVwZSJogQJIirowAKVykc7oAQrp8b3bvdu9ES5bM I4i7mX1v3rz3fd97x083Xz770qsffPPOHz6JPv/p2b9+48+88Rf15QH5TBUzqk1F uXJVkUrrvDEp5TKmAxLaSpHWlIkTSYKuVj6ThVeJ8PKek3breP/XxxH/2d7cmFRF 4pUp4FJ4mhs7czSFuY/pV7xyQKkpBp7aQ0SRknKUmTl5Q1Pp6c7P7+Dt5kblJJVa JBKbmp+libGUCi9orIpUFdOYjjPY4jc3VsK4kFYl4ZGxgLVyruL4NzcSU+m0DV87 Q3OrvJfFcHNjc+Pcwe3R/t1jOrh9fIQjDG2JaLxNv7x6eG9/RFuXo8vb5/i5eSZx iJgKVUS4nKQToSvpSGC1FM7JlJwshUVSdE18L955rTD+NVKFl7Y0Gnvp5gY+meDh vUramm8h/MCFldJgk3YIVj0j3JVrYxdHcnpKa7xMfBOQ46dRiZB44b1IZjHH/LZx WYV8xfQ2MrS5kXlfDnd35/N5jJqghjLJCqPNVDkfGztlm6MCAVUR7V2kq6WlvfPn 9yK6Jd5XOf5q6d2spi0U6ZqcqgIZjxOTbyOjCCfk8xJd53LLELGTeoJc0OgXh7SK jNTwRfjdcAewubT8pZEqEqRa11G7sHo4r7xlAnwiup4pOaEb8kRqU0rbGvD91iIk ot1damrICAt7buXcS7TDP0dWYUtouiWdE1MZFpv9t6zJh7SaVHo3F0p7M3yE5Sun ZvVBYz3CzpBza10q6oizqzTSHIUc04Xzw72f0J1bzcPXkyGVWbkTQC30FQ1fLsZK XEjf+qvGj4CAId3dH9K7uNSDcLORTCrAu6ZDKWbhyebxwJWxBZYcVSWKYgA425Ak aggIAGYymaE2QQqYjX2+XW5Sbxt//LRWE0lmAplY8tpJ2aaZH3gYIL4svSNXlaWx ngHBbrSaMWqWQZ4b7R/uXz9+UmICDTvHRfA+UVAQYs7l0K1p5mkMhjaeIB+2EHka mMgPO5kYvJ0HKeDnAmshUCkzEGqRSsFa0uiW8pmpQqIhja5x6Thw3JbFMhAyMPyk 4gqNtWQBY5yvM9HFvQuuM5LXns3Kpfn3I+fSzXcBewf4Q4X83lTjsVuCXWNpyitX apEZw8c86MyegfSfDffOL4EeoGmeCfYVwD8N7LRyyYNBjoqzVnDJFGtRbQrAXDh+ G4ruCKVqG1AuZksE8YuLUJBTkLPQYxyfh54SNCp4Z6WG3mlovsMWzuifjoYj30cX UwXaQ14HOZxLrUkWpppmAZwNbxofne2sQEQcldQuQMsJhOsjOIX5owrAn6rgXuSl 5j5UpJ11oEjgcFU7SqDAE6M1vLlK+XBqzvTCxZ3JZWdnTtBomUlueFo2FxOAldNK C8vpMcVwwTUZHHesCv1e9QoYNF+5iHncMJgtydclr4Mv1HlhF9GKNdr/XNiU299S vRgDJXCLpk2DXKWplrkoBs0aM7kzD9Rm+Qi5gw9gtmQCL6J33cFuO+oM0XQVZBD7 45oSFkjGEkfPbF9MG1GT8wyDkrSnBx0UMwCKw4vpKkIwM8WDCiWhZ+LGK2U8MUqL iAs54NmDKwgchflhHmRKMhgSbLDzzm4gEow8hQ8HuUFMt80cGo/bY87Iaxq4ljcD 2kImVSJX7d+rIBhuu8MAXYjpPuAEJAGruASXa1nFe3dZ9RJdpZzEZUI7a1xqF8Nb J7m05UyjtIUhJiRDNJAvVRYc7zEQg6nbjruFPbCPUcISzaNF/6rDRaqsbPwgW03i 1ykdAAI9YI60ofci75AQLrkaTai+WT+6F+GPm4byBB7D6MnKwy2F2gFOMYEQRWee FAI5buKHqvCRfJ7y7ZVPi1IVK9znisR0TTjF2IACs4lrq8dtPUAIAti0stU7wr5+ ek7Usuy9W78e09H4RJnK8YGc10bY+DgkCv2lzbc9HSAdNhq7XPgk62Jsz1zQrTPd 4k7Nvf9g0KkakoWZkE2CzOLjlLWn19abF0QVzvvwurgGdJw7QRcM2G01BXzlzTDJ 9gLBpaCe8Wm6uZAebjmtnHCUoMSCiPwlZzEQo62sKrJmmWjnr1XX7ZvFZxhrNDTf IMzPzXDtAdAY4xSNRoeLFaaTN+13mKB9dOvGRfSnxNall8ti37i26mrN8crQ3t94 cnjn11MG+L7x8wzy3x5brxIPn/uns71hAjLu88Dzo64W7QLdDC1kh7+zhjbh0OfG GP+mIs8NvjKWxuim8y4HP361w9+UrePlMLV7Suz9wYxvfrOZlpBbpZkhh5iaaKs3 TLYD1O52f9LCF29XjV1i1Rg9609nThSmmyGdYhYe5E9PTW4X1YvFtB7Ri8XTm20X Ab1IOC8WTPcVsjn7+U/+Hud+fPnlV87yP3EW/9V59aU3/3jms7/98PU//+/x37/6 zdcXfvffrx7+/l8/+O39M5/9+43Jw4+Sx4/Pfv3h+Isv//Pgn9nRP/4P =qO6f -END PGP MESSAGE- -- 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
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)
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)
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)
$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
