Jim Kielt
Table of Contents (Jump to)
1.0 Analysis
1.1 Cross-Site Scripting: 239 vulnerabilities detected.
1.2 File Manipulation: 9 vulnerabilities detected.
1.3 SQL Injection: 4 vulnerabilities detected.
2.0 Bibliography
Table of Figures
Figure 1 – RIPS results output for bWAPP
Figure 2 – Line of code from xss_json.php vulnerable to Cross-Site Scripting detected by RIPS
Figure 3 – Returned message from xss_json.php
Figure 4 – Returned message from xss_json.php with a script being passed to the application.
Figure 5 – Returned message from secured xss_json.php with the script being passed to the application.
Figure 6 – Vulnerable to File Manipulation code detected by RIPS
Figure 7 – Link to uploaded file on unrestricted_file_upload.php showing path to uploads
Figure 8 – Attempted upload of a PDF file on unrestricted_file_upload.php
Figure 9 – Vulnerable to SQL Injection code detected by RIPS
Figure 10 – Message from SQL Injection on sqli_3.php
1.0 Analysis
The open source project for analysis for source code vulnerabilities is The Buggy Web App or bWAPP. This application is deliberately insecure to help security experts and students of IT security learn about the vulnerabilities that exist on the Internet today, how they can be exploited and how they can then be secured. bWapp is a PHP application that makes use of a MySQL database. [1]

Get Help With Your Essay
If you need assistance with writing your essay, our professional essay writing service is here to help!
Essay Writing Service

To analyse the source code for vulnerabilities, a static source code analysis tool is required. RIPS is such a tool which is written in PHP and designed to find vulnerabilities in PHP applications. It transforms the PHP source code that it is analysing; into a programme model that can detect potentially vulnerable functions or sensitive sinks that could then be tainted by user input that causes vulnerabilities. [2]
So a potentially vulnerable function in source code that uses a source containing user input creates a vulnerability.
bWAPP is available as a virtual machine called buzz-box where it can run as a stand-alone web server on a lab/testing network. To analyse the buzz-box server, the RIPS application files need to be extracted to the buzz-box server’s document root i.e. /var/www/rips/. Then on the host machine’s browser, navigate to http://localhost/rips to bring up the main scanning page. The path to the file or directory and/or subdirectories to be scanned is entered along with some available options before the scan button is clicked.
The available options for scanning are as follows:
Verbosity level:1. User tainted
2. User, file and database tainted
3. User, file and database tainted secured
4. User, file and database untainted secured
5. Debug mode
Vulnerability type:
All or one of the following:
Server-side all or one of the following:
Code Execution, Command Injection, Header Injection, File Disclosure, File Inclusion, File Manipulation, LDAP Injection, SQL Injection, XPath Injection, and other.
Client-side all or one of the following:
Cross-Site Scripting and HTTP Response Splitting
Unserialized / POP

For the bWAPP analysys, /var/www/bWAPP was entered as the path with the subdirectories option checked. Verbosity level option 2 (User, file and database tainted) and vulnerability type option All was selected. After clicking the scan button, 198 files were scanned in the web directory and after just under a minute, the statistical output in figure 1 was generated.
According to RIPS, the scanner works by tokenizing and parsing all of the PHP source code in the file or directory structure and tranforms the code into a program model which detects sensitive sinks that can be tainted by user input, the source throughout execution of the program.
At a glimpse it can be seen that Cross-Site Scripting has been heavely detected along with some of the other top vulnerablilties found in web apps today. Of the 198 files scanned, 4251 sensitive sinks (vulnerable functions) were found of which 293 could be tainted by user input and therefore considered vulnerabilities.
The three chosen vulnerabilites for futher analysis are as follows:
1.1 Cross-Site Scripting:239 vulnerabilities detected.
Cross-site scripting (XSS) is an injection attack where malicious scripts can be passed through user input on to the web application to create undesired effects and generally performed through a client browser.
An attacker can use his browser to use XSS to execute a malicious script to another browser user visiting the same page and have the script display unintended information or perform an unintended action. Because the user’s browser has no way to know if the script should be trusted or not, it has no option but to execture the script. The script or tainted data becomes embedded into the HTML output by the application and rendered by the users browser which can lead to website defacement, phishing or cookie stealing and session hijacking.[3]
A potentially vulnerable function like echo() which prints data to the screen that uses a source like $_GET containing user input can create Cross-Site Scripting vulnerability, e.g:
$title = $_GET[“title”];
echo ($title]);
The above code would display whatever the user enters and could therefore be exploited.
To demonstrate the Cross-Site Scripting vulnerability in bWAPP, the focus is on the bWAPP/xss_json.php file/page. Figure 2 shows the code snipit where user input was found and marked by the scanner (white dots) as a potential entry point for exploitation. Line 34 of the program places unchecked user input straight into a function which causes the vulnerablility.

