SSL, TLS et OpenSSL

SSL c’est l’acronyme de Secure Socket Server [ssl]. En version 3 depuis 96 il a en fait été aujourd’hui remplacé par TLS [tls] Transport Security Layer en version 1.2 [rfc5246] depuis 2008 mais a connu une version 1.3 [rfc8446] dernièrement en 2018. Malgré cette évolution, par abus de langage, tout le monde continu d’utiliser le terme SSL.

Mais qu’est ce que SSL?

SSL/TLS est un protocole permettant la sécurisation d'échange réseau à un niveau applicatif (par opposition à une sécurisation qui aurait lieu à un niveau réseau comme avec Ipsec [Ipsec] mais on y reviendra)

Massivement utiliser pour le web en permettant la déclinaison de [http] en [https] ou [ftp] en [ftps] (attention à ne pas confondre avec sftp qui est un ftp dans ssh [sftp-ssh]), le protocole propose de compléter le protocole à sécuriser en y ajoutant ses propres échanges.

CSRF

Je ne suis pas coutumier d'article sur des sujets concernant le FrontEnd car honnêtement, les technologies web ne me passionnent pas vraiment étant plus familiarisé avec celle du BackEnd.

Cependant, ça serait une erreur de ne pas s’intéresser a tout, surtout que l'on trouve dans les concepts du front des choses plutôt intéressantes et des préoccupations propres a elle qui ne peuvent qu'enrichir la compréhension du fonctionnement des applications d'entreprises actuelles.

Ainsi aujourd'hui on va s’intéresser à un concept propre au front et à la sécurité: le CSRF.

Le CSRF ou Cross Security Request Forgery [1] est une faille de sécurité visant à faire réaliser une action malveillante et non souhaité à un utilisateur.

Explications [2]

Cette faille part du principe que vous, être malveillant, connaissiez des urls spécifiques d’un site permettant la réalisation d’action d’administration via des GET ou des POST. Vous n’avez pas les droits adéquats pour réaliser ces actions, mais vous savez qui peut les faire. L’exploitation de la faille consiste, par un quelconque moyen (un mail avec des chatons par exemple), à inciter cette personne à cliquer sur ces urls pré-paramétrés pour réaliser ces actions à son insu.

Pour éviter cela, il existe une solution: le jeton (ou token). L’idée est d’associer (au moment de la réponse à un GET initial) à chaque éléments réalisant une requête une valeur auto-générée et aléatoire qui sera repoussée au serveur afin d'être authentifiée et validée.

Ce faisant, il est alors impossible de réaliser une requête quelconque sans ce token, ceci permettant alors de s’assurer que pour que l’action soit valide, il faut que l’utilisateur l’ait réalisé en ayant eut le jeton préalablement, invalidant alors la possibilité d’utiliser la faille CSRF.

Alors si ca vous a paru compliqué, ne vous inquiétez pas, la plupart des frameworks actuels tels que Spring avec Thymeleaf [3], [4] implémentent déjà des tokens pour se parer à la faille CSRF. Ceci existe même aussi directement dans les serveurs d’applications, comme avec Welogic [5].

Références

[1] https://fr.wikipedia.org/wiki/Cross-site_request_forgery
[2] https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf
[3] https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html
[4] https://www.baeldung.com/spring-security-csrf
[5] http://weblogic-wonders.com/weblogic/2016/04/29/prevent-csrf-attack/