No Branch/Tag Specified
1.8
1.9.1
1.9.2
2.0
2.1
3.0
3.1
3.2
4.0
4.1
4.2
boutons-danger
coquille_doc
debug_ecrire_fichier
dev-sortable
dev/autoloader
dev/hasard_fixe
dev/instituer_ergo
dev/issue_5447_exporter_csv
dev_infos_image
fix/valider_url_distante
fix_issue_5454
fix_modifier_login
issue_4101
issue_4678
issue_4705
issue_4717
issue_4836
issue_4946
issue_5258
issue_5344
issue_5427_bis
master
v1.8.3+b
v1.9.1+i
v1.9.2+f
v1.9.2+g
v1.9.2+h
v1.9.2+i
v1.9.2+j
v1.9.2+k
v1.9.2+m
v1.9.2+n
v1.9.2+o
v1.9.2+p
v2.0.0
v2.0.1
v2.0.10
v2.0.11
v2.0.12
v2.0.13
v2.0.14
v2.0.15
v2.0.16
v2.0.17
v2.0.18
v2.0.19
v2.0.2
v2.0.20
v2.0.21
v2.0.22
v2.0.23
v2.0.24
v2.0.25
v2.0.26
v2.0.3
v2.0.5
v2.0.6
v2.0.7
v2.0.8
v2.0.9
v2.1.0
v2.1.1
v2.1.10
v2.1.11
v2.1.12
v2.1.13
v2.1.14
v2.1.15
v2.1.16
v2.1.17
v2.1.18
v2.1.19
v2.1.2
v2.1.20
v2.1.21
v2.1.22
v2.1.23
v2.1.24
v2.1.25
v2.1.26
v2.1.27
v2.1.28
v2.1.29
v2.1.3
v2.1.30
v2.1.4
v2.1.5
v2.1.6
v2.1.7
v2.1.8
v2.1.9
v3.0.0
v3.0.0-alpha.1
v3.0.0-beta
v3.0.0-beta.2
v3.0.0-rc
v3.0.1
v3.0.10
v3.0.11
v3.0.12
v3.0.13
v3.0.14
v3.0.15
v3.0.16
v3.0.17
v3.0.18
v3.0.19
v3.0.2
v3.0.20
v3.0.21
v3.0.22
v3.0.23
v3.0.24
v3.0.25
v3.0.26
v3.0.27
v3.0.28
v3.0.3
v3.0.4
v3.0.5
v3.0.6
v3.0.7
v3.0.8
v3.0.9
v3.1.0
v3.1.0-alpha
v3.1.0-beta
v3.1.0-rc
v3.1.0-rc.2
v3.1.0-rc.3
v3.1.1
v3.1.10
v3.1.11
v3.1.12
v3.1.13
v3.1.14
v3.1.15
v3.1.2
v3.1.3
v3.1.4
v3.1.5
v3.1.6
v3.1.7
v3.1.8
v3.1.9
v3.2-alpha.1
v3.2.0
v3.2.0-alpha.1
v3.2.0-beta
v3.2.0-beta.2
v3.2.0-beta.3
v3.2.1
v3.2.10
v3.2.11
v3.2.12
v3.2.13
v3.2.14
v3.2.15
v3.2.16
v3.2.17
v3.2.2
v3.2.3
v3.2.4
v3.2.5
v3.2.6
v3.2.7
v3.2.8
v3.2.9
v4.0.0
v4.0.0-alpha
v4.0.0-beta
v4.0.1
v4.0.2
v4.0.3
v4.0.4
v4.0.5
v4.0.6
v4.0.7
v4.0.8
v4.0.9
v4.1.0
v4.1.0-alpha
v4.1.0-beta
v4.1.0-rc
v4.1.1
v4.1.2
v4.1.3
v4.1.4
v4.1.5
v4.1.6
v4.1.7
v4.2.0-alpha
v4.2.0-alpha2
Labels
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
Apply labels
Clear labels
accessibilité
amélioration
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
No Label
accessibilité
amélioration
APIs
authentification
base de données
bug
code généré
compilo
css
divers
documentation
doublon
ergonomie
espace privé
filtres et balises
formulaires
Inscription
installation
invalide
javascript
langues
LDAP
plugin
PostgreSQL
refusé
sécurité
traduction
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
La fonction url_de_base() dans utils.php renvoie une url absolue calculée à partir de $_SERVER['HTTP_HOST']. C'est pénalisant pour des sites SPIP situés derrière un reverse proxy par exemple.
Détaille un peu ?
Statut changé à En cours
Voici un patch qui utilise l'adresse publique du site si on passe par un reverse proxy, celà pourrait-t-il convenir ?
Statut changé à Commentaire
Oui mais non : HTTP_X_FORWARDED_HOST peut provenir d'un proxy externe (celui d'AOL par exemple)... pourquoi ne pas hacker $_SERVER['HTTP_HOST'] dans mes_options ?
Ce qui peut provenir d'un proxy externe, c'est le HTTP_X_FORWARDED_FOR qui indique l'ip du client derrière le proxy. Ensuite, chez AOL, je ne sais pas comment ça se passe...
Hacker le $_SERVER['HTTP_HOST'] ne serait pas suffisant : le path réel peut changer, par exemple /spip/ peut être réécrit en /spip/version1.9/. Il faudrait donc bidouiller la variable globale $REQUEST_URI, je ne le sent pas trop.
Au temps pour moi !
Ton patch est intégré en r6997.
Statut changé à Fermé
voir aussi #578
Tu n'as pas donné ton email... merci de vérifier si le commit r7483 n'a pas cassé la compatibilité chez toi.
Je confirme, ça a tout cassé. On a réellement besoin de $GLOBALS['meta']['adresse_site'] à cause du reverse proxy qui réécrit les URLs.
... donc je réouvre le ticket.
Statut changé à Commentaire
Même problème constaté chez nous. Nous accédons à une instance spip depuis un intranet et un extranet, derrière un reverse proxy.
Lors de l'accès via l'extranet, et notamment lors du passage de la partie privée à la partie public, Spip renvoie l'adresse interne au lieu de renvoyer une adresse relative.
Est-ce que par hasard il serait possible de passer les URL internes à spip en relatif ? ou alors de faire fonctionner une autre instance de spip configurer avec l'adresse externe mais pluguer sur la même base de données que l'instance interne ?
Bref :)
Je ne sais pas; il faut trouver une modif qui résolve ici sans casser #578
Voir aussi http://forum.spip.org/fr_193072.html
En tous cas c'est facile de mettre dans le fichier mes_options.php :
bon ben, si ça n'intéresse plus personne... on ferme. c'est juste un pb de doc au fond : puisqu'il suffit de hacker $_SERVER
Statut changé à Fermé
The code added to SPIP in r6997 to close this ticket opens a security hole in SPIP. A patch is attached to solve the issue.
The problem arrises when the code in question uses the value of $_SERVER['HTTP_X_FORWARDED_HOST'] without validation. This variable (like many of the $SERVER['HTTP*'] variables) is set by Apache/PHP based on input supplied by the client making the request: it may not be correct (or even valid) and must not be used without checking. This allows a malicious client to make requests to SPIP that may result in SPIP generating URLs containing arbitrary hostnames chosen by the attacker and using these malicious URLs in pages. Combined with SPIP's caching behaviour, this allows the malicious client to deliver malicious content to other users and, potentially, to intercept sensitive data and make cross-site scripting attacks.
In current releases and r12786 this allows an attacker to redirect the SPIP login form to a site under their control!!!
Statut changé à Commentaire
Traduction du post de Thomas, qui est très concerné par le problème donc me presse de traduire ;)
Le code qui a été ajouté à SPIP r6997 a en fait ouvert un nouveau problème de sécurité. J'ai attaché le patch qui résoud ce problème.
Le problème se situe dans la partie du code qui utilise la variable $_SERVER['HTTP_X_FORWARDED_HOST']. Cette variable est définie à l'origine par Apache/PHP et se base simplement sur ce qui est envoyé par le navigateur. Peu importe la valeur envoyée ; elle n'est ni vérifiée ni validée. Ainsi n'importe qui peu envoyer des requêtes à SPIP qui générera des URLS non appropriées. Ceci combiné avec le système de cache de SPIP, cela permet à quiconque de glisser du contenu offensif et éventuellement d'intercepter des données sensibles (XSS).
Dans la version actuelle de SPIP r12786, un hacker peut rediriger un formulaire de login sur son propre site!!!
cf #1689 et #578