1. by Brian Vees

2.  SQL Injection  Username Enumeration  Cross Site Scripting (XSS)  Remote Code Execution  String Formatting Vulnerabilities

3.  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

4.  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 + "'";

5.  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 --'

6.  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'

7.  “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

8.  A very simple method of finding valid usernames

9.  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

10.  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

11.  This form echoes what the user entered in the case of an invalid login (i.e. invalid characters)  What if we input JavaScript?

12.  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:

13.  User input cleansing  Don’t echo user input back unless it is necessary

14.  Potentially the most dangerous vulnerability  Stems from unsecure settings on a web server

15.  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

16.  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

17.  Ensure web server configuration is secure (namely, if using PHP, turn register_globals off)  Validate user input

18.  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

19.  %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

20.  Make sure and verify all user input  Replace or reject special characters (“%”)

21.  What is the golden rule that will stop the majority of these website attacks? Validate User Input!