0

I am working on an ASP.NET web application, and a recent security scan (conducted using SecurityMetrics) flagged a vulnerability related to Blind SQL Injection (Time-Based). Here are the details of the report:

Impact (as per the scan report):

By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, the scanner was able to cause slower responses. This suggests that the application may be vulnerable to Blind SQL Injection. The issue occurs because certain parameters are not properly sanitized, allowing malicious inputs like WAITFOR DELAY or SLEEP to execute. This could allow attackers to:

Bypass authentication Access or modify confidential data Potentially take control of the database server Vulnerable Parameters Identified:

__EVENTVALIDATION parameter in URLs such as:

/?__EVENTARGUMENT=&__EVENTTARGET=&__VIEWSTATE=...&__EVENTVALIDATION=...');WAITFOR DELAY '00:00:03';-- __VIEWSTATE parameter in requests like:

/login.aspx?__EVENTVALIDATION=...&__VIEWSTATE=...'; AND SLEEP(3)='...

What I've Tried So Far:

Ensured basic SQL injection protection by using parameterized queries in most places, but it’s unclear if these apply to built-in ASP.NET fields like __VIEWSTATE and __EVENTVALIDATION. Enabled validateRequest="true" in the web.config to reject malicious inputs.

My Questions:

How can I protect built-in ASP.NET fields like __VIEWSTATE and __EVENTVALIDATION from being exploited through SQL injection? Are there any specific settings or approaches for these fields? Is it necessary to encrypt or sign __VIEWSTATE and __EVENTVALIDATION to prevent tampering? If so, what’s the best way to do this? Are there any tools or practices I can use to verify that all potential SQL injection vulnerabilities have been addressed in my application?

Additional Information:

The application uses ASP.NET Web Forms and interacts with a SQL Server database. The vulnerability seems to be exploiting WAITFOR DELAY or SLEEP commands to test for delays in SQL queries. Any guidance on how to resolve this vulnerability and prevent similar ones in the future would be greatly appreciated!

3
  • 1
    If your SQL statements always use parameters, then no SQL injection should be possible. If code behind users values stored in viewstate then that should be safe, but even then, ANY values presented and sent to SQL server should use parameters. I mean, if some value from the user is shoved into viewstate, and then used in a SQL string, then you have a SQL injection issue, right?. As a result, then that scan tool should not be able to create delays by sending SQL commands such as wait for. Don't use SQL strings that involve concatenations. If you are not doing as such, that's a false scan flag Commented Jan 22 at 16:43
  • 1
    You shouldn't "protect" whatever __VIEWSTATE or anything like that. You must protect your queries. The point is have ALL queries protected, not just "in most places". Commented Jan 23 at 8:27
  • @YourCommonSense I am using storedprocedures and parametrize queries in pages. Commented Jan 23 at 14:21

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.