1

I want to / am busy with completely re-writing my whole site. At this point I am working on what I call "members- and safety engine". I have been reading a lot about security and SQL injection, and it is pretty complicated. ps. My site is more a hobby than a professional money making website with about 250+ members.

For username AND password I only allow the characters a-z, A-Z and 0-9. I check this in the if(isset(post))-function with:

if(ctype_alnum(mysql_real_escape_string(stripslashes($string))) == false) {
    header to error-page; exit;}
else {continu with script}

This check is done for both the password and the username.

When somebody tries to login with a unknown username or a known username with a wrong password the action is logged (inserted) in a special table, including IP address. After 10 attempts to login with an unknown username, or 6 attempts with a wrong password the IP address is blocked from the members area and on all the non-member pages forms and submit of the forms are not shown and they are not useable because of this ip-block. I even have this ip-check as a line when the form is submitted... if the ip is in the table, header(to error page); exit;.

My questions:

  • Do I have to make a security check when I place the IP address in a string? $xip = $_SERVER['REMOTE_ADDR']; this $xip is inserted in the table when trying to log in with a unknown user or with wrong password.
  • Is this a (pretty) safe environment against hacking and SQL injection?
  • If not? I really appreciate help and suggestions (writing the complete solution here is very much appreciated, but I learn a lot more when you send me on the right path to the solution)
  • Do I also have to run the "ctype_alnum" check when I retrieve this info from the $_cookie or the $_session?

ps. I am dutch, so almost all of my table names, column names, form input-field-names etc etc etc have a dutch word for it. I am still working on it, but when the site is finished you will not find the word "password", "pass", "user", "userid", or anything like that on my site.

AstroCB
  • 12,337
  • 20
  • 57
  • 73
user2414353
  • 11
  • 2
  • 2
    If you're rewriting your whole site, then rewrite it using MySQLi or PDO with prepared statements rather than rewriting it with the MySQL library – Mark Baker May 23 '13 at 16:50

2 Answers2

1

Using prepared statements with MySQLi or PDO is a must as a first step to preventing SQL injection, and the mysql_* commands are deprecated anyway.

But, the best place to answer your questions for best practices at preventing SQL Injection would be OWASP: They have many great resources for both general methodologies and review of code, as well as language-specific guidelines and libraries.

https://www.owasp.org/index.php/Guide_to_SQL_Injection https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection

cerd
  • 2,171
  • 1
  • 18
  • 28
0
  1. No you don't have to, this variable is safe. Have a look at : Is it safe to trust serverremot addr
  2. It depends, you will have to post the entire authentication code
  3. Usually a good practice is to select every users from the DB, then iterate over them and compare username/password in order to find a match. That way you don't need to place user input in the SQL statement.
  4. It depends what you do with the content of these
Community
  • 1
  • 1
dna
  • 1,085
  • 7
  • 15
  • thanx very much. at 2. what do you mean with "you will have to post the entire authentication code"? and at 4. i guess... when i use this retrieved info from cookie or session within a form i should do the ctype_alnum check, otherwise it is save to use. – user2414353 May 23 '13 at 17:23
  • Well your question focuses on the user authentication part so it's pretty hard to tell if it's safe without looking at it. Now concerning the $_COOKIE and $_SESSION array's members, you want to take care of them if they are used in an SQL statement, especially for the $_COOKIE array. Using prepared statement is definitively a must since you can get rid of all the the evil that might be encapsulated into your variables. – dna May 23 '13 at 17:44