New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amélioration de la gestion des reverse proxy (X-Forwarded-For). #13

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@otetard

otetard commented Oct 27, 2014

Ajout d’un nouveau define, _REVERSE_PROXY, qui permet d’indiquer si l’installation de SPIP se trouve derrière un relai inverse. Dans ce cas, on récupère l’adresse IP du client via l’en-tête HTTP X-Forwarded-For et on se considère en HTTP ou HTTPS selon l’en-tête X-Forwarded-Proto.

La fonction url_de_base() est aussi modifiée pour éviter d’intégrer le port serveur du serveur si l’on se trouve derrière un relai inverse.

Au final, les define suivants sont ajoutés :

  • _REVERSE_PROXY (boolean) : indique si l’on se situe derrière un relai inverse.
  • _REVERSE_PROXY_HEADER : définir le nom de l’en-tête indiquant l’adresse IP du client (habituellement, X-Forwarded-For).
  • _REVERSE_PROXY_PROTO_HEADER : définir le nom de l’en-ête indiquant le type de protocole utilisé par le client (habituellement, X-Forwarded-Proto).
Amélioration de la gestion des reverse proxy (X-Forwarded-For).
Ajout d’un nouveau define, ``_REVERSE_PROXY``, qui permet d’indiquer
si l’installation de SPIP se trouve derrière un relai inverse. Dans ce
cas, on récupère l’adresse IP du client via l’en-tête HTTP
``X-Forwarded-For`` et on se considère en HTTP ou HTTPS selon
l’en-tête ``X-Forwarded-Proto``.

La fonction ``url_de_base()`` est aussi modifiée pour éviter
d’intégrer le port serveur du serveur si l’on se trouve derrière un
relai inverse.

Au final, les define suivants sont ajoutés :
  - ``_REVERSE_PROXY`` (boolean) : indique si l’on se situe derrière
    un relai inverse.
  - ``_REVERSE_PROXY_HEADER`` : définir le nom de l’en-tête indiquant
    l’adresse IP du client (habituellement, ``X-Forwarded-For``).
  - ``_REVERSE_PROXY_PROTO_HEADER`` : définir le nom de l’en-ête
    indiquant le type de protocole utilisé par le client
    (habituellement, ``X-Forwarded-Proto``).
@Fil

This comment has been minimized.

Contributor

Fil commented Oct 27, 2014

de mon côté j'installe bien SPIP derrière un varnish, mais j'ai le mod_rpaf qui fait ça pour moi au niveau d'apache, ça me semble bien plus safe (et ça évite de bidouiller).

Par ailleurs quand tu écris "La seule source d’information fiable est l’adresse la plus à droite, qui correspond au dernier relai traversé.", ce n'est pas exact : c'est même un problème si jamais quelqu'un essaie de t'"attaquer" en parlant directement à apache et en lui envoyant un faux IP dans ce champ. Il faut donc en plus contrôler l'IP source réel (ce que fait mod_rpaf).

@otetard

This comment has been minimized.

otetard commented Oct 28, 2014

de mon côté j'installe bien SPIP derrière un varnish, mais j'ai le mod_rpaf qui fait ça pour moi au niveau d'apache, ça me semble bien plus safe (et ça évite de bidouiller).

Merci, je ne connaissais pas mod_rpaf. Je viens d’y jeter un coup d’œil, c’est parfait pour gérer de manière fiable l’adresse IP du client via l’en-tête X-Forwarded-For (d’ailleurs, à partir de la version 2.4 d’Apache HTTP Server, il est possible d’utiliser mod_remoteip pour cela).

Certains forks du module gèrent aussi la partie protocole, via l’en-tête X-Forwarded-Proto (mais ne seront probablement jamais intégrées dans Debian, donc je vais éviter de les utiliser). Du coup j’ai rajouté ce code dans mon fichier mes_options.php :

if(strcasecmp($_SERVER["HTTP_X_FORWARDED_PROTO"], "https") == 0) {
  $_SERVER['HTTPS'] = "on";
  $_SERVER['SERVER_PORT'] = 443;
}

Cela permet à la fonction url_de_base() de retourner la bonne adresse quand le serveur frontal est en HTTPS, mais que le SPIP est derrière en HTTP.

Par ailleurs quand tu écris "La seule source d’information fiable est l’adresse la plus à droite, qui correspond au dernier relai traversé.", ce n'est pas exact : c'est même un problème si jamais quelqu'un essaie de t'"attaquer" en parlant directement à apache et en lui envoyant un faux IP dans ce champ. Il faut donc en plus contrôler l'IP source réel (ce que fait mod_rpaf).

Oui, bien sur, c’est bien pour ça que dans la proposition de correctif, je passe par un define pour indiquer si l’on se trouve derrière un RP (et je considère alors que toutes les requêtes passent par le RP). Je suis bien d’accord, mod_rpaf ou mod_remoteip font ça bien mieux que ce bout de code ;).

Je vais donc pouvoir fermer cette demande.

@otetard otetard closed this Oct 28, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment