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.
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.
 |
| 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.