2

So I've been wondering for some time, after being advised in a previous question to use PDO prepared statements, why its important when connecting to my Database to use them in an instance like so?

eg using $_SERVER['REMOTE_ADDR']

I mean, if no one knows I'm using a database, and they have no idea what I'm looking for, and the thing I'm looking for in the database (assuming they know) is an IP address, why should it matter? Is this a matter of XSS attacks?

Genuine question. Never been able to find any reason to use PDO statements (or similar methods) in this instance. Surely I'm not vunerable?

Community
  • 1
  • 1
Ricki
  • 933
  • 2
  • 15
  • 33
  • 3
    It's not about XSS, it's about SQL injection. You don't need to know whether or not an app uses a database (most do) to try a SQL injection attack; if it works, it does. And it doesn't matter what you're looking for either. – Robert Harvey Jan 17 '13 at 16:03
  • possible duplicate of [How to prevent SQL injection in PHP?](http://stackoverflow.com/questions/60174/how-to-prevent-sql-injection-in-php) – Tchoupi Jan 17 '13 at 16:04
  • 1
    @RobertHarvey You are right. But how could someone inject some random SQL code when in his select he is using the value of `$_SERVER['REMOTE_ADDR']`? – cheesemacfly Jan 17 '13 at 16:04
  • How? can an IP be faked? – Ricki Jan 17 '13 at 16:04
  • 2
    @cheesemacfly: By putting a semicolon at the end of some input. If there's no user input at all, there's no possibility of injection. But why take the chance when the best practice is to use PDO prepared statements? – Robert Harvey Jan 17 '13 at 16:05
  • @RobertHarvey I know and you are right. But I believe the question is specific about using the value of `$_SERVER['REMOTE_ADDR']` in a request? – cheesemacfly Jan 17 '13 at 16:07
  • 1
    Eh, if you use prepared statements, you never have to have this discussion. – Robert Harvey Jan 17 '13 at 16:08
  • @RobertHarvey Your Comment is an answer 'if there is no user input at all, there's no possibility of injection' that was my main purpose as well as to understand the possibility of the vulnerabilities using `$SERVER[]` values – Ricki Jan 17 '13 at 16:15
  • I'm not going to write that as an answer. Suppose another programmer comes along and adds a field to your query that's tied to user input. What do you do then? – Robert Harvey Jan 17 '13 at 16:16
  • I do not distrube code nor display any to any other person i know. To see and modify my code, i would need to be the victim of my server being hacked.. – Ricki Jan 17 '13 at 16:18

5 Answers5

6

So you're not sanitising your input at all?? Really?

What happens when you have a user named "Bob O'Reilly"? Will your code cope with that? Have you tried it?

Or what happens if someone enters a letter into a numeric field. Will your code cope with that?

SQL data sanitation is about more than just protecting against hacks; it's allows for everyday data to be entered without worrying about whether it contains quote marks or other characters that would break the query.

Protecting against hacks is a very good thing, but even if that wasn't a consideration, you would still need to sanitise your DB input.

...if no one knows I'm using a database...

Hackers don't "know", they guess; they try out a few common hacking techniques to see what happens. If the site responds in the way they hope for then they know that its vulnerable. That's when they really start attacking you.

Those investigation hacks are typically automated and just trawl the web looking for sites to attack; you'll be vulnerable simply by being online. Don't think you're safe just because you're obscure, or because no-one knows your code, or because no-one would want to hack you. They will find you and they will hack you.

SDC
  • 14,192
  • 2
  • 35
  • 48
  • Very helpful, Thanks. Maybe my carelessness needs addressing. I never mentioned grabbing any other info than an IP address, however its still very helpful – Ricki Jan 17 '13 at 16:21
  • I was truly moved by the closing statement :) +1 – Matanya Jan 17 '13 at 16:22
2

As you take a value from a GET or POST request or either from a Cookie and use that value to build up a string that will be you query, the data received could have been properly set up by a malicious user to transform your original query into a different one (with different SQL statemens) and get control over your data.

I'll not explain here as a whole, Google for SQL injection.

As you use "prepared statementes" it is virtually impossible to use the passed data to alter the query statemens.

EDIT

eg using $_SERVER['REMOTE_ADDR']

If the only value is that one you're quite safe. But, who knows...

Maybe a bug in PHP that will be discovered in the future will allow the client to alter that value in way to twaek your query...

In doubt stick with the prepared statements pattern. What does this cost to you?

Paolo
  • 15,233
  • 27
  • 70
  • 91
1

Using prepared statements even when it may not strictly be necessary keeps you in the mindset of producing secure code by default and avoids situations where you think the input is safe but it isn't actually (for example, $_SERVER['HTTP_HOST'] seems safe, but it's not necessarily). Yes, the specific variable $_SERVER['REMOTE_ADDR'] should be safe, but nothing is lost by being extra careful.

ceejayoz
  • 176,543
  • 40
  • 303
  • 368
0

Used you php vars in your sql statement? for where / order / limit clause? If yes, you use PDO statement with escape vars.

If, in the future, you migrate to SQLServer, SQLite, ... you have justvto change Driver connector (1 code line) with PDO. With mysql/mysqli, you have to change all of your php code.

throrin19
  • 17,796
  • 4
  • 32
  • 52
0

PDO helps to stop the execution of arbitrary SQL (SQL Injection) provided by the attacker.

If an attacker can execute any SQL they like on your server then they can retrieve / edit data from the database and additionally in some DBMS they will be able to access / create files possibly in your webroot depending on security measures taken.

Ingmar Boddington
  • 3,440
  • 19
  • 38