By default does ASP.net protect against SQL injection attacks when using ASP controls?
问题:
回答1:
No. As long as you're supplying the SQL, it's up to you to be smart in how you use the controls.
That usually means sanitizing input and using Parameterized Queries or Stored Procedures over dynamic SQL strings.
If the control is generating the queries for you (like the Membership Controls, etc.) then you're well protected.
回答2:
Yes and no.
ADO.NET has very good support for parameterization, and when you use it properly, the parameter values will be automatically sanitized to prevent SQL injection. So you can add parameters to a SqlCommand
(or a SqlDataSource
control) without worrying too much about what's in them.
The good news is that parameterizing your stuff is really easy. I'll show you a C# example for doing it programmatically, but you can do it declaratively with server controls if you prefer.
The bad news is that just like anything else, you still need to think about what you're doing. Any string from an unsafe source must be parameterized if you want to have any security. If you paste it verbatim into the query, you'll have bypassed ADO.NET's security features.
Secure:
string name = txtName.Text;
sqlCommand.CommandText = "select * from product where name = @name";
sqlCommand.Parameters.AddWithValue("name", name);
Not secure:
string name = txtName.Text;
sqlCommand.CommandText = "select * from product where name = " + name;
If anything in your SQL query comes straight from the user, you need to put it in a parameter or all bets are off. And just like almost anything else, it's possible to shoot yourself in the foot if you really want to. For example, you could take SQL code, put it in a parameter, and pass it to a SQL EXEC
statement. But you wouldn't do that, would you, because it is a Very Bad Idea.
Still not secure (yes, I saw this in production code)!
string sql = "select * from product where name = " + txtName.Text;
sqlCommand.CommandText = "exec(@sql)";
sqlCommand.Parameters.AddWithValue("sql", sql);
TL;DR: ADO.NET has great features to stop SQL injection, but only if you to use them correctly.
回答3:
Most ASP.Net controls (except for DataGrid) do not use SQL at all.
If you have your own SQL in your code (using SqlCommand
s), you don't get any free protection; you need to use parameters.
The few controls that do use SQL (SqlDataSource and the membership framework) do use parameters and are safe against injection.
回答4:
ASP.NET does not protect against SQL injections!
ASP.NET is just the framework for web applications and it does not dictate in what way you access your database. It depends on how you implement your data access:
- If you are using ADO.NET, and are building your SQL queries as strings, then you have to sanitize any user-input to be safe from injections.
- If you are using ADO.NET and use SqlParameters, then I think you are safe against injections.
- If you are using an ORM tool for data access, then I'd say you are safe (at least when using the common ones)
- If you are using DataSets, then you are probably safe as well.
- If you are using some 3rd-party databound controls, then I hope they are taking care of protecting against SQL injections
Probably I forgot to mention a lot in my answer, but you can see that the answer is: "it depends"
回答5:
If you always use SqlParameter
s, and never concatenate user input into SQL, you should be safe. You can use SqlParameter
s without stored procedures too.
回答6:
No, ASP.Net does not protect against SQL Injections. The MS shipped code for the ASP.NEt controls is supposed to be SQL Injection free, but this does not prevent all problems one developer can corner himself into. The best defense is a good understanding of SQL Injection and careful coding. When this is unattainable, for whatever reasons, there are tools that can help like Microsoft Code Analysis Tool .NET (CAT.NET). This is a free VS plug-in that can analyze the generated assemblies and detect SQL Injection, XSS and XPath injection risks. Such a tool is not bulletproof, but is much better than nothing.
回答7:
Partially. There is a filter which is turned on by default which makes constructing an SQL injection attack difficult unless it's turned off.
The method which many ASPNET applications use to access MSSQL databases also makes them generally resistant to SQL injection attacks.
But it is still POSSIBLE to create a vulnerable application if you are careless enough.