This is the second post in a series where I look to create a framework to build and test proof-of-concepts in hopes of gaining a deeper understanding of various web application fundamentals. In this post I’ll introduce a few vulnerable scripts you can use to research various attacks and defense mechanisms (headers, cookie flags, and browser settings).
Part 1: Web Application Lab – Proof-of-concept Infrastructure
I’ve created some PHP scripts with the following vulnerabilities:
- Cross-Site Scripting (XSS),
- Cross-Site Request Forgery (CSRF)
- Local File Inclusion (LFI)
- Remote File Inclusion (RFI)
- Command Injection
My test environment is running on CentOS so everything in this post relates to the Linux operating system. At some point I will port these over to IIS and even recreate them in ASP.NET. Just not today!
I’ve made them available at my github repo. Download the entire set and place them into a web-enabled directory.
NOTE: Do NOT host anything contained in this post on the internet. The content in this repository contains vulnerabilities and is only meant to be hosted in a private/protected lab environment.
The above-linked scripts should all be fairly self-explanatory. Each will output information regarding a vulnerable input parameter. Abuse of each vulnerable input is straight-forward. Make note that the CSRF related scripts write to files. You will need to adjust your file-system permissions to make them work properly. Something like the following should do the trick. Adjust your paths accordingly.
chown apache /var/www/html/data/profile.csv chown apache /var/www/html/data/token.csv
If you are using SELinux, you’ll need to work through something like the following:
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/data/profile.csv" restorecon -v /var/www/html/data/profile.csv semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/data/token.csv" restorecon -v /var/www/html/data/token.csv
Additionally, the command injection and remote inclusion scripts will need you to adjust some PHP parameters in /etc/php.ini.
NOTE: These are INSECURE settings. DO NOT set the configuration of a production, web-exposed server with these values.
; This directive allows you to disable certain functions for security reasons. ; It receives a comma-delimited list of function names. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. ; http://php.net/disable-functions disable_functions = ; Whether to allow the treatment of URLs (like http:// or ftp://) as files. ; http://php.net/allow-url-fopen allow_url_fopen = On ; Whether to allow include/require to open URLs (like http:// or ftp://) as files. ; http://php.net/allow-url-include allow_url_include = On
So if you’ve worked through everything in the previous portion of this post series, you should now be able to begin testing and examining each attack type from the request, response, and source-code perspectives.
For example, the following request and response was taken from the Apache logs for an attack on the xss_post.php script.
POST /xss_post.php HTTP/1.1 Host: account.example.local User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://account.example.local/xss_post.php Content-Type: application/x-www-form-urlencoded Content-Length: 85 Cookie: test_cookie=foo-bar; xsrf_token=5ae5018ec23ba Connection: keep-alive Upgrade-Insecure-Requests: 1 input=%3Cimg+src%3Dx+onerror%3Dalert%28document.cookie%29%3E&xsrf_token=5ae5018ec23ba HTTP/1.1 200 OK Date: Sat, 28 Apr 2018 23:20:09 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16 X-Powered-By: PHP/5.4.16 Set-Cookie: test_cookie=foo-bar; path=/ Set-Cookie: xsrf_token=5ae501a9c5c6c; path=/; httponly Content-Length: 329 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 <html> <body> <h2 id="title">XSS Vulnerable Form</h2> <p id='input'>POST['input'] = <img src=x onerror=alert(document.cookie)></p> <form action="/xss_post.php" method="post"> <input type="text" name="input"> <input type="hidden" name="xsrf_token" value="5ae501a9c5c6c"> <input type="submit"> </form> </body> </html>
And the source code behind all of it.
Producing the following browser output.
In my next blog post I’ll start to dive into the Same Origin Policy and how it affects Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
