0

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.

Samy
  • 101
  • 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? – PortSwigger Jul 23 '18 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 Jul 23 '18 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. – PortSwigger Jul 23 '18 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 Jul 23 '18 at 13:45
  • @Samy is the request behind authentication? – McMatty Jul 24 '18 at 03:34
  • @McMatty Yes a user level session is created after authentication and on every request user session is validated. – Samy Jul 24 '18 at 03:38
  • The tools doesn't matter, what you need to assess is the risks : what are the impact of the vulnerabilities shown (cost), what is the probabilityit happen, what would it cost to fix. Then you make a decision based on that. In all honesty, that post feel like "There is a security vulnerability, look when I hit F5 the same request get processed again". For me that's the standard way of F5, furthermore the server depending of how it process the information might not give the same result (exemple : is you use a version number on your datas for modification). – Walfrat Aug 22 '18 at 14:33
  • @Walfrat On F5 requests are reposted and there are enough measures to avoid processing the same request again. That is directly from client’s browser without intercepting requests. In this case requests are intercepted and modified using burp suite. – Samy Aug 22 '18 at 14:48
  • I know, but the idea is basically the same.Furthermore, if you have a RESTFULL API, it is expected and supported that two exact requests must be processed and give the same result (with the right http verb, I think it is PUT and not POST). The most important part of my comment was the first : security is like any risks, it must be handled by a proper Risk Management process, unless you're working on a state-software extremely secret things, you won't have the money and time to fix everything and not everything need necessary to be "fixed". – Walfrat Aug 22 '18 at 14:51

1 Answers1

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.

GxTruth
  • 963
  • 6
  • 9
  • 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 Jul 23 '18 at 07: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 Jul 23 '18 at 07: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 Jul 23 '18 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 Jul 23 '18 at 13:55