SQL injection vulnerability

Question

How can I avoid SQL injection attacks in my ASP.NET application?

I have a master page and child pages for my project.

Thanks

Answer 1

You should avoid construction queries with values; instead, use SQL Parameterization or Stored Procedure with parameterization. It also helps to create optimized query plans for better performance.

Here is some samples: https://www.c-sharpcorner.com/article/best-practices-to-prevent-sql-injection/

Answer 2

Hi @Sana, Ramesh,

You can pay attention to the following points:

1. Do not rely on client-side input validation
2. Use a database user with restricted privileges
3. Use prepared statements and query parameterization
4. Scan your code for SQL injection vulnerabilities
5. Use an ORM layer
6. Don’t rely on blocklisting
7. Perform input validation
8. Be careful with stored procedures

Best regards,
Lan Huang

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

You have some great answers.

At the most base level?

Well, you can in code risk so called "in line" SQL statements. However, in "any" case in which ANY of that SQL used involves ANY kind of user input?

Then no chances are to be taken in such cases, and you can't use "string" concatenations in code for your SQL. Follow the above simple rule, and you covered 99% of SQL injection cases.

So, for example, say we have a simple gridview, and the user is to click on a button. (to select the row, maybe view that one record).

Can you risk SQL concatenation in that case? Well, yes, you actually can, providing you use 100% server side code for that row click, and don't pull or use any user input for the database ID value you use in this example.

So, don't ever take user input, and use with SQL statements as concatenated "strings" code.

Else you risk this: