Will these security functions be enough?

I am trying to secure my site so I'm not vulnerable to sql injection or xss.

Here's my code:

//here's the form (abbreviated)
<form>
<label for="first_name" class="styled">First Name:</label>
<input type="text" id="first_name" name="first_name" value="<?php if (!empty($first_name)) echo $first_name; ?>" /><br />

//submit button etc
</form>


if (isset($_POST['submit'])) {

 //gets rid of extra whitesapce and escapes
 $first_name = mysqli_real_escape_string($dbc, trim($_POST['first_name']));

 //check if $first_name is a string
 if(!is_string($first_name)
 { 
 echo "not string"; 
 }

 //then insert into the database. 
 .......

}

mysqli_real_escape_string: I know that this function escapes certain letters like \n \r, so when the data gets inputted into the dbc, would it have '\' next to all the escaped letters?

• Will this script be enough to prevent most sql injection? just escaping and checking if the data is a string. For integers values(like users putting in prices), i just: is_numeric().

• How should I use htmlspecialchars? Should I use it only when echoing and displaying user data? Or should I also use this when inserting data to a database?

• When should I use strip_tags or htmlspecialchars?

So w开发者_StackOverflowith all these functions:

if (isset($_POST['submit'])) {

 //gets rid of extra whitesapce and escapes
 $first_name = mysqli_real_escape_string($dbc, trim($_POST['first_name']));

 //check if $first_name is a string
 if(!is_string($first_name)
 { 
 echo "not string"; 
 }

 //gets rid of any <,>,&
 htmlspecialchars($first_name);

 //strips any tags with the first name
 strip_tags($first_name)

 //then insert into the database. 
 .......

}

Which functions should I use for sql injection and which ones should I use for xss?

When can a user insert xss scripts against me? When there is a form?

---

Checking if data is a string is useless: strings are exactly what you'd use for injections.

real_escape_string is a reasonable, but not guaranteed way of avoiding SQL injections, because escaping routines have a risk of being buggy and not escaping things correctly (in fact, there have been bugs previously). The right way to do it is to used parameterized queries - this separates the data from the structure of the query, making injection impossible. If you absolutely cannot use parameterized queries, however, real_escape_string (with a set_charset when the connection is opened) is the best you can do.

You will want to use htmlspecialchars on anything the user can touch, and you want to use it at the moment it is shown on a page. If you want users to format posts or anything, then you should provide them with a formatting language a la BBCode (and convert the BBCode after running htmlspecialchars). If you need to store pure HTML, you wouldn't want to use htmlspecialchars, but you'd want to make damn sure that only trusted people can write there. For example, if you're writing a blog, it might be okay to allow pure HTML in the blog post itself, because only the blog editors can write stuff there. However, you wouldn't want to allow it in the comments, because everyone can write stuff there, and that would just make it too easy to do stuff like cross-site scripting.

---

For SQL injection, mysql_real_escape_string should work. (To be totally sure, you can use prepared statements)

For XSS, htmlspecialchars should work. strip_tags might not be as safe, as someone could cleverly disguse their javascript.

---

Whenever you are embedding user-supplied information in HTML, you should use htmlspecialchars. Whenever you are embedding user-supplied information in SQL, you should use mysql_real_escape_string. Follow these rules and you should be OK.

Note, however, that a better solution for database security would be to use prepared/parametrized queries (see here and here), as these will handle the escaping for you, eliminating the possibility of your forgetting.

Also, don't forget to check for magic quotes.

---

If you are printing HTML you should clean it with HTML Purifier first. Think of it as an advanced (and customizable) version of strip_tags().

For insertion into database, I use prepared statements. It's foolproof.