Vinky41
En fait c'est "pire" que ça.
Au tout début de mes tests j'étais à distance pour le faire et je ne comprenais pas.
J'ai fini par retester chez moi en mettant les ip privés et là ça a marché.
En retestant sur le réseau local avec l'ip publique, cela ne fonctionne même pas.
Je pourrais tester avec mon vpn si tu veux, mais ça risque d'être exactement la même chose à mon avis 🙁
EDIT : JE confirme que l'interface web fonctionne très bien à travers le vpn 😉
Zakhar
Si tu as un VPN, oui, le test est parfait.
Vérifie quand même que l'admin à distance est bien activée... on sait jamais, parce que ton histoire avec l'IP publique en local... c'est louche.
Sinon dans ta requête curl il manque de peut-être un truc (on s'en rend compte avec Wireshark) regarde dans mon dlfree comme je fais par exemple pour ajouter un téléchargement à la liste:
freebox_start_dl()
{
HTTP_CODE=$( curl "http://${FBX_IP_PORT}/download.cgi" \
-o "${TMPLOG}" \
-b "${TMPLOG}.f" \
-d "url=${IDENT}&user=freebox&method=download.http_add" \
-H 'X-Requested-With: XMLHttpRequest' \
-w "%{http_code}" \
-s)
jsoncatch
}
Le header
X-Requested-With: XMLHttpRequest est indispensable, sinon ça ne marche pas !..
Pour d'autres requêtes, par contre, il n'est pas utile, comme pour télécharger un fichier depuis la freebox, vers le PC local :
HTTP_CODE=$( curl "http://${FBX_IP_PORT}/get.php" \
-o "${DEST}/${NAME}" \
-w "%{http_code}" \
-b "${TMPLOG}.f"\
-d "filename=${FBX_FILE}" )
Et maintenant, je suppose qu'il faut aussi rajouter le CSRF-Token comme tu le montres dans ton exemple.
Bon test !
Vinky41
Bah le truc c'est que si je test en local avec l'adresse privée, cela marche parfaitement. Tu penses qu'il faut rajouter des arguments pour lorsque l'on est à distance ?
Zakhar
Vu qu'on n'a pas les spécifications de l'interface de la Freebox, on est obligé de "deviner" !..
Et c'est en tout cas indispensable à distance, et le header en local "ne gêne" pas (je ne sais pas s'il est indispensable ou pas). De la sorte, ce bout de code fonctionne que l'on soit en local ou à distance... et c'est donc ça qui est programmé dans dlfree. 😉
Alors, il donne quoi ton test VPN ? (et change aussi le MdP et port après le test, parce que le fournisseur de VPN, lui, il fait la requête en clair, et idem qu'un Proxy, il aura tout ça bien en clair dans ses logs, le chiffrement c'est juste entre toi et on VPN, mais pas entre le VPN et ce que tu accèdes).
Vinky41
aaaah ok bon je vais tester ça alors 😉 je te tiens au jus 🙂
Merci pour ton retour en tout cas 🙂
EDIT : Bon après test, toujours pareil 🙁 je vais essayer de façon plus poussée, mais ça ne semble pas être ça 🙁
Vinky41
Pour le VPN, c'est moi qui l'ai mis en place, pas de souci là dessus, c'est mon serveur qui le gère 😉 c'est d'ailleurs sur ce même serveur que sont les fichiers que je veux mettre sur la box.
Zakhar
Ok, si c'est ton serveur à toi, il y a moins de problème... mais cependant, à moins que ce soit une "dedibox" donc aussi chez Free (en fait Online, mais c'est une filiale), n'oublie pas que l'opérateur (OVH, Gandi, etc...) verra les flux "en clair" passer sur son infra. 😛
Vinky41
ouais ouais ça c'est obligatoire, mais bon, cette crainte est valable pour tout accès sur ma box à distance malheureusement 🙁
Mais tu as raison de le rappeler.
Zakhar
Absolument, c'est la raison pour laquelle je ne fais cet accès distant (chez ma mère) que depuis chez moi. Comme je suis aussi chez Free, ça reste dans le "réseau local Free", et vu que contractuellement la Freebox de ma mère leur appartient, ainsi que tout ce qu'il y a dessus... c'est pas trop choquant dans ce cas d'avoir un truc en clair. De toute façon, si c'était chiffré avec un certificat SSL, Free aurait la clé privée et par conséquent les moyens de déchiffrer de toute façon.
Comme je l'ai mis dans le bugtracker (sur un autre bug d'un gars qui avait l'air de découvrir ce manque de sécurité), c'est tellement gros qu'à mon avis ils l'ont fait exprès pour que si tu as 2 notions de sécurité et 3 grammes de jugeote, tu ne le fasses pas en dehors du réseau Free (ou alors tu changes les MdP/Port de chez toi juste après !).
Même sans certificat, il y a des moyens simples de sécuriser un peu mieux.
Il suffit que la Freebox envoie un "challenge" (c'est à dire une chaîne aléatoire) dans la page de login, et la page de login fait :
SHA512(SHA512(MotDePasse) + Challenge) (**).
Du côté du serveur tu fais le même calcul et tu vérifies. Ainsi ce qui circule est un truc brouillé (non déchiffrable) et différent à chaque login (donc inutile de le "piquer" pour le rejouer, ça ne fonctionne pas !).
Pour faire ça, tu as besoin juste d'un truc : une bibliothèque qui calcule un SHA512 (tout autre hash "raisonnable" fonctionnerait tout aussi bien) en JavaScript(*)... et je suis sûr qu'en 10 sec de recherche sur le web on trouve ça ! :lol:
(*) parce que côté Freebox, c'est du Linux, donc la librairie pour calculer un SHA512 existe à l'évidence.
(**) ça c'est pour que la Freebox ne conserve pas le MdP en clair, mais seulement un hash. Sinon tu peux simplifier le premier SHA512... mais du coup, risque sur le stockage local -on doit pouvoir démonter le disque de la Fbx et le lire sur n'importe quel PC après tout!-
Vinky41
Je ne suis pas certain que la sécurité soit "meilleure" si tu fais ça depuis une autre freebox. Ca n'empêche pas quelqu'un se positionnant entre toi et la box de chez toi de voir ton mot de passe 😉
Enfin bref, ce n'est pas vraiment le débat, mais tu as eu raison (pour ceux qui liront ce topic) de rappeller de bien faire attention à ce point de sécurité et dans tous les cas de prendre en compte les conséquences de ce choix 🙂
PS : Je ne sais pas si tu avais vu sur la page précédente, mais malgré l'ajout du "-H 'X-Requested-With: XMLHttpRequest'" cela ne fonctionne pas non plus 🙁
Zakhar
Vinky41 a écritJe ne suis pas certain que la sécurité soit "meilleure" si tu fais ça depuis une autre freebox. Ca n'empêche pas quelqu'un se positionnant entre toi et la box de chez toi de voir ta box 😉
Certes... mais là tu es au niveau "hardware". Parce que de chez moi partent des fils de cuivre France Telecom, mais ce sont des composants "passifs", le premier composant "actif" (c'est à dire avec de l'électronique et du soft) c'est le DSLAM de chez Free, idem du côté de chez ma mère. Donc quelqu'un qui se positionne "entre les deux" : bah... soit il est à l'intérieur de chez Free sur leur réseau local, soit il a mis des pinces-crocodile sur les fils de cuivre et il "écoute" (niveau
"écoute téléphonique").
Je te l'accorde la sécurité n'est pas "meilleure" (elle est de toute façon à chier), mais c'est juste que ce ne sont plus les mêmes
risques. Les risques sont :
- un gars de chez Free (mais ça on ne peut rien y faire, c'est leur matériel, et même si c'était du SSL ils auraient la clé !)
- une attaque "hardware" (/"gouvernementale" => type écoute téléphonique).
... donc nettement moins facile à faire qu'une simple log sur un proxy ou chez un hébergeur. 😉
En réalité, une "sécurité" bien faite doit être proportionnée au "risque", c'est pourquoi j'ai dit par abus de langage que dans ce cas d'utilisation elle est "meilleure". L'abus de langage est que la "sécurité" n'est pas "meilleure", par contre dans un usage en "réseau local" (de Free à Free) c'est "mieux" proportionné aux risques somme toute faibles.
Et pour revenir au sujet (effectivement on s'est un peu écarté) commence par le commencement : le test
"normal" à partir de l'
extérieur (ton VPN par exemple) et après on avise !
... si ça se trouve il y a encore d'autre headers à mettre.
Vinky41
Dernier HS : Oui je te l'accorde, dès qu'on sort du wifi c'est déjà plus compliqué pour quelqu'un de récupérer les infos (enfin particulièrement s'il est impossible de se connecter par Wifi d'où tu es et chez toi, sinon quelqu'un pourra toujours prendre les infos en se connectant à ce réseau wifi justement 😉 )
Pour les tests voici ce qui a été "fait" :
Télécharger sur l'interface web un fichier depuis le local & l'exterieur (vpn) : Cela fonctionne parfaitement.
Télécharger un fichier sur la box à l'aide d'un script depuis le réseau local (en utilisant les ip privées) : Cela fonctionne parfaitement avec les lignes ici :
http://forum.ubuntu-fr.org/viewtopic.php?pid=12251711#p12251711
Télécharger un fichier sur la box à l'aide d'un script depuis le réseau local (en utilisant les ip publiques/Nom de domaine) : Cela ne fonctionne pas : Erreur 403 Forbiden
Télécharger un fichier sur la box à l'aide d'un script depuis un réseau externe : Cela ne fonctionne pas : Erreur 403 Forbiden.
Voilà donc mes résultats (sauf erreur de ma part)
Zakhar
Les deux derniers sont cohérents. En fait quand tu utilises l'IP publique en interne, ce n'est pas tout à fait comme utiliser l'adresse locale.
Par exemple si tu n'as pas activé l'admin à distance... bah ça ne marchera pas, bien que tu sois en local (en ayant donné l'IP publique).
Bon, il te reste maintenant à faire une trace Wireshark pour tenter de voir ce qui manque puisque ça fonctionne avec un navigateur.
Tu sais faire la trace Wireshark ?...
Sinon je peux tenter de trouver les commandes tcpdump équivalentes pour faire ça... mais je les oublie régulièrement... je suis un peu feignasse avec Wireshark qui est si pratique ! 😛
P.S.: il manque le test en "normal" (navigateur) depuis le réseau local, mais en donnant l'IP publique au lieu de l'IP locale.
Vinky41
Oui ça me semble logique effectivement 😉
Pour le PS c'est ce que je disais dans le point 3, cela ne fonctionne pas 🙁
Pour wireshark, aucun souci je connais, là om je suis embêté, c'est qu'est-ce que je cherche ? 😃 En gros (si j'ai bien compris) je lance un dl sur ma box depuis le réseau extérieur et je regarde ce que dit wireshark ?
Mais après j'en fais quoi ? (là par exemple je viens de le faire en utilisant l'ip du réseau local) mais je ne vois rien de plus (mais je ne cherche peut-être pas la bonne chose 🙁 )
Zakhar
En principe si tu rejoues très exactement ce que fait le navigateur, et que tu voies au travers de WireShark, ça devrait fonctionner.
Après, tu truc c'est d'enlever petit à petit les headers qui ne servent pas, parce que sinon le code est suant avec tout ce qu'envoie le navigateur.
Il faut aussi faire les séquences dans l'ordre où les fait le navigateur et ensuite voir si ça ne gêne pas quand tu enlèves des trucs intermédiaires. Le CSRF, tu le prends sur le login, ou il change à chaque "page" ? Si c'est la deuxième option, il faut demander la "page" (même si c'est inutile pour le download) histoire d'avoir le nouveau CSRF.
Et bizarre qu'ils aient scratché la possibilité d'utiliser l'IP publique en local. Enfin d'un autre côté vu qu'on peut utiliser l'IP locale, c'est pas dramatique tant qu'on peut faire marcher local & distant.
Vinky41
Je ne sais pas ce que tu cherches exactement,
Je te met deux images de ce que renvoie wireshark voit au moment où je post un fihcier (en l'occurrence l'image iso de test de débit de free dans mon cas).
(j'ai bien sûr effacé mon ip publique)
Adresse publique :
Adresse locale :
Je ne vois strictement aucune différence (en dehors des jetons/ID)
Zakhar a écrit Le CSRF, tu le prends sur le login, ou il change à chaque "page" ? Si c'est la deuxième option, il faut demander la "page" (même si c'est inutile pour le download) histoire d'avoir le nouveau CSRF.
Non le CSRF reste le même tant que la session est valable. Donc tant que je ne suis pas déconnecté, ça reste le même 🙂
Vinky41
J'ai peut-être trouvé quelque chose qui fait que ça ne fonctionne pas.
Voici ce que je j'ai avec mon script quand cela ne fonctionne pas :
Donc on est d'accord, ça ne renvoie pas la bonne chose à la box avec le script (ce qui doit expliquer l'erreur) mais je vois pas comment régler ça, si tu vois le truc ?
EDIT : Pour être totalement complet, voilà ce que j'ai quand le script fonctionne (en local donc) :
Autant dire, pareil que depuis l'exterieur :huh:
Zakhar
Les différences sont effectivement faibles...
Le navigateur expose explicitement (Accept) qu'il veut bien du application/json, comme le XMLHttpRequest, ça peut jouer...
Après je m'interroge sur la différence de taille de 1 octet (Content-length 139 et 140) entre les requêtes interne/externe. Le csrf est de taille "variable" ou c'est juste que tu as oublié un caractère en le récupérant... ce qui expliquerait le bug.
Aussi le navigateur n'a pas l'air de donner la taille, ce qui provoque un "chunk transfer"... a priori c'est "pire", mais ça a l'air de marcher quand même.
En fait ce qui me turlupine le plus, c'est cette différence de taille du CSRF. Regarde si par hasard il n'y aurait pas une différence en distant, puisqu'il est à deux endroits (header et dans la form) si les deux valeurs sont bien identiques.
... et aussi tu utilises un curl apple... hum... si ça trouve il bugge... parce que bon, là c'est le forum Ubuntu, pas Apple. 😉
Vinky41
Le CSRF est de taille aléatoire de ce que j'ai remarqué donc je pense que c'est lié à ça également. Après est-ce que la taille est lié à l'accès distant ? Je ne sais pas 🙁 j'ai pas forcement fait un "lien".
Pour ce qui est du curl "apple" c'est parce que j'ai fait les tests sur mon mac, mais mon serveur est sous une ubuntu et j'avais exactement le même problème que sur le mac (ou plutôt, le mac a le même souci qui le serveur) donc j'en déduis que la version du curl n'est pas à remettre en question.
Il n'y a pas d'erreur en copiant je l'ai fait tellement de fois que j'en suis sûr ^^
Pour les deux valeurs, quand je regarde sur le navigateur avec firebug, que se soit dans le form ou le header, j'ai exactement le même résultat.
La seule chose qui me semble pertinente, c'est le Accept forcé en application/json. Mais je ne sais pas comment le forcer en commande curl 🙁
EDIT : En revérifiant, le CSRF est parfois du même nombre de caractère que se soit en local ou en distant.
Zakhar
Comme les autres headers :
-H "Accept: application/json, text/javascript, */*"
Car le man de curl dit :
man curl a écritNote that if you should add a custom header that has the same name as one of the internal ones curl would use, your externally set header will be used instead of the internal one.
