Skip to main content

How to Approach Web Application Vulnerability Assessment using Burp Community | Part - 1 | Audit Guidelines | High Impact Web Vulnerability

The blog basically covers how to check to web application vulnerability with Burp Community Edition. This blog will be very helpful while performing the web application security assessment manually. In this part of the blog, we will cover a few vulnerabilities with High impact severity. So here is the blog.

HTTP PUT method is enabled

Audit Guideline

1) Capture the base request in the burp community and send the request to the repeater.
2) Change the request method to PUT and set the path with a file name as /test/shell.php and send the request to the application server.
3) Observe the response if the server response with 201 Created response. Then the application is vulnerable.
4) Now upload the shellcode as shown below and BOOM. Happy RCEing.
Note- If the PUT method is not allowed on base URL/request trying uploading on a different directory in the application.

Proof of Concept

A web shell is uploaded using the PUT method

Server-side request forgery (SSRF) - Out-of-band resource load (HTTP)

Audit Guideline

1) Capture the base request in the burp community and send the request to the repeater.
2) Change the request path to any internal or external URL. For eg. change the request path to https://www.lucideus.com.
3) From Exhibit below, it can be observed that the application includes the response of https://www.lucideus.com. 

Proof of Concept

Application is fetching the pages of another website in response

HTTP response header injection 

Audit Guideline

1)Capture the request in the burp community and send the request to the repeater.
2) Try Injecting some value For e.g "abcd" in the URL before the parameters start. The injected value will be visible in the X-Cache-Key response header as seen in the Exhibit 3 below.
3) This can further be exploited to change the Content Type and execute malicious javascript payloads as seen in Exhibit 4 and Exhibit 5, thereby leading to Reflected Cross-Site Scripting.

Proof of Concept

Exhibit 3

Exhibit 4

Exhibit 5

Hope you like this blog. The next part is coming soon. Please give your valuable feedback on this blog. You can comment if you want details in-depth on the web vulnerabilities mentioned above or any web-related vulnerability.

Security blog of the month

How 13 Bytes Freeze Google Perfetto: An Integer-Overflow DoS Behind Billions of Devices

Here's a fun one. I found a way to make a tiny file - just 13 bytes , smaller than this sentence - completely freeze one of Google's most widely used engineering tools. Not crash it with a bang. Freeze it. Pin a CPU core at 100% and make it spin forever, going nowhere, until you kill it. The tool is called Perfetto , and once you understand where it lives, this stops being a curiosity and starts being a genuinely useful lesson about how software breaks - one that's worth reading whether you write code, run a security team, or sign the budget. Let me walk you through it in plain English. First, what is Perfetto - and why should you care? Most people have never heard of Perfetto, yet it quietly runs near a staggering number of devices. Perfetto is Google's open-source system tracing toolkit. Think of it as a flight recorder for software: it captures a detailed, timestamped record of everything a device is doing - which app woke up, which function ran, where t...
Post a Comment
Read more