SQL Injection advise
-
Hi all, My site got hit with SQL injection attack, and I'm now looking for ways to ensure that this won't happen again. Actually I thought I was pretty well covered against SQL injection attacks, but apparently I was wrong. One technique I've been using is when I pass ID's through querystring is to do something like this:
String strID = Request.QueryString["ID"];
if ( !String.IsNullOrEmpty( strID ) )
{
int nID = Convert.ToInt32( strID );
myDBWrapper.GetSomeData( nID );
}// where GetSomedata would be implemented like this:
public MyDataCollection GetSomeData( int nID )
{
String strSQL = String.Format( "SELECT * FROM MyData WHERE ID = {0}", nID );
// etc... fetching data using SQL Reader etc....
}Would you consider this code to be vulnerable? I'm aware of SQL parameters, and I use them in other circumstances, such as when inserting into tables. But I've always believed that it wasn't necessary in these situations, because the conversion to Int32 would fail if the Query String parameter did contain some malicious SQL statments. Any comments? Regards, Daníel
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
-
Hi all, My site got hit with SQL injection attack, and I'm now looking for ways to ensure that this won't happen again. Actually I thought I was pretty well covered against SQL injection attacks, but apparently I was wrong. One technique I've been using is when I pass ID's through querystring is to do something like this:
String strID = Request.QueryString["ID"];
if ( !String.IsNullOrEmpty( strID ) )
{
int nID = Convert.ToInt32( strID );
myDBWrapper.GetSomeData( nID );
}// where GetSomedata would be implemented like this:
public MyDataCollection GetSomeData( int nID )
{
String strSQL = String.Format( "SELECT * FROM MyData WHERE ID = {0}", nID );
// etc... fetching data using SQL Reader etc....
}Would you consider this code to be vulnerable? I'm aware of SQL parameters, and I use them in other circumstances, such as when inserting into tables. But I've always believed that it wasn't necessary in these situations, because the conversion to Int32 would fail if the Query String parameter did contain some malicious SQL statments. Any comments? Regards, Daníel
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
This is my take on an injection attack If you have a textbox which a user can enter data into and that textbox value is then used in a query which is written into your c# code (i.e. not a stored procedure) then you are at risk of attack unless you can filter their input. To answer your question I'm not sure if the above code would be vunerable but my using the above methodology you might be able to work it out yourself hope this helps
We are not a Code Charity
-
This is my take on an injection attack If you have a textbox which a user can enter data into and that textbox value is then used in a query which is written into your c# code (i.e. not a stored procedure) then you are at risk of attack unless you can filter their input. To answer your question I'm not sure if the above code would be vunerable but my using the above methodology you might be able to work it out yourself hope this helps
We are not a Code Charity
-
Yes, I'm using command parameters for all values which the user can enter.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
...but bear in mind that input fields on web forms are not the only method a hacker has of passing data to your application - they can also use the QueryString and even cookie values, so if you utilise any of these you msu also validate them. Basically, validate ANYTHING that gets passed to the database. Life is much easier if you don't allow HTML to be posted, but unfortunately a lot of clients want it nowadays... but, for example, no-one should ever be allowed to pass "<script" back...
-
...but bear in mind that input fields on web forms are not the only method a hacker has of passing data to your application - they can also use the QueryString and even cookie values, so if you utilise any of these you msu also validate them. Basically, validate ANYTHING that gets passed to the database. Life is much easier if you don't allow HTML to be posted, but unfortunately a lot of clients want it nowadays... but, for example, no-one should ever be allowed to pass "<script" back...
Agreed. I'm aware of this. What I wanted most was some advise on the initial code, i.e. if the approach described is vulnerable in some way. Any ideas? Regards, Daníel
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
-
Agreed. I'm aware of this. What I wanted most was some advise on the initial code, i.e. if the approach described is vulnerable in some way. Any ideas? Regards, Daníel
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
Well I hope it is, as it's essentially what I do as well in such a case... basically, you have ensured that nothing but an integer can get passed to your query, so you should be safe...