Short Description:
Improper application validation passes invalid data into SQL update statements executed in SQL Server 2012, causing a server-side error which is not handled by the application. From a database security perspective, could this be exploited?
Background:
I am not a full-time security professional and have a security-related question which hopefully has a simple answer. I am investigating potential security vulnerabilities in an "off the shelf" web application with a "black box" approach and have come across a cause for concern. The application seems to fail to validate the length of data input for a few nvarchar fields and passes the input data directly to the database. Even when the data is in violation of the data type length limit, the application claims everything was committed successfully. Because the attempted write causes an error on the server side and the data is not committed to the database, it seems that this is a statement based only on the application validation and not any return information from the database. I do not have access to the web application source code, but would like to write a justification to the vendor on why they should consider this a top priority to fix.
Question:
Beyond the obvious problem of losing the input data from the invalid SQL insertion statement, can this overflow of data type length at the SQL Server level be exploited to either read or write to the database, or to create a memory hogging loop that will hinder subsequent requests?
In various programming languages, I am aware that buffer memory overflows can be exploited to execute code at the application-level ("smashing the stack"), and I was wondering if execution at the SQL Server level is controlled and will just produce an error from validation at the SQL Server level, or if it could somehow include additional commands like ; DELETE FROM USERS; or something to that effect that could be additional cause for concern.
Let me know if you need additional information. I would imagine there is extensive documentation surrounding this, but wasn't able to find what I needed from Google or other stack answers after significant searching. Perhaps the answer is just "SQL Server 2012 has adequate internal validation to prevent this." Please point me in the right direction. Thank you!
