Open tarunKoyalwar opened 5 months ago
Since the whole issue appears to be the mix of asynchronous/periodic polling + callback, I think we should change the approach we are using and try to make it synchronous.
For example we can introduce a shared event bus as a start, where interactsh publishes upon receiving data to queue with a specific subject (for example correlation-id
that identifies a group uniquely), the caller thread will put itself in wait mode on this specific id:
Before:
request.options.Interactsh.RequestEvent(...)
After:
...
select {
case eventbus.WaitFor(xxx.CorrelationId):
// actual code from request.options.Interactsh.RequestEvent(..)
case time.After(interactsh_cooldown):
}
...
Unless I'm missing something this would fix the following issues:
pkg/protocols/common/interactsh/interactsh.go
in deferred mode with the need of shared atomic boolean or modify the structure from different components
Nuclei version:
main | dev
Current Behavior:
In Nuclei , we currently have two locations where results are stored/written
tmplexec
packageprotocols/common/interactsh
packagethis issue is only related to cases where interactsh is used in template and due to fallback behaviour we have for it
fallback behaviour
interactsh-cooldown-period
=> this is global cooldown period of interactshResult Event Cache
=> for all templates that uses oast we store current event (req/resp) and other template metadata related to that specific request in gcache . and this result event cache is used when interaction is recieved later on say after 10secAnything else: