• Guides
• Request Variation Controller

The Request Variation Controller integration is, in fact, two integrations that work together to protect your online assets.

In the response phase, the Hash Generator creates a signed cookie to track the different arguments the user (or the origin) is using across the requests. This cookie will be used for the second integration, the Hash Validator, which checks the number of variations made and blocks access to the origin whenever the user exceeded the maximum number permitted.

Request Variation Controller is a serverless integration available at Azion Marketplace.

Remember, this integration is divided into two. To run it, you have to install the hash generator and the hash validator.

With the help of this integration, a signed cookie can be created or updated, containing details about how many different requests were made in succession to an edge application.

1. Access Azion Console > Marketplace.
2. On the Marketplace homepage, select the search box and type “variation” or browse through the cards to find the two Request Variation Controller integrations.
3. Once you’ve found the Request Variation Controller - Hash Generator and Request Variation Controller - Hash Validator cards, select one to go to the integration’s page.
4. On the integration page, look for the Subscribe for section on the bottom-right corner.
5. Click the Get It Now button.

You’ll follow the same steps to install the second integration.

In both cases, after clicking on the Get it now button, you’ll see a message indicating that your integration was successfully installed.

Once you’ve gotten your integration on Marketplace, it’ll be available at your edge functions list. To use the integration, you’ll have to create a new edge application.

Proceed as follows:

1. On the upper-left corner, select Products menu > Edge Application on the BUILD section.
2. On the listing page of your edge applications, select the one you’ve created to use with the Request Variation Controller integration.
3. On the application page, on the Main Settings tab, locate the Functions switch and turn it on to enable Functions on your edge application.
4. Still on the application page, on the Main Settings tab, locate the Application Accelerator switch and turn it on to enable the Forward Cookies functionality for your application; this will be addressed at the Rules Engine section.
5. Click the Save button.

You’ll receive a message indicating your edge application was successfully updated.

To enable this function, while still on the Edge Application page:

1. Select the Functions tab on the top list.
2. Click the Add Function button.
3. Choose an easy to remember name for your function.
4. On the dropdown function menu, select the Variation Request function.

This action will load the function, showing a form with the function code and, just above it, two tabs: Code and Args. By clicking on the Code tab, you’ll be able to navigate through the code, but won’t be able to change it.

As you have two integrations, you’ll have to configure two Args tabs, one for the response phase and another one for the request phase.

For the response phase, the *Args are:

{
    "cookie_name": "azn",
    "cookie_secret": "1234567890123456",
    "cookie_max_age": 45,
    "args_list": ["http_x_something", "http_x_another_thing",
    "request_body_userid"]
}

Where:

• cookie_name: defines the name of the cookie. The default value is “azn”.
• cookie_secret: defines the key used to encrypt the signed cookie. Due to the encryption algorithm used here, the AES-128, this key must have exactly 16 chars.
• cookie_max_age: define the time for the expiration of the cookie. If you don’t define any time (passing a null value or none value), the cookie will be a session cookie. The default value is 45.
• args_list: defines the nginx list of variables that will be analyzed on the user’s request. Whenever this changes, the count of changes will be increased. These parameters will be used to block or allow the access.

For the request phase, the Args are:

{
"cookie_name": "azn",
"cookie_secret": "1234567890123456",
"max_variation": 6,
"max_unique_variation": 2
}

Where:

• cookie_name: defines the name of the cookie. It must be the same as the one defined at the response phase.
• cookie_secret: defines the secret key for the cookie. It must be the same as the one defined at the response phase.
• max_variation: defines the maximum number of any kind of variation in the parameters.
• max_unique_variation: defines the maximum number of unique variations in the parameters.

This function decrypts the signed cookie and checks to see if any cookie variants have been reached. If they have, a new request header with the name [COOKIE_ NAME]-[VIOLATION TYPE]-[TRUE] will be appended to the request.

Possible violations can assume 3 values:

• All Variations: regardless of whether there are repeated values, it counts the number of times the cookie’s value was altered. For instance, if the cookie value changed from “nothing” to “A” in the first request, “A” to “B” in the second, “C” in the third, “B” to “C” in the fourth, “B” to “A” in the fifth, and finally “A” in the sixth request, the total number of variations would be 5. If the cookie has the default name, the violation header that is added to the request when this violation occurs is http_cookie_name_any_variation_violation.

• Unique variations: counts the number of distinct values that have been assigned to the cookie since its creation. Given that the cookie only had “A,” “B,” and “C” as distinct values, the unique variation for the same example as above would be 3. Assuming the cookie has the default name, when this violation occurs, a violation header called http_cookie_name_unique_variation_violation would be added to the request.

• Signature Violation: when the function is unable to decrypt the signed cookie (for example, because it was signed with a different key or because the cookie was altered on the client side), this violation will be brought about. Assuming the cookie has the default name, when this violation is triggered, the request will have the violation header http_cookie_name_signature_violation added to it.

Still in the Edge Application page, in the Rules Engine tab, you have to configure the rules you want (criteria and behavior) to apply to run your function.

You have to configure the response phase for the Rules Engine.

To do so, follow these steps:

1. Select the Rules Engine tab.
2. Click the New Rule button and select Response Phase.
3. Give an easy to remember name to your rule.
4. Pass the criteria you need to in order to run your integration.
5. On the behavior field, select Run Function from the dropdown menu and then select the Variation Request - Hash Generator function, according to the name you gave it in the instantiation step.
6. Click the Save button.

Now, you have to configure the request phase for the Rules Engine.

To do so, follow these steps:

1. Select the Rules Engine tab.
2. Click the New Rule button and select Request Phase.
3. Give an easy to remember name to your rule.
4. Pass the criteria you need to in order to run your integration.
5. On the behavior field, select Run Function from the dropdown menu and then select the Variation Request - Hash Validator function, according to the name you gave it in the instantiation step.
6. You’ll need a second behavior for the Request Variation Controller function, the Forward Cookies. To add this, click the + button and select the Forward Cookies option from the dropdown menu.
7. Click the Save button.

Done. You’ve successfully instantiated your two integrations and now you’re protected against attackers.

Contributors