Sql Injection is possible if parameters are passed via GET. But is it possible via POST also. If yes, can https prevent it?
+16
A:
Yes, it's possible with $_POST as well as with $_GET, $_COOKIE and $_REQUEST. HTTPS will not protect you at all. You have to use some function to protect you, for example mysql_real_escape_string or use prepared statements.
All communication from the web browser should be handled as "untrusted". Other techniques you can't trust is Ajax, file uploads and JavaScript form validations (among others). All these data come directly from the web browser and should not be trusted before you have filtered them or validated the data.
The only thing you can trust is $_SESSION, provided that you ONLY put in validated data into your $_SESSIOn variables.
Emil Vikström
2010-01-18 15:45:20
*giggles* ... so PHP needed a *real* string escape function because the original one didn't suffice? And they didn't hesitate naming it exactly so? :-)
Joey
2010-01-18 15:58:55
@johannes: Not sure why the "real" part is in there, but mysql most likely requires certain characters to be escaped which may or may not be covered in other escape functions. So having a special mysql version of it makes perfect sense. Again, no idea what the "real" part does in the name though... probably someone having fun :p
Svish
2010-01-18 16:03:49
Actually the difference is that real escape string takes into account the char set of the current database connection while the original escape string doesn't even require a connection to use (less secure though)
Chris T
2010-01-18 16:05:21
There is a function mysql_escape_string, but it's been replaced by mysql_real_escape_string. They left the original in there for backwards compatibility.
Alex JL
2010-01-18 16:10:19
+7
A:
- Yes you can SQL inject via POST. Anyone can change what gets send in POST requests (look up an addon for firefox called "hackbar"
- No https will not help with it because it can do nothing against web application layer attacks. It only prevents man-in-the-middle attacks and sniffing.
Chris T
2010-01-18 15:45:39
You don't need fancy hacking tools - writing your own html page with vi/notepad may be enough.
symcbean
2010-01-18 16:27:53
Hackbar allows faking the referer and easily adding/manipulating cookies. I like showing it as an example because it illustrates that the client should never be trusted. +1 for simplicity though
Chris T
2010-01-18 16:40:45
sanitize all user input server side... you cant trust any client side code... and you can rewrite any header like user-agent or referrer so those shouldn't be written directly to db either...
Carter Cole
2010-01-26 18:15:12
+3
A:
You should escape all user-submitted data, no matter the method.
Martin Bean
2010-01-18 15:46:04
+2
A:
No, there isn't a difference between these two methods.
The SQL injection happens when you use user supplied input in SQL statements without sanitizing it. It doesn't matter if you received the data through GET or POST, or if it was encrypted. What matters is what you do with the input after you have it.
Alex JL
2010-01-18 15:46:30
If there is an absolute need to pass Sql Query via POST or GET, what can be the safest bet? If I encrypt the query and send then..?
RPK
2010-01-18 15:48:37
There is never a need to pass a raw query to a browser under the control of a user who isn't completely trusted (trusted to not try to break things **and** trusted to not break things accidently). If you think there is a need, you just haven't thought of a decent solution yet (which usually involves breaking down the data in the query into parts that are standard (which you keep server side) and parts which are user entered data (which you check when they get sent back to you to make sure they are safe).
David Dorward
2010-01-18 15:51:09
The safest way to deal with any user supplied info is to use the commain mysql_real_escape_string() on the input before putting it into your query (if you're using PHP, for instance). Using parameterized queries (prepared statements) is the best way to prevent SQL injection.
Alex JL
2010-01-18 16:08:24
+1
A:
Nothing can protect you except sanitising your inputs, and the only completely safe way to do that is to use prepared statements. This is of course hassle, but there really is no alternative - if you develop a website and it's hacked by SQL injection because you didn't use prepared statements you pretty much are negligent as a programmer for this.
The simplest way I've found in PHP of doing this to date is to use Codesense's mysqli wrapper. It's a neat, small, class that removes much of the hassle associated with raw prepared statements, has been more than solid enough where I've used it.
Using this prepared SQL only slightly more hassle than straight SQL, so there really is no excuse for not.
Cruachan
2010-01-18 15:58:46