Reference no: EM133141495

PRT 574 SECURITY ASSESSMENT IN WEB DEVELOPMENT

Assignment: Jump to portswigger website and register using your real name and cdu email id.

There will be many vulnerabilities listed and you can select any one vulnerability (except SQLi and XSS) and complete all the options/tasks in the selected vulnerability.Dashboard to show that you have completed the selected tasks must be included in the report.

You need to prepare a detailed report on how you successfully completed the tasks with possible screenshots and steps followed. The screenshots must contain the timestamp as a proof of your work.The report cannot exceed 15 pages (including the figures).

Lab - 1 Basic SSRF against the local server

1. The stock check feature present on the website which fetches data about a product from an internal system was used to solve lab - 1.
2. It wasn't possible to access the admin page directly by adding /admin to the URL.
3. To alter the URL I then intercepted the request while checking the stock of one of the products.

4. Since it was a basic SSRF I altered the stock API to https://localhost/admin
5. https://localhost/admin/delete?username=carlos I then examined the HTML code to identify the query to delete the user and submitted in stock API.

Lab - 2 Basic SSRF against another back-end system

1. Intercepted the stock check request again through burpsuite but this time sent it to the burp intruder.

2. https://192.168.0. §1 §:8080/admin After sending the request to the burp intruder changed the stock API and added the new payload marker around 1.
3. Opened the Payload tab altered the payload type from a simple list to numbers and then entered IP range 1, 255,1 respectively in boxes from, to and step which is the payload (1)
4. After starting the attack, I found one interface(46) which belonged to admin with status 200.
5. https://192.168.0.46:8080/admin/delete?username=carlosSent the request to repeater altered the stock API and send the request.

Lab - 3 SSRF with blacklist-based input filter
1. Intercepted stock check request and sent it to the repeater.
2. https://127.0.0.1/ Altered the stock API URL to check if the request is accepted.
3. After rejected request altered IP again to 127.1/ to bypass by confusing the server.
4. Tried changing it to 127.1/admin and again got rejected.
5. Then I obfuscate the alphabet "a" using double URL encoding into %25%36%31.
6. Altered the stock API - https://127.1/%25%36%31dmin/delete?username=carlos and it went through.

Lab - 4 SSRF with whitelist-based input filter
1. Intercepted the check stock request and send it to the repeater.
2. Tried altering the stock API to - https://127.0.0.1 and found that the request is being checked against a whitelist in order to extract the hostname and the host must be stock.weliketoshop.net.
3. Altered the URL to - https://[email protected]/ and it got accepted because the whitelist had these credentials on it but still gave an internal error.
4. I then again added a # next to the username and it again got rejected.
5. I then obfuscated the # using double URL encoding to %25%32%33 and altered the URL to - https://localhost%25%32%[email protected]/admin and it went through.
6. Then I accessed the admin interface and deleted the user by altering the stock API

Lab - 5 SSRF with filter bypass via open redirection vulnerability

1. Again intercepted a check stock request and send it to the repeater.
2. Tried altering the stock API but didn't work because the direct request couldn't be sent to the host.
3. Tried playing around on the website and intercepting more requests and found that the path parameter was being placed in the header location when I clicked next product and redirecting the response and also the get and post method changed.
4. Made a query that can exploit the open redirection vulnerability and used that query in stock API - /product/nextproduct?path=https://192.168.0.12:8080/admin and this query gave access to the admin interface.
5. Edited the query again to delete the user and it worked /product/next

Lab - 6 Blind SSRF with out-of-band detection
1. For this task, I had to sign in for a trial version on a professional burp suite because a burp collaborator was required.
2. Intercepted a product request and sent it to the repeater.
3. Opened the burp collaborator and copied the payload to the clipboard.
4. Changed the referer with copied payload from the collaborator domain and sent the request.
5. Opened the burp collaborator and clicked the poll now button and collaborator a DNS lookup.
6. The collaborator was received from the backend IP address.
7. Lab - 6 solved.

Lab - 7 Blind SSRF with Shellshock exploitation
1. I installed the collaborator everywhere.
2. I then copied the domain of the lab and added it to the target scope will order to enable the collaborator everywhere to target.
3. Then I surfed the website and clicked few products.
4. I found out that whenever I clicked on a product on the website it triggered an HTTP communication through Burp collaborator using referer header.
5. The HTTP request captured included user agent string
6. I then sent the request containing the user agent string to burp intruder
7. I then opened the burp collaborator client in order to generate the collaborator payload and then used it with the shellshock payload.
8. I then replaced the user agent string in the request which I sent to burp intruder before.
9. Then I altered the referer header to https://192.168.0.§1§:8080 and cleared the earlier payload marker and added the new payload marker around 1 in the IP address
10. Initiated the start.
11. After the completion of the attack, I went back to the burp collaborator client and clicked on poll now.
12. I saw a DNS communication initiated by the back-end system of the website and the name of the operating system user was revealed.
13. At the end, I entered the username which I captured from the DNS lookup.

Attachment:- Security Assessment In Web Development.rar