I would like to know if intercepting and modifying requests using Burpsuite before reaching server is considered as vulnerability.

In our web based and mobile applications, adequate security measures are in place to avoid replay attack and data integrity etc.,

Now the same is being evaluated by one of the application security teams, they use burpsuite to intercept the request payload and have raised few security vulnerabilities which aren't reproducible without using Burpsuite.

So using such tools is still a valid case and considered to be vulnerable?

Let me explain test case which i am trying to find a solution, to avoid replay attack i use client and server nonce in my web application. Requests are intercepted using burp-suite and only the client nonce is changed and forwarded to the server and its obvious request will be processed. It is raised to be a vulnerability.

  • Most applications do not need explicit protection against replay attacks and can rely on the defences built into SSL. Why does your application have a nonce? Commented Jul 23, 2018 at 12:52
  • I was completely relying on SSL for replay attack, people started raising, that requests are re-playable since when started using Burp suite. Generally they intercept request using Burpsuite and post the same to a RESTFul API using any restful client.
    – Samy
    Commented Jul 23, 2018 at 12:56
  • 1
    In most scenarios, simply being able to replay is not a vulnerability. Because the request includes some authentication (cookie, header, etc.) and is over SSL, only the original requester could replay it. Commented Jul 23, 2018 at 13:30
  • @PortSwigger Thanks your supportive answers, more or less my statement was to VAPT team. They couldn't buy and said that what if original requester himself is a hacker.
    – Samy
    Commented Jul 23, 2018 at 13:45
  • @Samy is the request behind authentication?
    – McMatty
    Commented Jul 24, 2018 at 3:34

1 Answer 1


What Burp does is intercepting a request and allowing the user/pentester to modify it. Technically it acts as a proxy, allowing the user to send pretty much arbitrary input to your application (server-side).

You seem to assume, that requests can only be sent using your app. This is not true and generally pretty dangerous to rely on. Keep in mind, that everybody can do a "Bash-Fu-1-Liner" using cURL and send literally anything to your server. Your webservice has to be prepared for that! If the only input checks you perform are client-side (which is untrusted code as users can mess with it), you have to overthink your security measures.

Separate client-side and server-side. Think of them as two pieces of software which have to be secure on their own.

Edit: As you added a test case to your question, I'll add the answer here. Penetration Tests flag a lot of things as potentially dangerous. It may be true and little bugs, which don't look like they can wreck havoc on your server, will do so, if exploited properly. However, a Penetration Tester will scan your app, test around, find bugs and report everything which looks dangerous. Keep in mind, that he does not know the application as well as you (or the Software Engineers/Developers) do.

Bugs found by him/her might be false positives and it's on you (and the tester) to verify bugs and prioritize them (irrelevant - critical) according to their damage potential (and other factors). Once in my environment, a pentester's scanner found a document which was reported as "Privilege Escalation" as its regular link is behind a login. False Positive, as it was an unimportant document.

  • Thanks for your inputs. I have a web application(client-side) and a Restful API(Server-Side) so it is two different entities. Issue currently is to mitigate replay attack i have used client and server side nonce, using burp suite they change client nonce every time and it still becomes valid at the server. Requests would be plain text when it reaches burp suite proxy. One possible solution is to return nonce with every response, becomes difficult with Asynchronous, getting nonce every time from server becomes expensive for Asynchronous requests.
    – Samy
    Commented Jul 23, 2018 at 7:50
  • (I edited my answer for a bit of extra info) Correct, your web application must be secure against stuff like XSS, etc. Independent from this, your server-side webservice has to check the input and must not process it, if it's invalid. Make sure you avoid undefined states at all time and only process what you can verify is what you expected. "If you expect a number, prepare for users sending arrays of potatoes". I can't say much about your replay attack problem without more details about your application, however this was not your question in the first place.
    – GxTruth
    Commented Jul 23, 2018 at 7:54
  • Adequate security measures are in place to mitigate XSS, CSRF etc. The issue i am trying to find a solution for is, a request being replayed to the server. To address it, i generate a server nonce which is generated at server and returned to the client, and client generates a client nonce for every request, that gets validated to avoid replaying requests. Here using Burp suite to change the client nonce before request reaching server in a Web application is treated as a vulnerability.
    – Samy
    Commented Jul 23, 2018 at 11:59
  • What threat does the client-nonce mitigate? What happens if the client nonce is changed to something random? What is supposed to happen? This might be too much to discuss here as it's not the main question. As I said, the penetration tester might be right or it's a false positive. It really depends on your security architecture.
    – GxTruth
    Commented Jul 23, 2018 at 13:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .