Username

The 'username' configuration has the following format:

"username": {
  "in": "",
  "key": "",
  "value": ""
}

When a decoy triggers, it is interesting to know whether a user is authenticated as this can reveal a user impersonation. The most efficient way to know whether a user is authenticated is to retrieve the session token, as described in the session section. However, in certain cases it is possible to retrieve the actual username of the authenticated user. This can be useful for a few reasons, such as:

• to directly know which user is concerned, instead of having to search for a mapping between the session token and the username in the relevant database
• to possibly verify that the session token is valid, in case the username can be retrieved in the HTTP response of the server (instead of provided by the attacker).

However, just like with the session token, our solution needs to be told where to possibly find this username.

In

The in key defines where to look for the username. Supported values are 'cookie', 'header' and 'payload'.

Key

The key key is used to specify the name of the cookie or request header where the session token is stored. This value is case sensitive. The key value is ignored if the in value is set to 'payload'.

Value

The value key is used to refine what exactly to use as username value. This key is treated as a regular expression. If not specified, it is considered to have a value of '.*' (fetch everything).

If the 'username' is configured, then if a value can be computed when a decoy is triggered, that information will be displayed in the alert. Be careful though: there is no way for the solution to know whether a username value is legitimate or not. This means that if the value is retrieved from the attacker's request, that value will be displayed in the alert even if that value was forged.

For the demo application, the username value can be configured as follows:

"username": {
  "in": "payload",
  "value": "<h2>Welcome (.*?)<\/h2>"
}

There might be pages of the demo application where the username cannot be found. On the other hand, since the username comes from the server response ('payload'), it is way harder for an attacker to forge a fake username for the alert.