"Blind SQL Injection (Time-Based)" vulnerability in ASP.NET web application
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!
