Scott Ning
SE 526
Final Exam
11 Jun 2013
SE526 – Final Exam
Vulnerability Identification And Exploitation
Code Sample 1 – Cross site scripting
Lines of code:
 $search_term = $_GET['query'];
 <title>Search Results for <?php echo $search_term; ?></title>
Issue: The user-alterable query string “query” is reflected through the echoing of the title tag and it is
not sanitized or validated. This means that the input of HTML and Javascript code can be equally used,
which demonstrates vulnerability.
Sample Parameters for exploitation/vulnerability:
 Access the page’s URL with the query string , “query”, of value “%3C
/title%3CE%3Cimg+src%3D1+onerror%3Dalert%281%29%3E %3Ctitle%3E”
Access Gained: The exposing of this malicious URL to any users who unknowingly access it can be
potentially used to redirect users to an attacker’s server, which will allow the attacker to steal cookies or
session/authentication information. With such information, attackers can exploit users and potentially
log into the account, change the password, and take ownership of the account.
Mitigation: To mitigate this issue, the “query” input should be validated and sanitized. The application
should transform tags to their HTML equivalent character entities. An example of this is to change “<” to
be “&lt;”.
Code Sample 2 – SQL injection
Lines of code:
 $query = "SELECT user_id,usergroup FROM ".$config['db']['pre']."users WHERE username='"
. $_POST['username'] . "' AND password='" .md5($_POST['password']) . "' AND status = '1'
LIMIT 1";
Issue: SQL injection is possible through the user-inputted “username” and “password” post parameters
and they are not sanitized. More dangerously though, the password is not properly validated; the user’s
password is “checked” ONLY through the same vulnerable SQL query.
Sample Parameters for exploitation/vulnerability:
 Enter into the “username” field the value of “<someexistingusername>’ --” and into the
“password” field some value that satisfies the password input validation.
o An example username input would be: admin’ –
 And submit the form/request (probably by clicking a “login” button).
2
Access Gained: The exploitation of users is possible because this allows for the potential to add SQL
code to essentially cause the application cancel or ignore the password “validation” through ways such
as commenting the rest of the query out. Therefore, an attacker only needs to know another user’s
username and he or she can easily log in as that user without knowing the password.
Mitigation: An option of mitigating this issue is to sanitize the input by properly accepting quotes as
input through escaping input. An additional option is to separate this query into two; one to get the
username and the other to get the password. Then do the password and username checking within PHP
code.
Code Sample 3 – SQL injection
Lines of code:
 $query = "SELECT user_id,usergroup FROM ".$config['db']['pre']."users WHERE username='"
. escape_input($_POST['username']) . "' AND password='" .
escape_input(md5($_POST['password'])) . "' AND status = '1' LIMIT 1";
Issue: Even with the quote-escaping function, it does not fully protect against SQL injection through the
user-inputted “username” and “password” post parameters. In this case, an attacker can use the code’s
escaped quote to end the username field. SQL injection may be a little harder, but it is still possible and,
therefore, the core of the issues presented from the previous “Code Sample 2” still exists.
Sample Parameters for exploitation/vulnerability:
 Enter into the “username” field the value of “<someexistingusername>\’ --” and into the
“password” field some value that satisfies the password input validation.
o An example username input would be: admin\’ –
 Tip: This would then be read as admin\’’ – (hence using the escaped-quote,
from the added function, to end the username field)
 And submit the form/request (probably by clicking a “login” button).
Access Gained: Same exploitations and access gained as presented from the previous “Code Sample 2”.
Mitigation: To mitigate this issue, the suggestions from the previous “Code Sample 2” should be
considered. In addition to those, though, the “escape_input” function should also apply a quote
command such as PDO::quote or utilize special character escaping such as using
mysqli_real_escape_string.
Code Sample 4 – Insufficient authentication and improper input handling
Lines of code:
 foreach($_POST as $param_name => $value) {
$content.= "\$config['db']['".$param_name."'] = '".addslashes($value)."';\n";
}
 fwrite($handle, $content);
Issue: The $param_name post parameter does not do any sanitation or validation of valid inputs. Also,
the use of the PHP fwrite method appends the inputted content to the existing file, which can
3
potentially cause the existence of duplicate keys. The entire configuration-writing-file functionality also
does not include any signs of authentication.
Sample Parameters for exploitation/vulnerability:
 To exploit authentication vulnerability: Attempt to access this functionality/URL without any
form of authentication or logging in.
 To exploit duplicate key vulnerability: Send a post request to this page with a test parameter
and test value and repeat this step with the same test parameter and test value.
 To exploit invalid input vulnerability: Send a post request to this page with parameter of:
