Session

The 'session' configuration has the following format:

"session": {
  "in": "",
  "key": ""
}

When a user authenticates, a session is being established. When a decoy triggers, it is important to know if a user is authenticated as this can denote a user impersonation.

However, there are different ways for an application to deal with a session token. Typically, the session token is provided as a cookie or as a request header, but as this depends on the protected application, our solution needs to be told where the information can be found. This configuration is meant to deal with this concern.

In

The in key defines where to look for the session token. Supported values are 'cookie' and 'header'.

Key

The key key is used to specify the name of the cookie or request header where the session token is stored.

If the 'session' is configured, then if a session token is found 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 session token is valid or not. This means that if an attacker sends a forged token, the content of this token will be displayed in the alert even if the session is invalid.

For the demo application, the session token can be configured as follows:

"session": {
  "in": "cookie",
  "key": "SESSION"
}