Timeline for Modifying requests using Burpsuite considered to be valid security vulnerability?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21, 2018 at 10:00 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Sep 21, 2018 at 9:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 22, 2018 at 14:51 | comment | added | Walfrat | 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". | |
| Aug 22, 2018 at 14:48 | comment | added | Samy | @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. | |
| Aug 22, 2018 at 14:33 | comment | added | Walfrat | 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). | |
| Aug 22, 2018 at 9:00 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jul 24, 2018 at 3:38 | comment | added | Samy | @McMatty Yes a user level session is created after authentication and on every request user session is validated. | |
| Jul 24, 2018 at 3:34 | comment | added | McMatty | @Samy is the request behind authentication? | |
| Jul 23, 2018 at 13:45 | comment | added | Samy | @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. | |
| Jul 23, 2018 at 13:30 | comment | added | PortSwigger | 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. | |
| Jul 23, 2018 at 12:56 | comment | added | Samy | 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. | |
| Jul 23, 2018 at 12:52 | comment | added | PortSwigger | 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? | |
| Jul 23, 2018 at 7:45 | answer | added | GxTruth | timeline score: 1 | |
| Jul 23, 2018 at 6:55 | review | First posts | |||
| Jul 23, 2018 at 13:00 | |||||
| Jul 23, 2018 at 6:55 | history | asked | Samy | CC BY-SA 4.0 |