authentication for user logins & passwords

[cbassett01]

Sorry if this really isn't a PHP question, but I've got an HTML form that asks for a user name and password (for logging into a site).  The HTML form then calls a PHP file which will process the request and verify (with a table in the MYSQL database) the user's name and password and either let the user into the site or not.

 

Now, my question is from the HTML page that is displayed to the user to get the user name and password.  What is to prevent someone from grabbing the field names from the HTML file and then creating their own script on their own site, referencing my PHP script on my server which accesses my database.  Can I prevent someone from remotely accessing my scripts from another website?

 

Additionally, what's to prevent someone from seeing the field names in the HTML form and then feeding these variables to the PHP script via the address bar? 

 

How are these issues generally handled?  I'm using PHP sessions for security reasons.

 

(I'll be honest... I'm pretty fluent in PHP, but am new to the topic of "sessions" in PHP, encryption, and stuff relating to those subjects).

[cssfreakie]

Can I prevent someone from remotely accessing my scripts from another website?

You might want to have a look in to something called form tokens. In a nutshell: by using good form tokens you can prevent direct access to your processing scripts.

 

Besides that it might be wise to implement some sort of system that limits the amount of attempts to login and add something like a captcha.

 

am new to the topic of "sessions" in PHP, encryption, and stuff relating to those subjects

these are pretty much security questions. For more info. Some things to look at http://phpsec.org, http://shiflett.org/ (buy his book) read http://www.phpfreaks.com/tutorial/php-security and google your butt off 

 

hope this helps

[Psycho]

If your form is set up to send data via POST AND you are properly referencing them (i.e. using $_POST and NOT $_REQUEST) then it is impossible for users to "feeding these variables to the PHP script via the address bar?". Your processing page should be referencing the variables as $_POST and not $_GET - as they would if appended to the query string.

 

Now, as for someone creating a copy of your form and submitting it to your page, yes that is a possibility. But, do realize that just because the data comes from someone else's form and not yours does not make it any more or less secure. But, you can prevnt it by using $_SERVER['REQUEST_URI'] or you could populate the form with a hidden variable that you check on the processing page. It could be a session variable or it could be a random value that you populate into a DB for a one-time use. It all depends on wha you are really trying to achieve and how elaborate you want to get.

[cbassett01]

So the "$_SERVER[REUQEST_URI]" variable looks at the file/document making the request to the PHP file?  Is that what this variable/function does?

 

I can prevent hotlinking to file directly, so this might help as well (as in, I can only allow pages that have the base domain, such as www.mydomain.com, to access files on the site and not allow "outside" sources access or direct access  to files).  I think many web hosts refer to this has "hotlink protection."

 

I have been using the $_POST array, and NOT the $_GET or $_REQUEST array.  I just wanted to make sure that for the most part, people can't do something like this from my login page:

 

www.mydomain.com/authenticate.php?UserName=someuser&Pass=something

 

So if I use $_POST in my PHP script that processes the log in, this above web address (supposedly feeding parameters to the PHP script) shouldn't work, right?

 

 

[Psycho]

www.mydomain.com/authenticate.php?UserName=someuser&Pass=something

 

So if I use $_POST in my PHP script that processes the log in, this above web address (supposedly feeding parameters to the PHP script) shouldn't work, right?

 

if variables are passed on the query string they cannot be referenced via $_POST. So, yes, that link above wouldn't work.