Is SQL Injection possible with POST?

问题:

Sql Injection is possible if parameters are passed via GET. But is it possible via POST also. If yes, can https prevent it?

回答1:

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.

回答2:

1. Yes you can SQL inject via POST. Anyone can change what gets send in POST requests (look up an addon for firefox called "hackbar"
2. 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.

回答3:

You should escape all user-submitted data, no matter the method.

回答4:

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.

回答5:

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.

回答6:

https cannot protect you here. Filter you input(s)