Figure 2 – Line of code from xss_json.php vulnerable to Cross-Site Scripting detected by RIPS
This page was opened in a browser and was titled ‘XSS-Reflected(JSON)’, displaying one textfield and a search button looking for the name of a movie to be entered. To test how this page works, ‘Spiderman’ was entered using the ‘Marvel’ hint ans submitted. The resulting message appeared below the textfield based on the input (see figure 3).

Figure 3 – Returned message from xss_json.php
So the user input was displayed back in the output message which could mean that the input was probably unchecked.
To test how the texfield responded to a simple script to display cookie information in an alert box, the following was entered and submitted:
The message this time did not display the entered script statement but instead tried to execute the script and displayed lines of the code from the page (see figure 4):

Figure 4 – Returned message from xss_json.php with a script being passed to the application.
This message reveals information about the application that should never be dispayed and raises a security concern. A hacker could learn further how to exploit the application using this information.
Mitigation:
We should never trust user data entered into an aplication which needs to be screened for the likes of scripting code. All entered data should be encoded before being embedded into the output. HTML encoding converts untrusted user input into a safe format that can be used as output instead of executing as code in the browser e.g Converts ‘&’ to ‘&amp’. For PHP applications, HTML entity encoding is done via the htmlspecialchars() function which convert all special characters to HTML entities.[4] To encode any double or single quotation marks that could be interpreted by the application as code, the ENT_QUOTES parameter is used to prevent any injections and defining the correct charset prevents any special characters being used in the input e.g UTF-8 ASCII compatible multi-byte 8-bit Unicode.
Line 34 shows the vulnerable code which was updated to incorporate the mitigation to make it secure.
Vulnerable code:
$title = $_GET[“title”];
Secure code:
$title = htmlspecialchars ($_GET[“title”], ENT_QUOTES, “utf-8”);
Once the code was secured, the same script code was entered and submitted and this time, the message showed the script statement in the message but this time treated it as a string and did not attempt to execute it (see figure 5):

Figure 5 – Returned message from secured xss_json.php with the script being passed to the application.
1.2 File Manipulation:9 vulnerabilities detected.
File Manipulation can occur with Full Path Disclosure vulnerabilities where an attacker can see the path of a file in the url of a webapp, e.g. /var/www/htdocs/file. This gives the attacker a partial knowldege of how the application is structured or how the underlying operating system is arranged in order to mount different kinds of attacks. [5]
Knowing the location of a particular file, the attacker could access and manipulate it by adding malicious code to compromise the webapp server or even upload an attack tool to that location.
A potentially vulnerable function like move_uploaded_file() that uses a source like $_FILES directly from user input (upload) can create File Manipulation, e.g.
move_uploaded_file($_FILES[‘file’][‘tmp_name’], “images/” . $_FILES[‘file’][‘name’]);
To demonstrate File Manipulation in bWAPP, the bWAPP/unrestricted_file_upload.php page was examined. Figure 6 shows the vulnerable code where unchecked user input (the selected file for upload) is used by the application.

Figure 6 – Vulnerable to File Manipulation code detected by RIPS
When the page was opened in the broswer, a ‘Browse’ and ‘Upload’ button were displayed where an image file could be uploaded to the server. A test image file was uploaded and the resulting message returned the link to where the file is stored on the server. The link was followed to a directory called ‘images’in the bWAPP directory. Navigating to the images directory brought up a list of all files in the that directory (see figure 7).
A PDF file was then selected and successfully uploaded so no file type check was in place. Effectively these files could be manipulated as described above or malicious files uploaded and executed like a webscript that take control of the server.

Figure 7 – Link to uploaded file on unrestricted_file_upload.php showing path to uploads
Mitigation:
Sensitive information like file locations should not be visable to the user and any path or file names displayed should be encoded to prevent leakage of this information. This could be achieved by changing the path and filename to a format that the server understands like a hashing function. The move_uploaded_file function should have the file checked that the files being uploaded are image files before being uploaded to the ‘images’ directory.
Line 34 shows the vulnerable code which uploads any file to the ‘images’ directly without being firstly checked. The preg_match() function can be used to check for particular file extensions, in this case images file types, in a new $filename variable. [6] A file check statement was added to the vulnerable code that checks for the file type and will now only execute the original code as long as the file has the correct extension using an if statement. Line 166 uses the $file_error variable to determine if the upload is successful or not which determines the output, so $file_error is firslty set to an unsuccessful attempt message by default which is cleared if the correct file extension executes.
Vulnerable code:
move_uploaded_file($_FILES[‘file’][‘tmp_name’], “images/” . $_FILES[‘file’][‘name’]);
Secure code:
$filename = $_FILES[“file”][“name”];
$file_error = “Not an image file, try again”;
if(preg_match(“/.(gif|png|jpg)$/”, $filename))
{
move_uploaded_file($_FILES[“file”][“tmp_name”], “images/” . $_FILES[“file”][“name”]);
$file_error = “”;
}
Once the code was secure, another PDF file was browsed to and the ‘Upload’ button clicked and this time because the file is now firstly checked for file type and because pdf in not in the array of allowable files, the upload function does not execute (see figure 8):

