question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Unexpected results when manually calling getInteractshService.deregister()

See original GitHub issue

Describe the bug

When manually calling the function Java.type("org.parosproxy.paros.control.Control").getSingleton().getExtensionLoader().getExtension("ExtensionOast").getInteractshService().deregister() I would expect the OAST canaries defined to be reset to allow for a new one to be used, it would appear the code ends early on InteractshService.java#278 if the code returned is not 200.

Steps to reproduce the behavior

  1. Start a interactsh OOB server
  2. Let the client sit for a few days until the interactsh server loses the correlation-id
  3. Call Java.type(“org.parosproxy.paros.control.Control”).getSingleton().getExtensionLoader().getExtension(“ExtensionOast”).getInteractshService().deregister()

Expected behavior

I would expect the de register option to clear the current server payload listed regardless of the returned code from the OAST service.

Software versions

2.11.1

Screenshots

No response

Errors from the zap.log file

[ZAP-ScriptExecutor-Deregiser OAST.js] WARN InteractshService - Error during interactsh deregister, due to bad HTTP code 400. Content: {“error”:“could not remove id: could not get correlation-id from cache”}

Additional context

No response

Would you like to help fix this issue?

  • Yes

Issue Analytics

  • State:closed
  • Created a year ago
  • Reactions:1
  • Comments:12 (11 by maintainers)

github_iconTop GitHub Comments

2reactions
someusername123commented, Oct 13, 2022

@njmulsqb Thank you for the quick bug fix!

1reaction
kingthorincommented, Oct 11, 2022

That’d be great but it’s a bigger issue 😉

Read more comments on GitHub >

github_iconTop Results From Across the Web

Is calling destructor manually always a sign of bad design?
Calling the destructor manually is required if the object was constructed using an overloaded form of operator new() , except when using the ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found