Ubuntu-fr

psylo24

cURL avec HTTPS pour vérifier les identifiants

Bonjour tout le monde,

Je suis en train d'essayer de faire un script qui me permet de dire si les identifiants (login/password) sont corrects sur un site donné, par exemple sur le forum d'ubuntu-fr par le biais de cURL.

curl --user toto:password -k https://forum.ubuntu-fr.org

Ça me retourne la page web mais visiblement ça n'essaie même pas de s'authentifier auprès du site.

Si vous avez quelques idées je suis preneur

J'ai déjà effectué quelques recherches sur internet, certains disent qu'il faut au préalable telecharger le certificat du site mais je n' suis pas arrivé à vrai dire

Merci à vous

Dernière modification par psylo24 (Le 12/01/2016, à 17:19)

carreti

Re : cURL avec HTTPS pour vérifier les identifiants

Hello,

est-ce que tu connais un peu le HTML et le protocole HTTP ?

... Car en fait la première chose à faire c'est de faire de la "rétro-ingénierie" sur le formulaire de la page de connexion en s'aidant d'outils comme ceux de développement intégrés dans tous les navigateurs. (Onglets réseau par exemple). Identifier le type de requête (GET ou POST), les paramètres échangés avec le serveur par le formulaire de la page (la requête), les cookies éventuels, voir si leur absence est bloquante ou pas, aller voir aussi dans le source de la page ... C'est là qu'on se rends compte que les 9/10ème du "poids" des pages (pas ici, mais quasi-partout), c'est pour la pub, le profiling/marketing de l'utilisateur, les réseaux sociaux ...

