SQL Injection prevention: Maximum measures [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I wanted to know if there is any other measures against SQL injection that can be taken apart from using parametrized Q开发者_Python百科uery and validating data. Thanks!

---

Obviously ensure you are validating data on the server-side in addition to anything you may be doing on the client.

Also, if you're talking web make sure you are validating all data, i.e. QueryString's and Cookie Value's as well as Form fields.

I know this is the first hit on Google but I do read this article over from time to time and really rate it (again relates to web): http://www.securiteam.com/securityreviews/5DP0N1P76E.html

---

I always run my user input text through a custom sanitiser server side, so I can strip out all the nasty stuff in case it gets through. (& " = ' etc)

I don't have any SQL statements in my code except for the stored procedures I call, so even if they do find a vulnerability they'll have to figure out my stored procedure before even touching the tables.

In the stored procedure parameters you can limit the text sizes, for example VARCHAR(10) so if you're normally expecting string "123456" and "12345' AND UNION SELECT * FROM MEMBERS INNER JOIN MEMBER_ADDRESS ON ID" comes through, the stored procedure won't like it.

Also one last point, try to catch all exceptions that come back, and try to handle them gracefully. Sometimes you see websites display something like "could not connect to database, 'USER_ID' does not exist in mydatabase.member". Giving someone a sniff at the architecture of your database will start the ball rolling for an exploit.

---

With All good answers above, What I did is create a script that scans all tables and creates whitelist for table names and columns then I use that to validate any user input that is supposed to be table/column name since they don't go into parametric query. Anything else is parameterized via PDO Bind!