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.
Some users will want to see what the
ronin-vulnscommands 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#initializeand 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
AuditEventobjects into some kind ofAuditLogobject, 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
WebVulnwith some kind ofevent_callbackwhich could be passed theAuditEventobjects 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.