0

Obviously SQL Injection via the payload of a message is a very common practice and therefore it is always key to cover this (I already have in my code). However I'm just wondering about how possible it is for SQL Injection via the URL and whether this is possible as an actual method for SQL Injection.

I'll give an example URL to detail my question better. If I have a URL such as this with the SQL statement to be used for Injection included inside a parameter as its value (please note that the 'SELECT' could be any SQL query):

https://testurl.com:1234/webservicename?parameter=SELECT

I would like to know if this is valid way and would this actually work for hackers in terms of trying to inject into the back-end of the desired web service and also if so, what is the best way to go about covering for this?

closed as unclear what you're asking by SilverlightFox, schroeder, Stephane, Eric G, Lucas Kauffman Apr 1 '15 at 13:34

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

1

SQL injections have nothing to do with whether or not your application accepts URL parameters. They work with any input, be it the URL, the request body, a cookie, an HTTP header or even data from your own application (e. g. a string stored in your database). It doesn't matter.

So it's not about the origin of the input. It's what you do with the input. If you take dynamic data and simply insert it into an SQL query, that's a potential vulnerability. And, yes, this happens very often.

SQL injections cannot be prevented by checking the input. They must be prevented at database-level, for example by using prepared statements.

0

Any input to the user, whose content may be used in a database query is a possible vector of SQL injection. For example, with your example URL, depending on your server implementation this might work:

https://testurl.com:1234/webservicename?parameter=DROP TABLE users;SELECT

The key to preventing SQL injection is simple and we'll understood, always use parameterized query, and never concatenate SQL statement with user inputs with anything derived from user query. Don't even try escaping the inputs, it won't work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.