1

XSS and SQL injections are the two main security risks with unsanitized user input.

XSS can be prevented (when there is no WYSIWYG) by using htmlspecialchars() and SQL injection can be prevented by using parameterised queries and bound variables.

By using these two methods, is it secure to use all unsanitized input?

SCC
  • 509
  • 7
  • 13
  • @MarcusAdams That’s not a problem of improper data handling but of improper request authentication. – Gumbo Feb 14 '14 at 17:29
  • There's also path traversal, wherein you fail to properly filter & validate file and path names, resulting in reads or writes to the wrong places in your filesystem. – Michael Berkowski Feb 14 '14 at 18:05
  • @MichaelBerkowski I never use user supplied datas for File/Directory names. – – SCC Feb 15 '14 at 08:26

4 Answers4

4

You always have to consider the context the data is used in. Because the mentioned functions and techniques do only work if they are used according to the purpose of their use. This applies not just to HTML and SQL but to any other language/context.

Regarding XSS, since htmlspecialchars escapes the HTML special characters <, >, &, ", and ' by HTML character references, it will protect you only if you put the data into a context in HTML where <, >, &, ", or ' are the context delimiters but won’t help you if other delimiters apply (e. g., an unquoted HTML attribute value, or you’ve already entered another context within HTML (e. g., an HTML attribute value that is considered as JavaScript code like the on… event attributes; or within HTML elements which are a different language, e. g., <script>, or <style>, where other/additional rules apply). Not to mention so called DOM-based XSS, where the input is not processed by the server but by client-side JavaScript. So there are situations in which htmlspecialchars won’t help you.

However, regarding emulated or real prepared statements, you should be on the safe side as the database connection layer or the DBMS will take care of proper data handling. Unless, of course, you’re still building the statement to be prepared by using improperly processed data.

Community
  • 1
  • 1
Gumbo
  • 643,351
  • 109
  • 780
  • 844
2

Just some possible issues beside XSS and SQL-injection:

It always depends where you pass the userinput and how you sanitize it. For instance always use PDO for SQL Operations, because even with proper escaping an attacker can inject SQL code without quotes at all:

SELECT title, content FROM cms WHERE id = 1

An attacker can change this to:

SELECT title, content FROM cms WHERE id = -1 UNION SELECT username AS title, password AS content from users LIMIT 1

In this case only intval() could help, and escaping (mysql_real_escape_string, magic_quotes, addslashes, etc...) won't help at all.

Also take a look here please: Exploitable PHP functions

Community
  • 1
  • 1
thebod
  • 462
  • 2
  • 4
  • +1 good list and good examples. And thanks for linking to that thread on exploitable PHP functions, it's a good one. – Bill Karwin Feb 15 '14 at 18:59
  • @thebod _In this case only intval() could help_ , Then what about MYSQLI prepared staement in that case? – SCC Feb 18 '14 at 10:41
  • Well, I meant `intval()` in case you don't use PDO. PDO should always be the way to go because it prevents you from malicious injected parameters. – thebod Feb 19 '14 at 09:32
2

SQL injection is just one case of the broader threat of code injection. That is, any case where user input (or any other untrusted content) is run as code.

This includes things like eval() but quite a few other vectors as well. The answer from @thebod includes a link to a great StackOverflow thread: Exploitable PHP functions.

Even SQL injection can't be solved 100% by parameters or escaping. Both of those techniques only help to sanitize individual values in SQL expressions. You might also need to allow user input to select tables, columns, SQL keywords, or whole expressions. For those, parameters and escaping don't help. Example:

$sql = "SELECT * FROM mytable ORDER BY $sortcolumn $asc_or_desc";

In that example, the column name to sort by and the direction (ASC vs. DESC) are based on variables. Were the variables set from trusted input, or were $_GET parameters used verbatim, resulting in a SQL injection vulnerability?

A better solution for those cases is allowlisting. That is, take the user input, compare it to a list of column names that are permitted for this dynamic query, and if the user input doesn't match one of those predefined choices, then either fail, or else use a default value.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
0

By using those methods, your user input is already sanitized for the most part. If you want to take it a step further you can do validation checks on the input before running the SQL code. An example would be, checking numbers are numeric only, checking the length of user input etc.

d.abyss
  • 204
  • 1
  • 4
  • 26
  • Input's length and data types have any security risk? – SCC Feb 14 '14 at 10:47
  • Sorry for delay, at work! Those were just examples but here is more specific example. Say you have a field on your site which lets a user search for something using a postcode, if you validate the postcode so that the input will only be accepted if the postcode follows the structure of a postcode and the length of a postcode e.g. LNN NLL (L=Letter, N=Number) this will make it much more secure against people trying to enter malicious code, as this box will not allow you to run any input that doesn't follow this structure or exceeds this length. – d.abyss Feb 14 '14 at 11:38