false positive code injection points

[r23j5a]

Messages from the scan in the form of

Issue detail  
The application appears to evaluate user input as code.  
It was instructed to sleep for 0ms, and a response time of 1516ms was observed.
It was then instructed to sleep for 15062ms, which resulted in a response time of 15062ms. 
This was re-confirmed six times to reduce false-positives  

 Please report any false-positives to https://github.com/albinowax/ActiveScanPlusPlus

appear often in my scans. I don't think it's even possible to sleep and measure something of a network with a ms precision (sleep for 15062ms, which resulted in a response time of 15062ms.), so the message itself could be used to filter out false positives.

[albinowax]

This does not look like a false-positive - otherwise it wouldn't have survived six confirmations. have you tried replicating the behavior in the repeater? Do your normal requests often have ten-second response times?

It's not super relevant but you can actually measure below 1ms over the network - https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work

That said, it looks like there's a bug in the report text - it shouldn't say "15062" twice. I'll push a fix for this.

[r23j5a]

right https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work - awesome work! 🙌

But yes, I've tried replicating behavior in the repeater, both using the time as mentioned in the report(s) and random (smaller/larger one). Not sure what to make of it though. One thing is to measure something with 1ms precision, but imho its a different thing to sleep for a given amount of time (not guaranteed to be exact) and measure the same exact response time (I obviously should have looked through the source code to get a better understanding 😳).
I may be (and happy to learn if I am) totally wrong here.

[albinowax]

It's not actually sleeping for the exact specified response time - that's a bug in the report text. If you look at the request attached to the report, you'll see the real payload, which tries to trigger a 4-second delay (4000ms).