Penetration Testing mailing list archives
Re: Security assessment on stored proc vulnerability
From: Frank Knobbe <frank () knobbe us>
Date: Mon, 17 May 2004 12:43:11 -0500
On Fri, 2004-05-14 at 22:13, Calvin Wood wrote:
SQLStr="exec IdentifyUser '" & UserName & "','" & Password & "'" conn.open connstr set cmd.ActiveConnection=conn set rs=cmd.Execute SQLStr if rs.EOF invalid username/password combination else valid username/password end if ... Now I noticed that the SQLStr is built from the form variable, and it is vulnerable to SQL injection. This is a definite vulnerability. However, in my report, I need to specify whether the risk is low/moderate/high. This is the area I need help on.
Of course, the lack of input validation should always be high risk. That's something that needs to be fixed. But even if that has been taken care of and is in place, there is another issue with this code. It issues a SQL query, and then only checks if it gets results back or not (check for EOF). That is insufficient. If the attacker can craft (with or without input validation) input data such that the database will return any non-EOF condition, he has circumvented your authentication logic. Instead of just checking for !EOF, you should check that you actually receive valid data from the database, data that you could expect. In the case at hand, the script should specifically check if rs.Username==FormUserName (preferable with a check to see if the account is valid, meaning not locked, not expired, etc). Without that explicit comparison in the web application you rely solely on the security of the stored procedure. I believe that you should use logic in both places. Have the stored procedure verify and return results, but also have the web application verify the validity of these results. Failure of the security check within the stored procedure can then be caught through the security check in the web app. (For example, if the returned username is unexpectedly Administrator, the web app can catch that error condition.) Regards, Frank
Attachment:
signature.asc
Description: This is a digitally signed message part
Current thread:
- Security assessment on stored proc vulnerability Calvin Wood (May 16)
- RE: Security assessment on stored proc vulnerability Aaron C. Newman (May 17)
- Re: Security assessment on stored proc vulnerability Frank Knobbe (May 17)
- <Possible follow-ups>
- RE: Security assessment on stored proc vulnerability Michael Howard (May 17)
- RE: Security assessment on stored proc vulnerability Brett Moore (May 18)