Jump to content

PHP/SQL Security


bshreff

Recommended Posts

I am currently working on a site for a friend and have created my own user management system (using PHP and sessions).How can I prevent people from hacking my site? I have been using mysql_real_escape_string() for all the posts that I use in sql commands, but is that enough? Should I be doing more?Thanks for any help.

Link to comment
Share on other sites

For SQL injection, that's all.But overall, there are too many more things to consider.Are your session IDs easily guessable? Have you made the mistake of using them in the URLs? (Not that "not" having them would stop a keen attacker, but still...).Do you use the POST method for sending sensetive stuff (e.g. the password)?When the user enters a wrong username and/or password, do you give a generic error message ("wrong username and/or password"), or is it specifc ("wrong username" and "wrong password")? You should use the former approach.Do you hash the password(s?) in the DB? How about "salt"-ing them?Do you limit access by IPs? Are you sure the list is not visible and not editable by anyone not already allowed?I could go on all day... but then again, where I live, the night has just begun, so I'll stop :) .

Link to comment
Share on other sites

For SQL injection, that's all.But overall, there are too many more things to consider.Are your session IDs easily guessable? Have you made the mistake of using them in the URLs? (Not that "not" having them would stop a keen attacker, but still...).Do you use the POST method for sending sensetive stuff (e.g. the password)?When the user enters a wrong username and/or password, do you give a generic error message ("wrong username and/or password"), or is it specifc ("wrong username" and "wrong password")? You should use the former approach.Do you hash the password(s?) in the DB? How about "salt"-ing them?Do you limit access by IPs? Are you sure the list is not visible and not editable by anyone not already allowed?I could go on all day... but then again, where I live, the night has just begun, so I'll stop :) .
Fancy :) I would add htmlspecialchars aswell for all get's and post's you use in the php script so you are sure no one adds some fancy php lines for you.
Link to comment
Share on other sites

Fancy :) I would add htmlspecialchars aswell for all get's and post's you use in the php script so you are sure no one adds some fancy php lines for you.
I know that this is not my topic, but security is a matter of important concern for me, as I have been the subject of hackers in the past. Could you please be more specific about how the adding of HTML special characters can deter the unwanted appearance of php scripts to get and post data transfers? Or, have I misunderstood?Roddy
Link to comment
Share on other sites

The problem is more on the client-side than with PHP (because, e.g., echo "`rm -r /`" will not do anything untoward). Also note that data filtering through functions like htmlspecialchars() should be done at output, not input (what if the data, for example, was edited later?). Nevertheless, HTML sanitization aims to prevent XSS.

Link to comment
Share on other sites

For SQL injection, that's all.But overall, there are too many more things to consider.Are your session IDs easily guessable? Have you made the mistake of using them in the URLs? (Not that "not" having them would stop a keen attacker, but still...).Do you use the POST method for sending sensetive stuff (e.g. the password)?When the user enters a wrong username and/or password, do you give a generic error message ("wrong username and/or password"), or is it specifc ("wrong username" and "wrong password")? You should use the former approach.Do you hash the password(s?) in the DB? How about "salt"-ing them?Do you limit access by IPs? Are you sure the list is not visible and not editable by anyone not already allowed?I could go on all day... but then again, where I live, the night has just begun, so I'll stop :) .
My IDs are somewhat guessable. If someone knew those they could hack it? how do they manage that without being able to access the server? None of the session IDs are used in the URL's.I use POST method on almost everything.I use generic error messages.I do md5 hashes for my passwords before they're put into the database or checked.Every page load checks the IP address of the user and matches it against the IP used on login. If they don't, it automatically logs you out.Thanks for the help.
Link to comment
Share on other sites

My IDs are somewhat guessable. If someone knew those they could hack it? how do they manage that without being able to access the server?
They can forge an HTTP request that contains the session ID. With the right ID supplied, PHP will restore their session data, therefore potentially giving them unauthorized access.However, if you check the IP address they logged in from, keep that IP in the session and check it on every request, attackers won't be able to get access, even if they supply the right session ID, since the IPs won't match. As far as I understand, that's what you're already doing, so - good job.BTW, I'm not sure logging the user out on IP mismatch is a good idea. This means the legitimate user will have their session disconnected, while the attacker may try to regain access on their own computer.Note that this also means you have to educate the user of the panel to manually click "Log out" when they's finished, or only work from one PC. Doing otherwise means they'll be denied access until their old session expires.That reminds me... when users log in, do you also check if the same user is already logged in? Since you're also binding access by IP, it makes sence to check if another IP isn't already logged in. Otherwise, attackers may try to "brute force" the login, and upon success, disconnect the legitimate user and/or deny him any further access, since their IP will now be binded to the only allowed session.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...