o ‘testparameterplaceholder’] = ‘testvalueplaceholder’;\n<Any PHP code in
here>$config[‘db’] [‘testsecondparameterplaceholder
o With an empty value
Access Gained: The exploitation of the application is present due to the multiple possible vulnerabilities
within this code. Any user can potentially access this functionality and modify the configuration file. The
writing of duplicate keys is also possible, which may possibly lead to breaking the application. Also, the
injection of any PHP code is possible, which can lead to it being executed on every page of the
application, due to the universal include of this configuration file.
Mitigation: To mitigate these issues, authentication checking, duplication checking (and overwrite
appropriately), and sanitation checking should be added to this functionality,
Code Sample 5 – Insecure File Upload
Lines of code:
 if(!eregi('image/', $_FILES["avatar"]["type"])) {
echo 'The uploaded file is not an image please upload a valid file!';
exit(0);
}
Issue: As described by the official PHP documentation, the value in $_FILES[“file”][“type”] is “completely
under the control of the client and not checked on the PHP side”. This means that users/attackers will
still have control be able to bypass the file uploading validation.
Sample Parameters for exploitation/vulnerability:
 A script that sends a standard HTTP request to upload a PHP file that has a payload with
“Content-Type: image/jpeg” and has malicious code.
 Disguising a script as an image; Put PHP code in a jpg file.
 Depending on server settings, multiple file extensions could be used for this exploit as well.
Appending a valid file extension after the PHP file extension would be valid in this case; for
example, a file called hello.php.jpg would be valid.
Access Gained: The ability to upload files with custom script within it is vulnerable to the exploitation of
the application. It will allow an attacker to upload and run malicious scripts that can do various actions
such as retrieve or modify data. These scripts can essentially create a backdoor, allowing the attacker
much control over the entire application. The attacker can also potentially upload a shell and execute
system commands through that shell.
4
Mitigation: Multiple steps can be used to help mitigate this issue. File extension checks should be in
place; adding a white list of valid file extensions should be part of those checks. However, mitigation
should not be limited to just this; more layers of security should be added as well. Configuration could
also be set in the .htaccess file to make images be associated to their default handlers. Another solution
would be to upload the file outside of the web directory (so they can never be served) and have a
custom script that retrieves, handles, and outputs the file correctly. Another addition would be to
rename the uploaded files randomly, making attacks more difficult.
Short Answer
1. The use of MD5 for storing passwords in cookies is an insecure practice because it can be
intercepted and easily translated/decoded. This creates the possibility for an attacker to
impersonate the user. Therefore, instead of storing the hashed password value in a cookie, sessions
should be used instead. Or, also, another encryption method could be used, server side validation
could be added, and the password hash should be salted with a long/random enough string.
2. Creating a blacklist of words to attempt to stop Cross-site scripting is not an effective method
because this blacklist does not cover everything. A more effective approach would be to blacklist “<”
and “>” or to transform tags to their HTML equivalent character entities. An example of this is to
change “<” to be “&lt;”.
3.
a. CSRF can be used on JSON specific pages by intercepting the post request and modifying it
(with a tool such as Burp Suite).
Example attack code:
POST /updatecart HTTP/1.1
Content-Encoding: identity
Content-Length: 71
Content-Type: application/json
Cookie: SessionID = 01040fb215dff9dc7088c666823bc43c44e295a1;
Host: bobsbacon.tasty.net
{"item_name":"bacon blanket","update_cart":1,"item":"6886","elx":999}
b. CSRF can be used on XML specific pages by intercepting the post request and modifying it (with
a tool such as Burp Suite).
Example attack code:
POST /newuser HTTP/1.1
Content-Type: text/tml
Cookie: SessionID = 01040fb215dff9dc7088c666823bc43c44e295a1;
Host: bobsbacon.tasty.net
Content-Length: 134
5
<User>
<FirstName>HackedFirstName</FirstName>
<LastName>HackedLastName</LastName>
<Email>hackedemail@hacked.com</Email>
<Gender>Male</Gender>
</User>
4.
a. The type of encryption being used to store these credit card numbers is stream encryption.
b. The issue with using this type of encryption for storing such numbers is that attackers can
retrieve the original values through the processes of XOR’ing other numbers and values.
An attacker can create an account and enter a credit card number, which gives the attacker
knowledge of the encrypted credit card number, the original number, and other users’
encrypted credit card numbers. Using these values, the attacker can use XOR to retrieve the
original credit card numbers.
c. The recommended type of encryption to store these numbers as a more secure alternative is
through 512 bit RSA.