experience using SolidWall to protect the positive model

When we deployed the SolidWall WAF web application attack protection system for our customers, we had the idea to see how attacks on a test service, for example, the Juice Shop simulator, an application that deliberately implemented the most common vulnerabilities, would be detected and blocked.

We wanted to make an analysis of all the simple riddles (with one star) of the Juice Shop, but taking into account the screenshots, only one fit into the article format: “Zero Stars Give a devastating zero-star feedback to the store. Improper Input Validation. It is interesting in that it is difficult to defend against it with a negative model (signatures), but it is easy – with a positive model, well developed in SolidWall.

Juice Shop deployed easily according to instructions https://hub.docker.com/r/bkimminich/juice-shop#docker-container

Setting up Solid Wall. First, filter nodes, publish the application in the nginx config: /etc/solidwall/nginx/sites-enabled/juiceshop

sudo solidwall-nginx test

sudo solidwall-nginx reload

Next, add the application in the SolidWall web interface:

In our case, there is a balancer in front of the filtering nodes. Therefore, within the framework of the “troika”, we will define the application only by name.

The traffic went, the application was correctly defined.

So, let’s start testing

Objective: Give a devastating zero-star feedback to the store. The classic task of validating input data.

We exploit

The solution is extremely simple: we create a request with the desired body (JSON), for example, in BurpSuite Repeater.

We protect

Now the question is how to protect yourself at the SolidWall level? Obviously, you need to introduce validation of input values.

We find the transaction we need in the SolidWall log.

First of all, we need to make sure that the request parsing on the WAF side is carried out correctly. We go to the “Request” section. As we see below, the structure is fully consistent with the request that we see in the properties of the transaction. This means that it will be parsed correctly, and you can move on to the rules.

We return to the transaction, go to the “Action” tab and click the “Create an action based on this transaction” button.

Go to the action section and see an action like this:

url->path->0 == api
url->path->1 == Feedbacks
url->path->2 ==
method == POST
body->rating, body->captcha, body->captchaId, body->comment (any value)

Editing the created action:

*You need to click on the top pencil, noted in the picture*

Parameters (from JSON) appeared when creating a rule from a transaction, but in the “Model” field it was indicated “by default”. We change it for each of the parameters and save the changes.

Checking…

Wrong rating

Correct Rating

Wrong captcha id type

Wrong comment

In general, it is difficult to throw incorrect data into the string type … it simply converts the same numbers into strings. Let there be another nested JSON: