Request enrichment helps identify user data | Fastly

Data leaks that include usernames and/or passwords are unfortunately more and more common. Attackers know that many users often leverage the same password across different sites, and by cross-referencing stolen lists, they can successfully match login information in order to perform account takeover (ATO) attacks that extend far beyond the original website that leaked the data. Just this month, the largest known password list ever was disclosed, compromising millions of user accounts. However, by using an enriched request passed through Fastly, you can keep tabs on if user logins are using known compromised credentials.

A recently published Developer Hub tutorial on enrichment shows you how to add data from a third-party API to the requests that pass through Fastly. The tutorial uses the API for Have I Been Pwned, an open-source site that allows you to check if a given username or password is part of a known compromised database, as an example. By adding a `fastly-password-status` header to the request, the origin server determines what HIBP's verdict is on the content of the request.

Our edge cloud leaves it up to your origin to decide what to do with that information, but what if you're running our next-gen WAF (formerly Signal Sciences) on your origin? Can you use the additional data on the request as a signal in the WAF? Why yes you can, and today I’ll show you how to connect these together.

Your Fastly configuration

Requests to login endpoints

First, you’ll log into your next-gen WAF management console in order to verify that the requests being routed through the Compute service are being checked for known compromised passwords. The rule below will check if the header `fastly-password-status` is present in the request. This header should be added to every request if the password is known to be compromised or not. You’ll know that the password was checked by adding a signal when the header `fastly-password-status` is present.

Requests with known compromised passwords

You can check to see if the password is known to be compromised based on the request header key/value pair, as mentioned in the Developer Hub tutorial, by building an additional rule that checks if the header `fastly-password-status` exists and has the value `compromised-credential`. If this header key/value pair exists, then you know that the configured Wasm service identified a compromised password.

Looking at a scenario

With this configuration in place, you have a lot more context on a potential attack. For example, an elevated number of login attempts, failed logins, and compromised-credential signals for requests during a given time series might indicate a brute force account takeover attempt.

Here’s where this data allows you to make more informed decisions. For this demo, I created the “Compromised Passwords” card with the signals “checked-pw” and “compromised-pw”. During the time series and when combined with the Login card, I can see that there were numerous login attempts and failures. However, there were no successful logins. The majority of the log in attempts during this time were using known compromised passwords.

From this information, I can tell that there is a high chance that my login endpoint is under a brute force login attack.

Taking more informed actions

With our next-gen WAF, you can take a thresholding-based approach to mitigating abusive behaviors. Below is a rate limit rule that will block requests with the signal “All Requests” from an IP after a limited number of attempts with compromised passwords.

This type of mitigation will allow your security or fraud prevention team time to investigate the behavior and determine if there is a single user being targeted, a small set of users that are being targeted, or if this is a larger password spraying attack against many different users. 

An example response by the security team could be if the attack is against a small set of users, to ensure that those specific users are using strong, uncompromised passwords and two-factor authentication. And if there are any successful logins from those IPs, to terminate those user sessions and force password reset.

Conclusion

By feeding data from the Have I Been Pwned API into our next-gen WAF, you gain visibility into the volume of known compromised passwords being attempted on your site. This information may be used to help mitigate account takeover attacks and better secure your customers’ accounts. This is just one example of what you can do with enriched requests and Fastly. Have other examples? Tweet us!