Ça serait au mieux, (en GET) du genre (mais c'est pas ça ):

curl 'http://www.monsite.net/login.php?user=monnom&passwd=monpasswd'

Ou les valeurs des paramètres user et passwd (derrière les = ) peuvent être remplacés dans le shell script par des variables (j'ai donné ces noms là de paramètres (user et passwd) au pif, ça peut être (doit être même) totalement autre chose).

- Sinon si c'est du POST voir option -d pour transmettre les paramètres et les valeurs.
- Ensuite pour déboguer vaut mieux se mettre en -v (verbose) pour voir ce qui se passe au niveau des cookies et des entêtes du serveur.
- Ensuite probablement un petit -L car il y aura une redirection (qui se verra aussi dans les entêtes HTTP du serveur grâce à l'option -v) mais pour ça faut déjà avoir passé l'authentification.
- Si besoin de conserver dans les cookies les valeurs renvoyées par le serveur pour la session (options -b -c avec nom_param_du_cookie=valeur_param_du_cookie) que l'on voit aussi dans les outils de développement des navigateurs ...
- Enfin peut-être "forger" des headers pour le "user-agent" et autres paramètres attendus par le serveur ... Par exemple, certaines pages redirigent vers une page d'installation d'un navigateur si la version du "user-agent" est trop ancienne, inconnue ou ne corresponds pas à celles attendues ... Ou si le "referer" est incohérent on a des erreurs, des redirection vers des pages de login, etc ...

Sans compter que maintenant sur beaucoup de sites, ils s'amusent avec du javascript et ajax / xhr et que là curl ne peut plus suivre et qu'il faut aller dans le source de la page récupérer une valeur ou faire de la rétro-ingénierie sur le javascript, recoder tout ça en shell script et renvoyer les valeurs avec cURL comme l'aurait fait le navigateur, récupérer des cookies, du JSON, l'interpréter, etc ... Je noirci un peu le tableau mais à peine ...

C'est très intéressant à faire mais, sans vouloir te décourager, un peu plus compliqué que ce que tu imagines, je crois ...
Les formulaires c'est pas forcément le plus facile à faire pour commencer avec cURL.

(L'option --user amha est plus à utiliser avec le protocole FTP ou autres, des trucs un peu plus basique que le HTTP ...)

Le HTTPS c'est un détail. cURL le gère tout seul si il a été compilé avec le support SSL (ce qui est généralement le cas).

Dernière modification par carreti (Le 13/01/2016, à 18:06)

---

Utilisateur et administrateur de Linux et d'Unix (depuis le siècle dernier) et plus précisément ces dernières années de  Linux Gentoo et de Windows 10 ...
Je cherche du boulot sur Paris et RP Ouest en administration système ou mieux dans la tierce maintenance applicative, middleware, base de données, flux ...

psylo24

Re : cURL avec HTTPS pour vérifier les identifiants

Bonjour,

et merci pour ta réponse.
En effet j'ai je connais un peu le HTML CSS PHP mais bon je suis plus  dans le réseau que dans la programmation

Quand je regarde par exemple le site sfr.fr, je vois que le formulaire utilise la méthode "post", mais j'ai déja essayé de regarder le code généré du formulaire sur mon navigateur pour me faire un URL d'auto-login mais c'est là que je n'y arrive plus....

Le formulaire de login pointe vers l'url suivante : action="/cas/login?domain=mire-sfr-et-moi&service=https%3A%2F%2Fwww.sfr.fr%2Faccueil%2Fj_spring_cas_security_check#sfrclicid=EC_mire_Me-Connecter"

Mes inputs pour le login et le mot de passe son bien username et password

Et quand j'essaie par exemple de saisir l'URL suivante dans mon navigateur (qui est censé m'identifier ou non) via l'url ci dessous, ca ne fonctionne pas et c'est surtout là que je bloque.
http://www.sfr.fr/cas/login?username=toto@sfr.fr&password=1234
Car je pense que avant de passer à cURL ca devrait fonctionner avec mon navigateur non ? à vrai dire cURL c'est la premiére fois que je l'utilise.

Si quelqu'un peu m'aider à troubleshooter mon probléme ca serait super

carreti

Re : cURL avec HTTPS pour vérifier les identifiants

Hello,

En effet j'ai je connais un peu le HTML CSS PHP mais bon je suis plus  dans le réseau que dans la programmation

Ça c'est cool :-)

Et quand j'essaie par exemple de saisir l'URL suivante dans mon navigateur (qui est censé m'identifier ou non) via l'url ci dessous, ca ne fonctionne pas et c'est surtout là que je bloque.

Attention, en essayant de saisir dans la barre d'adresse une requête POST, tu fais du GET et la page qui attends du POST ne verra probablement rien du tout ....
Si tu as un serveur apache fait le test, tu verras la différence dans les logs. C'est pour ça que cURL est indispensable pour les POST.

Dans les outils de développement des navigateurs (Firefox et Chrome tout au moins) / onglet network, si on fait un clic droit sur la requête envoyée (celle contenant login.php), on peut faire "copy as curl" ...

Par exemple ici cela donnerait :

curl 'https://forum.ubuntu-fr.org/login.php?action=in' -H 'Cookie: punbb_cookie=1%123456789ABCDEF%7C123456789ABCDEF%7C123456789ABCDEF' -H 'Origin: https://forum.ubuntu-fr.org' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Referer: https://forum.ubuntu-fr.org/index.php' -H 'Connection: keep-alive' --data 'form_sent=1&redirect_url=%2Findex.php&req_username=carreti&req_password=mon_password' --compressed

(J'utilise Chrome : cf. user-agent)
Certains des headers (-H etc ...) peuvent être remplacés par leur équivalent cURL  : -A 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36' pour le user-agent, mais bon on y gagne pas grand chose ... (tout comme le referer -e)

Bien sûr comme il y a une redirection (qui est aussi passée dans les paramètres redirect_url=%2Findex.php) :  il faut cocher la case "préserve log" dans les outils de développement, sinon aussitôt la redirection lancée, la requête "login.php" disparait et on a la requête envoyée à "index.php" ...

Ici une partie est passée en GET : action = in
le reste (form data) : 
- form_sent =: 1 
- redirect_url = /index.php   
- req_username = carreti   
- req_password = mon_password
... c'est du pur POST et c'est donc invisible dans la barre d'adresse du navigateur.

Tout comme le cookie punbb_cookie (pas du POST mais un cookie, donc invisible pour l'utilisateur lambda) ...

Le paramètre redirect_url est certainement là, pour palier au fait que certains peuvent masquer leur referer afin de les ramener après login à la page d'ou ils venaient ...
Et dans cURL pour suivre la redirection, il faudrait aussi probablement ajouter -L, sinon je ne suis pas sûr qu'il irait jusqu'à la page (ici "index.php") vers laquelle on est redirigé. Enfin pendant le développement un petit -v, ça mange pas de pain ... (En "prod" on passe tout en -s) ...

Enfin pour écarter la question initiale sur le HTTPS qui est normalement géré de façon transparente par cURL :

user@host ~ $ curl -V
curl 7.30.0 (x86_64-pc-linux-gnu) libcurl/7.30.0 OpenSSL/1.0.2e zlib/1.2.8 libidn/1.26
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 

Te permettra de t'assurer que tu as bien OpenSSL dans tes libs de compilation et HTTPS dans les protocoles disponibles (le contraire serait étonnant) ...

Dernière modification par carreti (Le 16/01/2016, à 11:22)

---

Utilisateur et administrateur de Linux et d'Unix (depuis le siècle dernier) et plus précisément ces dernières années de  Linux Gentoo et de Windows 10 ...
Je cherche du boulot sur Paris et RP Ouest en administration système ou mieux dans la tierce maintenance applicative, middleware, base de données, flux ...

psylo24

Re : cURL avec HTTPS pour vérifier les identifiants

Je te remercie pour ces éclaircissements je vais potasser sur le sujet avec tes informations car c'est en tripotant qu'on apprend le plus, encore merci