A very common, and easy to exploit vulnerability Requires basic SQL knowledge The basic idea: Find a user-inputted field that most likely is used to query a database Insert text in the field which will then merge with the SQL query being executed Examine the results to gain info about the database Using this info, write better queries to receive potentially private data
Given a sample login prompt on a webpage: Query to validate username might look like this: Entering a single apostrophe “breaks out” of the intended SQL code, allowing other code to be executed query = "select * from user where username='" + tbUserName.Text + "'";
Entering this data causes the following query to be sent to the database: Since 1=1 is always true, this query returns all users in the database select * from user where username='' or 1=1 --'
SQL injection to obtain error messages containing useful data SQL injection to delete data ( 'drop [tablename]-- ) SQL injection to execute files exec sp_oamethod @o, 'run', NULL, 'executable.exe'
“Escape” apostrophes String replacement on SQL-specific character combinations (“--”) Safest: reject any bad input rather than attempting to “cleanse” it Not necessarily plausible: names like O’Brien and other valid input contain apostrophes
A very simple method of finding valid usernames
Use the same error message for invalid password and invalid username This way an attacker has no idea whether or not the username is correct
Another type of code injection, but with client- side script Can be used to bypass client-side security, as well as gain other information (session cookies) Yahoo! and even Google have previously fallen victim to this vulnerability
Consider if we now input the following code: alert(document.cookie) With this data, we can bypass cookie-based security Also, external, lengthier scripts can be injected:
User input cleansing Don’t echo user input back unless it is necessary
Potentially the most dangerous vulnerability Stems from unsecure settings on a web server
In PHP, the register_globals setting is often set to “on” to ease development This allows for global variables to be set remotely require($page. “.php”); If $page is not initialized, any arbitrary file can be included and will be executed on that server
There are several XML specifications that are also vulnerable to remote code execution Improperly validated XML can “break out” of the XML, and execute malicious code
Ensure web server configuration is secure (namely, if using PHP, turn register_globals off) Validate user input
An attack on server-side functions that can perform formatting (such as C’s printf) Special characters are used to read or write sections of memory that normally would not be accessible
%s can be used to continue reading data off the stack until an illegal memory address is attempted to be accessed, crashing the program %x can be used to print areas of memory that are normally not accessible %d, %u, and %x can be used to overwrite the instruction pointer, allowing the execution of user-defined code
Make sure and verify all user input Replace or reject special characters (“%”)
What is the golden rule that will stop the majority of these website attacks? Validate User Input!