Securing the WAF log against leaks and data exfiltration

It may seem like unnecessary protection, but protecting the WAF log is an important item in preserving personal (PII) or even corporate data of your customers and partners.

Scenario

As your site needs to receive login data (whether customers, partners or suppliers) in POST or JSON calls with username and password, you may experience a leak if the log falls into the hands of a malicious agent that can be an employee or external.

An example I had a few years ago was in a credit consultation system integrated with registration partners such as Experian and Commercial Associations. The system’s error log stored calls with errors in plain text format in the database so that developers and Customer Service could find errors in queries returned.

However, in this log many times the problem was an error in the password and username sent and with that it would be enough to use logic to deduce that the user wrote a letter or typed too many or different to get to know his password. And even worse, in the complete authentication service log it was possible to see the data sent to the client in the GET.

That is, if a partner consults my ID or someone I’m interested in, I could look in the log for the return that was sent on the performance of this person’s credit services without it being logged anywhere since I accessed the log directly.

Now in Azure we can leave this in the past since we no longer need to keep programmatic logs since it stores everything in Log Analytics. But we still have a log where any security operator can use a KQL and see the data, even use a valid user to query data in the system.

Solution

At the time we noticed this problem, the solution had to be manual, programmatically removing the recording of the log for user and password in the functions, in addition to masking Personal and Customer ID. But obviously this was not a definitive solution, as the WAF and IIS log would still hold the raw data.

Now in Azure WAF it is possible to create masking rules for the log, that is, I will be able to identify the data in JSON and POST that I need to protect and prohibit from being used in KQL queries.

Settings

In WAF policy properties use “Sensitive Data” menu to access log scrubbing  like my setup below:

In my example I used the parameters and variables that are used by my developers to identify user, password, contract number and customer ID. 

Here you could add ID or other documents that are received and sent arguments. Below is the list of variable types that can currently be masked:

Except for the IP Address, all other types allow the option “Equal” and “Equal any”, where the first allows indicating named information and the second masks whatever the content of the selected item is. In the case of “Equal any” it is important to remember that it will encrypt all variables of that format, which could be bad for future debugging.

Reference

Microsoft has already released the documentation for the feature on Learn, so use the  Azure WAF – Masking Sensitive Data – Microsoft Community Hub announcement