View on GitHub

Let me secure that for you!

How to use Virtual Patching to protect your site

Blocking Requests

Sometimes your rule will decide to block a request, redirect the request to a different page, or otherwise avoid sending the request to the original web page.

Architecture layer: modsecurity

In modsecurity you can specify a disruptive action in the list of actions. In the below example, deny is the disruptive action:

SecRule  REQUEST_FILENAME "@rx /order/details/" \
  "id:11101,phase:1,deny,log,\
  t:none,t:lowercase,t:normalisePath,\
  msg:'Blocking access to %{MATCHED_VAR}'"

If the VARIABLES and OPERATOR match, then the ACTIONS clause of the SecRule will run.

The following disruptive actions are documented in the Reference Manual:

The most common way to block a request is to set the deny or block actions. For maintainability, it is recommended to use block, as that allows the site administrator to specify what should happen in the SecDefaultAction.

or

Architecture layer: node.js proxy

The node.js proxy gives us a few different ways to finish a response prematurely.

proxyRequest.abort();

This aborts the request that was going to be sent to the origin webserver. The client browser will see an unfriendly “ECONNRESET” message in their browser.

response.writeHead(302,
    { Location: '/Order?Security_Violation' }
);
response.end();
proxyRequest.abort();

This will abort the request being forwarded to the origin server, and also write a redirect response back to the client. This allows you to be slightly more friendly by redirecting to a blocking page.

response.writeHead(500, {
	'Content-Type': 'text/plain'
});

response.end('Something went wrong. And we are reporting a custom error message.');

This also aborts the request, but writes a text response back to the browser.