You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some users will want to see what the ronin-vulns commands are doing behind the scenes when testing URLs for vulnerabilities. We will need to somehow need to log/save the requests, responses, and what payload was used.
Option 1: logger
A logger object could be passed into WebVuln#initialize and the #vulnerable? methods could use it to write debug messages. This would be the quickest way to expose what exactly is being done, but would mix CLI messages into the web vulnerability classes; I would like to keep all CLI formatting logic in Ronin::Vulns::CLI.
Option 2: instance variables
A quick-and-dirty solution might be to add instance variables to store the payload used, the request, and the response objects.
Option 3: an Audit Event Array
A more data-orientated approach might be to store structured AuditEvent objects into some kind of AuditLog object, which would behave like an Array. This would allow tracking fine grained events and inspecting them with other Ruby code.
Option 4: an Audit Event callback
Instead of storing audit events in a list and inspecting them later, we could initialize WebVuln with some kind of event_callback which could be passed the AuditEvent objects as they are created. This could also be used to convert the event objects into debug messages, or save them to a JSON file, etc.
The text was updated successfully, but these errors were encountered:
Some users will want to see what the
ronin-vulns
commands are doing behind the scenes when testing URLs for vulnerabilities. We will need to somehow need to log/save the requests, responses, and what payload was used.Option 1: logger
A logger object could be passed into
WebVuln#initialize
and the#vulnerable?
methods could use it to write debug messages. This would be the quickest way to expose what exactly is being done, but would mix CLI messages into the web vulnerability classes; I would like to keep all CLI formatting logic inRonin::Vulns::CLI
.Option 2: instance variables
A quick-and-dirty solution might be to add instance variables to store the payload used, the request, and the response objects.
Option 3: an Audit Event Array
A more data-orientated approach might be to store structured
AuditEvent
objects into some kind ofAuditLog
object, which would behave like an Array. This would allow tracking fine grained events and inspecting them with other Ruby code.Option 4: an Audit Event callback
Instead of storing audit events in a list and inspecting them later, we could initialize
WebVuln
with some kind ofevent_callback
which could be passed theAuditEvent
objects as they are created. This could also be used to convert the event objects into debug messages, or save them to a JSON file, etc.The text was updated successfully, but these errors were encountered: