ukphp;10997384 wrote:I'm fairly new to PHP and MySQL and gather there is quite a bit of security risks around having fields which users are able to input data which gets written to a database
You've actually lumped a couple of different types of security risks into a single pile.
For example, there is one set of security risks introduced simply because you're incorporating user-supplied data somewhere inside of a SQL query. You should sanitize/validate this data to ensure that it actually matches what you expected to get as well as making it safe to use in the SQL query. For example, if you're expecting a U.S. telephone number, you might want to ensure that the string matches a certain pattern, such as the following regular expression pattern:
/\(?[0-9]{3}\)?[. -]?[0-9]{3}[. -][0-9]{4}/
(which would match all sorts of patterns like "(555) 555-5555", "5555555555", "555.555.5555", etc.).
In regards to the "making it safe to use" part, take the surname O'Fallon for example; it's a perfectly legitimate last name, and there was probably no malicious intent behind the user who entered that data. However, that's not to say that it's safe to use in a SQL query... example:
SELECT * FROM users WHERE last_name = 'O'Fallon'
(note the syntax error caused by the usage of unsafe user-supplied data).
On the flip side, there are HTML/XSS/etc. issues to worry about that have nothing to do with SQL security at all. For example, if you had a comment box and someone typed in this:
Hi there! <script type="text/javascript">window.location = 'http://malicious-website.example.com'; </script>
then none of the above sanitization addresses the concern that you're using user-supplied data stored in the DB and dumping it into an HTML document. This is where things like [man]htmlentities/man come into play to prevent unwanted HTML data to actually become a part of your HTML document.
ukphp;10997384 wrote:Just wanting to check the security of it is ok.
What type of security? π
ukphp;10997384 wrote: In terms of the field validation (e.g. name should only be a-z or A-Z)
What about names like O'Fallon? Or Smith-Jones? Or RaΓΊl? Or 井深 大?
ukphp;10997384 wrote:
function sanitise_input($data)
{
$data = trim($data);
$data = stripslashes($data);
$data = htmlspecialchars($data);
$data = mysql_real_escape_string($data);
return $data;
}
This function is bad for one reason: it's trying to do more than what it's supposed to (and/or doesn't have a clearly defined purpose). It's sanitizing user input, sure.. but for what purpose? Remember, there are different types of security risks and thus different methods to mitigate each one; trying to lump them all into a single "sanitize" function just isn't going to work.
For example, I've got issues with every line of that function other than the return statement:
$data = trim($data);
Why would any and all data never be allowed to contain leading whitespace characters? For example, if I was storing my e-mail signature in a database, I would first enter several line breaks so that the signature appears several lines below the body of the e-mail. Your "sanitize" function, however, would strip off those spaces and I'd be unable to do anything about it.
Furthermore, what's "unsanitary" about data that contains leading whitespace? After all, that's supposedly the role/purpose of this function - to make data sanitary for use... somewhere?
$data = stripslashes($data);
This is just plain wrong for reasons Derokorian already mentioned above.
$data = htmlspecialchars($data);
Wait a minute - now we're sanitizing data for the purpose of using it inside of an HTML document?
Furthermore, what if you actually do want to allow a limited subset of HTML to be submitted in a given form field?
$data = mysql_real_escape_string($data);
... and now we're sanitizing data for a completely different purpose, suggesting that this function truly has no clearly defined purpose/role. Plus, now we've got a rather hidden dependency on this function and a resource to a MySQL server created by mysql_connect() (and not any other extension, such as the [man]MySQLi[/man] extension you should be using anyway).
Further more, you're now assuming that all data this function is going to be used for will only be string data (and not numerical, boolean, etc.).
Finally, note that as mentioned above, the entire [man]mysql[/man] extension is outdated and has been superseded by the [man]MySQLi[/man] extension; new projects are advised to use this extension (or others, such as [man]PDO[/man]) instead.