3

A security review was done against one of our ASP.net applications and returned in the test results was a SQL Injection Exposures considered to be a high risk item.

The test that was performed passed a SQL statement as the value of the __EVENTTARGET and the __EVENTARGUMENT. I am wondering since these 2 values are ASP.net auto-generated hidden fields used for the Auto-Postback feature of the framework and hold information specific to the controls initiating the postback, is there really the potential for SQL injection if you are never manually calling and or pulling values out of these parameters in your code behind?

Schleichermann
  • 1,126
  • 3
  • 15
  • 26
  • Have you tried injecting sql? – rook Apr 05 '10 at 19:19
  • Yes all it does is blows up the page and an exception is returned since the injection has corrupted the auto post back values expected by the server. – Schleichermann Apr 05 '10 at 19:28
  • The reason I brought this to the community is to make sure I have not missed anything as we must submit a remediation plan to the 3rd party outlining each of the security exposures (how we plan to fix each one or why one may not be an issue in the first place). – Schleichermann Apr 05 '10 at 19:30
  • but does that exception come from the database? Or is it just the application server which is throwing that error? If its just the application failing, it can't be called SQL Injection. – Sripathi Krishnan Apr 05 '10 at 19:31
  • Agreed, the error is being returned by the Application server and not the SQL server. The 3rd party has issued it as a valid exposure because the error returned according to them insinuates the SQL made it back to the application server and should have been somehow filtered by some mechanism prior to hitting the application code. I don't see how this is possible in that the parameters they are injecting are auto-generated by the ASP.net framework. – Schleichermann Apr 05 '10 at 19:34

2 Answers2

2

You should always assume that dirty data can be passed from your form. Allowing it to be loaded from a postback, the __EVENTARGUMENT can be altered from the client side via javascript.

Always use good practices to make sure you don't allow sql-injection; and used parametrized SQL statements or another safe method.

http://msdn.microsoft.com/en-us/library/ms998271.aspx

Glennular
  • 17,827
  • 9
  • 58
  • 77
  • SQL is never executed from our code-behind files. We use an ORM as the data layer between the application and the database. – Schleichermann Apr 05 '10 at 19:26
1

..if you are never manually calling and or pulling values out of these parameters in your code behind...

Assuming the above statement to be true, I don't see those parameters being susceptible to SQL Injection. Perhaps you ran an automated scan and this is a false alarm?

Sripathi Krishnan
  • 30,948
  • 4
  • 76
  • 83
  • The results were given to us by a 3rd party who were more than likely using an automated tool and we believe this to be a false positive. But to make sure we do our diligence I am posing this to the community to see if anyone out there has run into this issue specifically. – Schleichermann Apr 05 '10 at 19:23
  • I'd ask the third party to back up their claim. – Martin Smith Apr 05 '10 at 19:30