-1

i have read many things here about how to prevent SQL injection also on other website and forums. Only thing is thats it makes me really confused on the way how to protect your website when writing stuff to the database.

I'm creating as schol project something where there alot of input from the users wil be writte to the database, i'm currently check them by javascript if they contains iligal char. Then i use ajax to activate my controller, use the query in my model send it back to the view.

But lets go on on my problem.

If i validate a input first with javascript, (client-side), then server side with PHP. If i first check in php if the input contains iligal char like * '' `` > <, that kind of things. What you whould use in a query for geting information from the database. Then escape the whitescpases since i don't want to have things with spaces on the website as users input.

Then use mysqli_real_escape_string() on the input. Then send it to the query that will looks like this.

/**
* @param string
* @param string
* @return mixed
*/
public function updateUsername($oldUsername, $newUsername) {
    return $this->_db->query("UPDATE `users` SET `username` = :new_username WHERE `username` = :old_username",
        [':new_username' => $newUsername,':old_username' => $oldUsername]);
}

So 1 > Check using javascript
2 > Check by php on char like * < > ' #
3 > using mysqli_real_escape_string()
4 > To the PDO query

Is this a good way for prefending SQL injection, i really don't want to send my school project live in the air with SQL injection haha.

Greetz,

Also many thanks for reading my long story

AddcitedToLearn
  • 398
  • 2
  • 18
  • See : http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php should pretty much cover any SQL injection question you can come up with :) – CD001 Mar 27 '15 at 16:48
  • 1
    If you're using parametrised queries - as you are here - then `mysqli_real_escape_string` is overkill and will break things. – Niet the Dark Absol Mar 27 '15 at 16:50
  • 1
    Note that the Javascript validation is nice because it catches accidental errors early, but you should view it as a convenience for the legit user and not as a real protection. After all, any malicious user can submit a form directly to the URL, completely circumventing any JavaScript. Therefore you cannot rely on any client-side scripting. – CompuChip Mar 27 '15 at 16:50
  • hi @CompuChip yes indead, also javascript kan by manipulate since its just client-side validation. – AddcitedToLearn Mar 27 '15 at 16:57
  • @NiettheDarkAbsol Hi, thanks i dind't now that. For the rest if i don't use that this wil be safe ? – AddcitedToLearn Mar 27 '15 at 16:57
  • Parameterising your query is *all* you need. Changing anything else will break something. The trick to proper security is to know the implications of what you are doing ;) – Niet the Dark Absol Mar 27 '15 at 16:58
  • So actualy, i do not need my php validation on this ? @NiettheDarkAbsol . – AddcitedToLearn Mar 27 '15 at 16:59
  • Nope. Just remember, when outputting it to the browser, you will need to use something like `htmlspecialchars`. But you do that on output, not when saving to the database. – Niet the Dark Absol Mar 27 '15 at 17:03
  • [The Great Escapism (Or: What You Need To Know To Work With Text Within Text)](http://kunststube.net/escapism/) – deceze Mar 27 '15 at 17:15
  • Remember that JavaScript-based validation is just a convenience. Attackers post to your site without going through a browser. – Andy Lester Mar 27 '15 at 20:18

1 Answers1

2
  1. No. Banning characters prevents people from using them and there are often valid reasons to use them. If it makes no sense for the characters to appear in the data, then you can filter them to help keep the data sane. Don't do it as a security measure.
  2. Ditto
  3. No. Parametrised queries are better.
  4. Yes, but not in combination with mysqli_real_escape_string since you shouldn't mix APIs and if you used both you would double escape things and put \ characters in your data.
Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335