4

I have a feedback form which will take a couple of user inputted fields along with a few fields generated by PHP functions like 'user-agent' and 'referer.'

My question is should these strings be sanitized before being inputted? I realize one could easily alter the user-agent and the referring page, but could it be possible for a visitor to add a SQL injection like string so when PHP pulls this info it potentially breaks my form?

For instance if a user changed their user-agent or referring page to include the string Robert'); DROP TABLE Students;--

ashleedawg
  • 20,365
  • 9
  • 72
  • 105
Eric
  • 565
  • 1
  • 8
  • 25
  • mysql_query() doesn't support query stacking, an attacker would never be able to execute the drop statement. SQL Injection is still a very serious problem, but that exploit would never work. – rook Jan 30 '12 at 17:54
  • Ah yes... that Little Bobby Tables can be such an annoying little brat. (+1 for the xkcd reference....easily my favourite [comic](https://imgs.xkcd.com/comics/exploits_of_a_mom.png) *ever!* I even printed it and stuck it to my fridge... even though most people don't get it) – ashleedawg Feb 13 '22 at 19:25
  • That might depend on how your sanitization looks like. But why not store the data as it was sent in the request? It could be important to have **exactly that** data at hand, for example when you want to filter for it, and not any value your application changed – Nico Haase Feb 17 '22 at 14:28

4 Answers4

10

The word "sanitize" is pretty ambiguous and and better to be avoided.

Speaking of a database interaction, there is no need to "sanitize" at all. Just use prepared statements.

What is even more important, the data source doesn't matter. It should never be a question, "should we properly handle the data from such and such source?". It's just illogical, if you think of it. Why making such a distinction? Why rely on such a vague judgement? Why not to have an established process that uniformly treats any data despite the source?

Not to mention it's just super simple to use prepared statements:

$stmt = $db->prepare("INSERT INTO log (user_agent, referrer) VALUES (?,?)");
$stmt->execute([$_SERVER['HTTP_USER_AGENT'],$_SERVER['HTTP_REFERER']]);

And it will not only make the code simpler yet secure, but also make it proof against human errors of all sorts.

Your Common Sense
  • 156,878
  • 40
  • 214
  • 345
5

Simple Answer: validate/sanitize/escape everything (like client-side data, for example) because everything could be modified and evil or contain unexpected characters that could break your query (like Col. Shrapnel explained).

to minimize risk you should also about using prepared statements instead of building SQL-strings on your own (Note: this doesn't mean you can leave out the checks).

ashleedawg
  • 20,365
  • 9
  • 72
  • 105
oezi
  • 51,017
  • 10
  • 98
  • 115
  • what about something that comes from server-side? – Your Common Sense Jan 30 '12 at 15:53
  • @Col. Shrapnel: thanks for the hint, i should've clearified you can't trust _any_ outer data. i rephrased that sentence to take that into account. – oezi Jan 30 '12 at 16:07
  • Erm, I don't even trust _local_ data when building queries. Who is to say there isn't an apostrophe in there? Might be perfectly valid. Col. Shrapnel's answer ("if you put it in a query it needs to be escaped, period") is far more valid.... – Wrikken Jan 30 '12 at 16:13
1

First off all - I believe the best practice is to parametr-ise everything in the query including self generated values. For me it does not make the query (almost) bulletproof but it creates much nicer and readable queries. When you use parameters and assign them later you use more explicit logic in your code and therefore it will function better in the long term.

Longer explanation can be found in the attached link:

How can I prevent SQL injection in PHP?

Community
  • 1
  • 1
SimSimY
  • 3,616
  • 2
  • 30
  • 35
-1

Always sanitize/filter any input from a browser.

Just assume all users are evil, and you should be fine.

A connection doesn't have to come from a browser - anyone can write their own HTTP requests with a telnet client. There are probably specialized tools for this as well, and they wouldn't be hard to create.

ThatOtherPerson
  • 834
  • 6
  • 18
  • any input, period. browsers aren't the only source of potentially malicious data. Even the database can inject itself if you're round-tripping data. – Marc B Jan 30 '12 at 16:12
  • Can you share more details about this? "Always sanitize" sounds like something that should be backed by a credible source, especially as there are better ways to avoid getting hacked than sanitization or filtering – Nico Haase Feb 17 '22 at 14:27