Web Authentication Mechanisms

HTTP Basic Access Authentication

The basic access authentication described in RFC 7617 uses the HTTP Authorization header to send access credentials on each request. These are sent in a base64-encoded user:password format. For security neophytes, it should be noted that setting a message in an encryption is very different from encrypting its contents, since the reverse process can be performed at any time in order to obtain the credentials without the need for a key.

Although the mechanism is available natively in many web servers and has its use cases, not everything is beneficial.

The main disadvantage comes from the need to send the username and password in each request made to the web server. This forces the application that sends it to know the credentials of the user for which the action is performed.

Another drawback associated with the use of APIs with this authentication, would come from the change of user credentials, since these should be re-saved in all the places from which actions are performed on their behalf. If the update did not occur, then the web application would refuse access to it, as the credentials would be invalid until they were updated.

Session token authentication

In session token authentication, commonly known as session authentication, a token associated internally with a user is generated. This token usually also has a set expiration date.

Example:CS5Vz46HGauRewAV5ulH0EznS

This token is sent and received in each HTTP request. When the server receives it, it looks for the existence of a user associated with it and proceeds to perform actions on its behalf.

The session token is usually sent as a cookie to take advantage of the nature of cookies, since by default they are sent on each request to the same domain by the web browser in question.

Another advantage of cookies as session token storage is that in the event of an XSS vulnerability, session tokens are protected from being captured by the httpOnly attribute of cookies. This is because when the HttpOnly attribute is specified in a cookie, it is no longer accessible via javascript.

The following screenshot corresponds to a WOCU development server where you can see the use of the HttpOnly flag.

A possible improvement would be to force in those installations that have HTTPS connection in production (should be all of them), the secure flag that forces the cookie can only be transmitted over HTTPs.

The use of session cookies can lead to CSRF type of attacks, but if we look at the WOCU forms we can see that they all have, or should have, protection against CSRF, since it is inherently given from the set of technologies we use in its development.

If the session token were to be leaked, either through a man in the middle attack on an insecure connection, physical access to the computer, social engineering or any other technique, it could be used to impersonate the legitimate user for the duration of the session.

Possible steps which would improve the security of the session:

• • Use of secure and httpOnly flags on sensitive cookies in production deployments.
  • Force all production deployments to use HTTPs with valid certificates.
  • Invalidation of the session if it is used from two different IP addresses or from two different User-Agents.

A User-Agent is the signature of the web browser with which we communicate. Our web browsers send in each HTTP request a header indicating the application that is making the request. We can visualize the headers sent either by using a network traffic analyzer such as wireshark, an auditing tool such as Burp or ZAP or by viewing the requests made by our browser directly from the network tab of the development tools.

Other applications make use of the Authorization header to send the authorization credentials or the exchange token when they are needed. However, if this token is injected in the requests made by another browser, we would have the same casuistry as with the sessions, a user could perform actions on behalf of another but with the additional problem that we lack the protections that the attributes of the cookies provide. This means that the application's access token could be leaked in the event of an XSS vulnerability, to name just one of the cases

Authentication by the application token

The session is a way of providing a status to the HTTP protocol. Associated with the session identifier, it is possible to temporarily store additional information about the user to which it is bound. There are times when it is not necessary to store a state of the interaction with the application and you simply want to perform actions. In addition, obtaining a session token requires prior authentication, which in the case of automated applications would mean saving credentials on the one hand and having to manage the necessary authentication processes on the other.

For this reason, many platforms allow the generation of an access token that must be stored securely and that will allow access to the resources of the user to which it is associated, as if it were a session. Some applications restrict the permissions of the access token generated at the time of its creation. Although expirations can be implemented, an application access token generally does not expire and is always the same (not to be confused with the resource access authorization token generated by an OAuth provider, which is different each time it is generated or renewed). Like the session token, if this token were to suffer a leak, the attacker who has it would be able to perform the actions provided by the token.

Although it does not have to, this token is usually sent in the Authorization header. A use case would be that of, for example, Linode, which allows the generation of application tokens to make use of its API and deploy machines in the cloud.

In this scenario, an interesting security measure to adopt would be to restrict the use of the generated application token to an IP address whenever possible.

There are other types of token such as JWT; which has the information in clear cryptographically signed inside the token itself to prevent tampering. However, the explanation and uses of these are beyond the scope of this article.

The issuance of tokens, which are a mechanism for identifying a user to an application, is preceded by an initial authentication. This initial authentication is the one used for token generation and is a challenge whereby the user must prove to be who he claims to be. Ideally the initial challenge should provide 3 elements to prove the user's identity.

• • • Something the user knows
    • Something the user owns
    • Something the user is

These three elements can be translated as follows:

• • • Password or secret information that only the user knows.
    • Security device, digital certificate, sms code, etc.
    • Biometric elements

Each element provides an additional layer of security and although not all of them can be applied in all occasions, it is advisable to strengthen the identification challenge by using some of the following techniques:

• • Evasion of brute force attacks through the use of captchas.
  • Notification of users of attempted logins along with their source IP addresses and the User Agent used at login.
  • Notification of successful logins.
  • Detection of improper logins by comparing the geographic locations from which a user typically logs in with that of the login
  • Detection of access anomalies by comparing the devices from which he/she typically accesses.
  • Disabling autocomplete on forms so as not to leak data on shared computers.
  • Establishment of secure password policies: https://www.incibe.es/sites/default/files/contenidos/politicas/documentos/contrasenas.pdf

Pro TIP:

Aunque consigamos proteger nuestro reto, esto no nos exime de las acciones que un atacante pueda realizar a nuestros usuarios. Un sistema es tan fuerte como su eslabón más débil y si nuestros usuarios cayesen en un ataque de phishing, podrían filtrar sus credenciales a un cibercriminal sin saberlo. Muchas páginas de phishing realizan una redirección al sitio web original, después de obtener los datos que desean. Esta acción a veces pasa desapercibida para el usuario que inicia sesión en el sitio web original y accede a su cuenta sin darse cuenta de que antes estaba introduciendo sus credenciales en otro sitio.

La redirección al sitio original se puede hacer de diversas técnicas. En algunas de ellas el navegador web de la víctima enviará la cabecera Referer apuntando al sitio que contiene phishing desde el que se ha realizado la redirección. Monitorizando las cabeceras de Referer que envían los navegadores web, podemos encontrar sitios fraudulentos que redirijan a la plataforma que se desea proteger.