sqlsecuritycode-injectionnessus

cgi generic sql injection problems


I was scanning a site when the following vulnerability popped up: CGI Generic SQL Injection

nessus sais that An attacker may exploit this flaw to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

So i continued reading and found out that the vulnerability sits in this piece of code:

Using the POST HTTP method, Nessus found that :

-------- output --------

 Exception Details: System.Data.SqlClient.SqlException: String or
binary data would be truncated.
The statement has been terminated. 

But i'm wondering how an attacker can exploit this vulnerability, because when i paste that piece of code it just give me the error.

So my question is how would an attack be able to actually hack into the site and bypass login etc. (Educational purpose only of course)


Solution

  • The error System.Data.SqlClient.SqlException indicates an error in your SQL query statement. This implies that value stored in the _codeTextBox parameter is not validated or otherwised sanitized before being put into the query.

    This would have varying implications depending on the query and logic surrounding its return value. It is impossible to determine the worst case scenario without a thorough understanding of the web application. Suffice it to say, this issue should be fixed by the developer. Fortunately, it is usually easy to fix once identified.

    In this case, it looks like the _codeTextBox parameter is being passed to the convert function. I doubt anyone could exploit this. But, this indicates insecure coding practices that probably appear in other areas that Nessus is not aware of. Read below for more info.

    I see this most often when the programmer simply concatenates the values with the SQL query string:

    Unsafe Example (java) (Source OWASP)

    String query = "SELECT account_balance FROM user_data WHERE user_name = "
      + request.getParameter("customerName");
    
    try {
        Statement statement = connection.createStatement( … );
        ResultSet results = statement.executeQuery( query );
    }
    

    Since the value simply gets appended to the end of the query, the user can change query to do something nefarious like login as any user or view all transactions. In the above example, the user could change the customer name parameter to something like '' or 1=1 or worse.

    Expected query:

     SELECT account_balance FROM user_data WHERE user_name = someuser
    

    Bad query:

     SELECT account_balance FROM user_data WHERE user_name = '' OR 1=1
    

    OWASP recommends the following defensive measures. Your situation will dictate what is appropriate:

    Primary Defenses:

    1. Use of Prepared Statements (Parameterized Queries)
    2. Use of Stored Procedures
    3. Escaping all User Supplied Input

    Additional Defenses:

    You really need to check out OWASP's site and read more about SQL injection.