Figure 8 – Attempted upload of a PDF file on unrestricted_file_upload.php
1.3 SQL Injection:4 vulnerabilities detected.
SQL Injection attacks happen when SQL queries are successfully injected through user input data into the application that can reveal information about the database to allow for further attacks where the database can be modified by the insertion, updating and deletion of data. [7] The user input is crafted in such a way that it is interpreted by the application as SQL commands allowing the attacker contol over the database in even the operating system itself.
A potentially vulnerable function like mysql_query() that uses a source like $_POST containing user input can create SQL Injection e.g
$login = $_POST[“login”];
$password = $_POST[‘password’];
$sql = “SELECT * FROM heroes WHERE login = ‘” . $login . “‘ AND password = ‘” . $password . “‘”;
$recordset = mysql_query($sql, $link);
To demonstrate the SQL Injection in bWAPP, the bWAPP/ sqli_3.php page was examined. Figure 9 shows the vulnerable code where unchecked user input is used by the application.

Figure 9 – Vulnerable to SQL Injection code detected by RIPS
When this webpage is loaded, it shows a login screen for ‘superhero’ credentials requesting a login and password. A basic test for web applications for SQL Injection is the entering of the following command in place for the username and/or password: ‘ or 1=1– The single quote is interpreted by the web application as a special character in SQL which allows for the additional condition to the SQL command 1=1 which is of course always true and the double hyphen is intrepreted by the web application as a comment which closes off the query. When the ‘ or 1=1 — statement is entered into the login and password fields, a welcome note is displayed (see figure 10):

Figure 10 – Message from SQL Injection on sqli_3.php
This shows that this web page is vulnerable to SQL Injection attacks which uses unchecked user input directly by the application which could be exploited in compromising the server.
Mitigation:
The most successful defence against SQL injections is to never use user input directly in the application and to use parameterized queries (prepared statements) instead — which is supported by most languages — and to avoid using dynamic SQL queries or SQL queries with string concatenation. For PHP the mysql_real_escape_string() function can be used to escape special characters in a string for use in an SQL statement.
Lines 137 and 137 of the code takes in the user inputs which are executed in the SQL statement in line 140 which is the vulnerable code really is. By implementing the mysql_real_escape_string() function into the code it will escape any special characters. [8]
Vulnerable code:
$sql = “SELECT * FROM heroes WHERE login = ‘” . $login . “‘ AND password = ‘” . $password . “‘”;
Secure code:
$sql = “SELECT * FROM heroes WHERE login = ‘” . mysql_real_escape_string($login) . “‘ AND password = ‘” . mysql_real_escape_string($password) . “‘”;
Once the code was secured, the ‘ or 1=1 — statement was entered again into the login and password fields and this time instead of getting the previous message as above, the invalid message displayed (see figure 11)

Figure 11 – Message after attempted SQL injection on secured sqli_3.php
2.0 Bibliography
[1] itsecgames. 2015. itsecgames. [ONLINE] Available at: http://www.itsecgames.com/. [Accessed 19 February 2015].
[2] RIPS – free PHP security scanner using static code analysis. 2015. RIPS – free PHP security scanner using static code analysis. [ONLINE] Available at: http://rips-scanner.sourceforge.net/. [Accessed 19 February 2015].
[3] Cross-site Scripting (XSS) – OWASP. 2015. Cross-site Scripting (XSS) – OWASP. [ONLINE] Available at: https://www.owasp.org/index.php/XSS. [Accessed 19 February 2015].
[4] PHP: htmlspecialchars – Manual . 2015. PHP: htmlspecialchars – Manual . [ONLINE] Available at: http://php.net/manual/en/function.htmlspecialchars.php. [Accessed 25 February 2015].
[5] Full Path Disclosure – OWASP. 2015. Full Path Disclosure – OWASP. [ONLINE] Available at: https://www.owasp.org/index.php/Full_Path_Disclosure. [Accessed 02 March 2015].
[6] PHP: preg_match – Manual . 2015. PHP: preg_match – Manual . [ONLINE] Available at: http://php.net/manual/en/function.preg-match.php. [Accessed 25 February 2015].
[7] SQL Injection – OWASP. 2015. SQL Injection – OWASP. [ONLINE] Available at: https://www.owasp.org/index.php/SQL_Injection. [Accessed 19 February 2015].
[8] PHP: mysql_real_escape_string – Manual . 2015. PHP: mysql_real_escape_string – Manual . [ONLINE] Available at: http://php.net/manual/en/function.mysql-real-escape-string.php. [Accessed 25 March 2015].