web-dev-qa-db-fra.com

Écraser les cookies dans htaccess

Je gère un site Web dans un environnement d'hébergement partagé (LAMP) assez bon marché: techniquement, dans ce contexte, tout ce que je peux faire est de modifier un ou plusieurs fichiers htaccess.

Peut-être qu'à des fins d'équilibrage de la charge, l'hôte envoie deux cookies non sécurisés.

Est-il possible de définir l'indicateur Secure sur les deux cookies à partir d'un fichier htaccess en écrasant leurs valeurs d'origine?

htaccesscookie
1
user93110

tl; dr Vous ne pouvez probablement rien faire pour influencer le cookie défini par Host ​​"à des fins d'équilibrage de la charge".

Cookie défini par le serveur d'application

Si le cookie est défini sur votre serveur d'applications, vous pouvez éventuellement intercepter la réponse et remplacer l'en-tête de réponse _Set-Cookie_ HTTP.

Par exemple, sur la base de ne réponse sur StackOverflow , les éléments suivants ajouteraient inconditionnellement l'indicateur Secure lors de la définition du cookie "MYCOOKIE" à l'aide du mod_headers d'Apache:

_Header always edit Set-Cookie ^(MYCOOKIE=.+) "$1; Secure"
_

Ou, en fonction de autre réponse sur ServerFault , le texte suivant utilise un lookahead négatif pour vérifier d'abord que la Secure n'est pas déjà définie dans le cookie:

_Header always edit Set-Cookie "(?i)^(MYCOOKIE=(?:(?!;\s?secure).)+)$" "$1; Secure"
_

Cookie défini par proxy/équilibreur de charge

CEPENDANT, si le cookie est défini par un équilibreur de charge/proxy hors de votre contrôle, la méthode ci-dessus ne fonctionnera probablement pas. Et toute tentative de remplacement du cookie peut elle-même être remplacée par le serveur proxy, en fonction du moment où le proxy définit le cookie.

Vous pouvez essayer quelque chose comme ceci en utilisant mod_rewrite, mais sachez que vous devrez également définir manuellement les propriétés domain et chemin (et durée de vie ) des parties du cookie identiques à celles définies par hôte (par exemple, en vérifiant l'en-tête de réponse HTTP initial _Set-Cookie_ que vous voyez dans le navigateur), sinon il ne sera pas remplacé le même cookie. Par exemple:

_RewriteEngine On

RewriteCond %{HTTP_COOKIE} (MYCOOKIE)=([^;]+)
RewriteRule ^ - [CO=%1:%2:.example.com:1440:/:secure]
_

_%1_ est une référence en arrière au nom du cookie (par exemple, MYCOOKIE) dans la directive RewriteCond précédente. Et _%2_ est la valeur correspondante. _.example.com_, _1440_ et _/_ sont les domaine, durée de vie (en minutes) et RL-path = respectivement du cookie que vous essayez de définir et que vous devrez définir manuellement.

Cependant, comme mentionné ci-dessus, cela ne peut rien faire, car le proxy peut simplement écraser cela.

Référence:

0
MrWhite