Sécurité et contrôle de la cache!

Plusieurs attaques requièrent l’utilisation de la cache d’un fureteur. À sa plus simple expression, il est donc possible pour un malfaiteur d’accéder à ces données, si elles ne sont pas protégé correctement.

Pour adresser ce point de sécurité, il est donc critique de retirer toute forme de cache possible. Que celles-ci se trouvent dans votre fureteur ou par le fait même, dans votre serveur web et même vos autres outils de sécurité réseau.

Contrôler la cache dans sa solution avant tout

Depuis plusieurs années, je remarque dans les solutions observé l’utilisation de méta données dans les pages web, par exemple :

<meta http-equiv="cache-control" content="no-cache">

<meta http-equiv="expires" content="0">

<meta Http-Equiv="pragma" Content="no-cache">

À première vue ceci semble parfait, mais cette solution possède un grave manquement… Elle ne touche pas du tout vos équipements réseau!

Ceci veut donc dire que le fureteur pourra ultimement être rafraîchie, mais que des données pourront toujours se trouver dans vos gestionnaires de cache, balanceurs et autres équipement.

Aussi, il est fort possible que certaines de ces commandes ne fonctionne pas avec plusieurs fureteurs se trouvant dans le marché actuel.

Pour répondre à ces besoins, il faut donc descendre d’un niveau et adresser les fureteurs ainsi que les équipements.

Réduire la cache

Pour solutionner en profondeur, ma recommandation est simple; directement attaquer les entêtes HTTP.

L’utilisation d’entête garantie qu’au minimum, tous les équipements dans la chaîne répondant aux normes web devront suivre les clauses indiqué, par exemple celles-ci:

Cache-Control: no-cache, no-store, must-revalidate

Pragma: no-cache

Expires: 0

Mais comme nous adressons les entêtes elles-mêmes, il faut donc travailler au niveau du protocole. Il est certain que pour différents langages il existe différentes solutions, mais voici deux bons exemples pour vous. Ceci devrait vous permettent de facilement solutionner vos enjeux dans le code de votre choix. Mon but est simple, vous mettre la puce à l’oreille! Voici donc pour PHP et java.

header("Cache-Control: no-cache, no-store, must-revalidate");

header("Pragma: no-cache");

header("Expires: 0");

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");

response.setHeader("Pragma", "no-cache");

response.setHeader("Expires", "0");

Idéalement, si vous voulez aller plus loin et “doubler” la protection, il ne faut pas se gêner et introduire le contrôle directement dans votre serveur web comme ceci dans Apache (fichier .htaccess) :

<IfModule mod_headers.c>

    Header set Cache-Control "no-cache, no-store, must-revalidate"

    Header set Pragma "no-cache"

    Header set Expires 0

</IfModule>

Métadonnées vs entêtes HTTP

La puissance des entêtes est fort simple : celles-ci sont présentées dès la connexion http, avant l’apparition de la page HTML elle-même; et ce à travers chacun des équipements dans votre réseau et vos solutions.

Cette approche nous permet donc de limiter les dommages potentiels et surtout, ne pas se limiter au fureteur en question! Surtout si c’est celui d’un malfaiteur…

De plus, utiliser les entêtes éliminent les différences que chacun des fureteurs possèdent. Comme les utilisateurs utilisent des mobiles, des laptop et autres équipements pour se connecter, les entêtes sont indifférentes  et donc renforce le tout devant les fureteurs.

Suivant mon expérience, il ne faut donc jamais faire confiance <meta http-equiv> tags et toujours renforcer via notre code et directement au niveau du serveur web.

%d bloggers like this: