|License Type||SaaS & On-Premise|
|Main Product Category||Ruby Agent|
How exactly does the Ruby agent block attacks?
The Contrast Agent throws a Contrast::SecurityException for our rules. The exception–which extends the core ruby StandardError class–is thrown when the rule criteria is triggered which then prevents any further execution of the application for that request.
Contrast Security’s Ruby agent is based on a Ruby-standard technology called Rack. Rack is a protocol for middleware that takes an HTTP request, optionally acts on the request and then passes it to the next layer in the stack. Once the response is generated each layer in the Rack stack then has an opportunity to inspect and, optionally, modify the response body, response headers, and HTTP status before it is sent back to the client.
Ruby on Rails and Sinatra are both Rack-based technologies where each layer is responsible for handling a specific detail of a request (e.g. parsing a URL query string into parameters). The Ruby agent adds a Rack layer that inspects user input (e.g. the request body, parameters and request headers) and stores references to those that look like possible attack vectors. Then, as the Ruby on Rails layers of the Rack stack run, the agent checks potentially unsafe operations (e.g. file writes for the Path Traversal rule, or database queries for the SQL Injection rule) and if the suspicious inputs are seen at that point (and the specific rule is in “BLOCK” mode) the Contrast::SecurityException is thrown before that operation takes place. A message is simultaneously sent to the Contrast Ruby service which is then forwarded to Contrast Teamserver for display.
“BLOCK AT PERIMETER” rules do not wait to check for potentially unsafe operations. If the user input looks like a possible attack vector the Contrast::SecurityException is thrown at that point. This happens before any subsequent layers of the Rack stack are allowed to run. It may result in many false positives.
After all the layers of the Rack stack have run and the suspicious user input is not seen in a vulnerable operation then no Contrast::SecurityException is thrown but the agent still reports to Teamserver as a “PROBED” event.