SQL Injection
-
Hi, We have an ASP.NET 1.1 application with SQL Server 2005. Database access layer of the application is written separately and provided to us as a dll to be used in application and we dont want to change it. DAL does not support parameterized queries. What we have done is that on every where clause we have replaced ' by ''. I know it is not very good approach but what i want to know is our application safe now, or SQL injection is still possible and if it is unsafe can anyone provide the example of how?
Regards Shajeel
-
Hi, We have an ASP.NET 1.1 application with SQL Server 2005. Database access layer of the application is written separately and provided to us as a dll to be used in application and we dont want to change it. DAL does not support parameterized queries. What we have done is that on every where clause we have replaced ' by ''. I know it is not very good approach but what i want to know is our application safe now, or SQL injection is still possible and if it is unsafe can anyone provide the example of how?
Regards Shajeel
There are many ways you can have SQL Injection problems. Code Project has several articles on this subject and all are great. This is a subject that will require some reading. If you are handling sensitive data, then read up and make sure you understand what you are reading. To answer your question, no that does not solve SQL Injection attacks.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
-
There are many ways you can have SQL Injection problems. Code Project has several articles on this subject and all are great. This is a subject that will require some reading. If you are handling sensitive data, then read up and make sure you understand what you are reading. To answer your question, no that does not solve SQL Injection attacks.
The best way to accelerate a Macintosh is at 9.8m/sec² - Marcus Dolengo
Expert Coming wrote:
To answer your question, no that does not solve SQL Injection attacks.
can you give me the example or article as i am pretty sure i looked at lots of articles and did not find any example that it does not solve my problem.
Regards Shajeel
-
Hi, We have an ASP.NET 1.1 application with SQL Server 2005. Database access layer of the application is written separately and provided to us as a dll to be used in application and we dont want to change it. DAL does not support parameterized queries. What we have done is that on every where clause we have replaced ' by ''. I know it is not very good approach but what i want to know is our application safe now, or SQL injection is still possible and if it is unsafe can anyone provide the example of how?
Regards Shajeel
Shajeel wrote:
but what i want to know is our application safe now,
Not at all. It's will not be safe by replacing ' with ''. There are many other ways a person can inject harmful SQL statements. Look at this[^] which explains these.
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia My Website | Ask smart questions
-
Shajeel wrote:
but what i want to know is our application safe now,
Not at all. It's will not be safe by replacing ' with ''. There are many other ways a person can inject harmful SQL statements. Look at this[^] which explains these.
All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia My Website | Ask smart questions
Thanks for reply. all examples in the article starts with ' which we have dealt with, there are some places where int is used that are not covered here but we are always validating int wherever user enters them in form, so they are covered also. So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Regards Shajeel
-
Thanks for reply. all examples in the article starts with ' which we have dealt with, there are some places where int is used that are not covered here but we are always validating int wherever user enters them in form, so they are covered also. So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Regards Shajeel
Are you also validating against cross site scripting? This can also lead to a Sql Injection. How? Well, imagine that you perform clientside validation to ensure that values fall into a certain range. Now imagine that somebody else creates a form that targets your system and doesn't have this validation, then your system can be targeted because the validation has been bypassed. You have to think of security as a whole and minimize the attack surface. One way to do this is to use parameterized queries, rather than relying on your code converting ' into ''. Remember, it just takes this being missed out in 1 place for the whole thing to come crashing down to its knees.
Deja View - the feeling that you've seen this post before.
-
Thanks for reply. all examples in the article starts with ' which we have dealt with, there are some places where int is used that are not covered here but we are always validating int wherever user enters them in form, so they are covered also. So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Regards Shajeel
Shajeel wrote:
So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Always take a multifaceted approach. Just because you can't find a way, doesn't mean that some clever hacker can't find a way. Do NOT be complacent about this. It is arrogant to think that just you put up protection in one area you are safe. The house my parents live in was very well secured. A burgler attempted to get in the back door, the back windows and eventually got in through the tiny skylight in the roof. Think of your SQL Server the same way. If you secure the main ways in and attacker will find the way you didn't think of.
Upcoming FREE developer events: * Glasgow: SQL Server Managed Objects AND Reporting Services ... My website
-
Shajeel wrote:
So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Always take a multifaceted approach. Just because you can't find a way, doesn't mean that some clever hacker can't find a way. Do NOT be complacent about this. It is arrogant to think that just you put up protection in one area you are safe. The house my parents live in was very well secured. A burgler attempted to get in the back door, the back windows and eventually got in through the tiny skylight in the roof. Think of your SQL Server the same way. If you secure the main ways in and attacker will find the way you didn't think of.
Upcoming FREE developer events: * Glasgow: SQL Server Managed Objects AND Reporting Services ... My website
Colin Angus Mackay wrote:
The house my parents live in was very well secured. A burgler attempted to get in the back door, the back windows and eventually got in through the tiny skylight in the roof. Think of your SQL Server the same way. If you secure the main ways in and attacker will find the way you didn't think of.
Absolutely true. I voted it with '5' vote. :)
Vasudevan Deepak Kumar Personal Homepage
Tech Gossips
Yesterday is a canceled check. Tomorrow is a promissory note. Today is the ready cash. USE IT. -
Thanks for reply. all examples in the article starts with ' which we have dealt with, there are some places where int is used that are not covered here but we are always validating int wherever user enters them in form, so they are covered also. So after going through article i assume my app is safe or is there other ways of SQL Injection which are not included in article.
Regards Shajeel
Shajeel wrote:
all examples in the article starts with '
No, one of the examples began with a number, not a quote: string sql = "SELECT * FROM Orders WHERE DATEPART(YEAR, OrderDate) = "+ this.orderYearTb.Text); and the attacker began his string with a zero. Does seem to me that all the examples I've seen had statement delimiters embedded within them. Therefore, I have two functions I run against the input. The first effectively converts ' to '', but also checks for a maximum length of the argument. If I know the maximum length of the field my user wants to compare against, a string longer than this is rejected outright as a possible attack. The next function removes any unquoted semicolons. This will cause attacking SQL to be ill-formed and rejected for syntax. But DON'T respond to the user with the ill-formed string. They may be able to see thru the protection scheme. While this two-prong approach defeates every injection example I have ever seen, it does not guarantee, as Colin suggested, that someone clever won't come up with a way to defeat it. Plus, as Pete inferred, the SQL validation (in my case, converting ' to '' and removing unquoted semicolons) must be done immediately before submitting the SQL string to the db for processing. You must not rely on external validation.
David --------- Empirical studies indicate that 20% of the people drink 80% of the beer. With C++ developers, the rule is that 80% of the developers understand at most 20% of the language. It is not the same 20% for different people, so don't count on them to understand each other's code. http://yosefk.com/c++fqa/picture.html#fqa-6.6 ---------