Tester l'existence d'un site
Pascale
autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus
flagrantes, un contrôle est fait :
$siteini=$_POST['siteini'];
$site="http://".$siteini;
$file = @fopen($site,'r');
if ($file)
{$_SESSION['siteini']=$siteini;}
else
{
echo '<p class="erreur">L\'adresse de site '.$site.' renvoie un
message d\'erreur !</p>';
$errurl1='1';
}
Ça ne nous met pas à l'abri de toutes les bourdes, mais globalement ça
marche plutôt bien et oblige certains utilisateurs à ôter leurs moufles
pour se servir du clavier.
Aujourd'hui, j'ai le problème inverse, avec un site qui existe mais renvoie
un code erreur. Pour la page d'accueil du site en question http://www.les-
rolistes-rouennais.com/ ça ne m'étonne pas trop, car non seulement la page
d'accueil met longtemps à s'afficher, mais le chargement semble n'être
jamais fini (« en attente de http://www.les-rolistes-rouennais.com/ »). Ce
qui m'ennuie plus, c'est que j'ai le même message d'erreur
avec d'autres pages, par exemple http://www.les-rolistes-
rouennais.com/forum/accueil-f2.html , mais là aussi, il semble qu'il y ait
des éléments de page qui se chargent de manière sporadique.
Du coup, je suis embarrassée, car je n'ai pas envie du tout de supprimer ce
test, même s'il est imparfait, alors si vous avez de bonnes idées, ne vous
gênez pas... (:
--
Pascale
Olivier Miakinen
> Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre
> autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus
> flagrantes, un contrôle est fait :
>
> $file = @fopen($site,'r');
> Aujourd'hui, j'ai le problème inverse, avec un site qui existe mais renvoie
Si le code de retour de fopen() n'est pas assez informatif, une idée
serait peut-être d'utiliser CURL :
http://fr3.php.net/manual/fr/ref.curl.php
Les codes d'erreur sont assez complets :
http://curl.haxx.se/libcurl/c/libcurl-errors.html
... et certains pourraient t'intéresser, par exemple :
CURLE_URL_MALFORMAT (3)
The URL was not properly formatted.
-> erreur de l'utilisateur
CURLE_COULDNT_RESOLVE_HOST (6)
Couldn't resolve host. The given remote host was not resolved.
-> probable erreur de l'utilisateur (à confirmer avec une requête sur un
site dont tu es sûre, pour vérifier que ce n'est pas le DNS qui est
en rade).
CURLE_COULDNT_CONNECT (7)
Failed to connect() to host or proxy.
-> le site est peut-être correct, même s'il ne répond pas.
etc.
Pascale
news:4870ebd3$1...@neottia.net:
> Si le code de retour de fopen() n'est pas assez informatif, une idée
> serait peut-être d'utiliser CURL :
> http://fr3.php.net/manual/fr/ref.curl.php
Ça a l'air de correspondre à ce que je cherche, par contre, je suis
totalement neuneue pour la mise en œuvre...
On commence par faire :
$ch=curl_init($url);
puis on récupère le code erreur éventuel avec
curl_errno($ch);
Mais en fait non, j'ai rien compris ? Si...?
--
Pascale
Pascale
> Si le code de retour de fopen() n'est pas assez informatif, une idée
> serait peut-être d'utiliser CURL [couic]
Je pense que ça correspond tout à fait à ce qu'il me faut : si je trouve
pas mon bonheur là dedans, c'est vraiment que je m'y prends mal, merci
Olivier (:
--
Pascale
CrazyCat
> Sur l'un de nos sites, les gens qui s'inscrivent peuvent entrer (entre
> autres) l'adresse de leur site web. Afin d'éviter les erreurs les plus
> flagrantes, un contrôle est fait :
>
> $siteini=$_POST['siteini'];
> $site="http://".$siteini;
> $file = @fopen($site,'r');
Pour ma part, j'utiliserais plutôt une fonction dédiée à cela: fsockopen:
<?
$siteini = $_POST['siteini'];
if (strpos($siteini , 'tp://')===false) $siteini = 'http://'.$siteini ;
if ($fid = @fsockopen($siteunu, 80, $errno, $errstr, 10) {
echo $siteini.' OK';
} else {
echo 'Error with '.$siteini.': '.$errno.' -> '.$errstr;
}
?>
--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces webmasters : http://www.c-p-f.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr
Mickaël Wolff
> On commence par faire :
>
> $ch=curl_init($url);
> puis on récupère le code erreur éventuel avec
>
> curl_errno($ch);
>
> Mais en fait non, j'ai rien compris ? Si...?
curl_init créé une ressource, et l'initialise avec le paramètre s'il
lui est fournit.
curl_setopt te permet de configurer ta ressource.
Il faut savoir que, par défaut, curl va télécharger la page distante
et renvoyer le contenu vers ton navigateur. Donc si tu veux seulement
vérifier que la page existe, tu peux utiliser le code suivant :
function check_url($url)
{
$socket = curl_init($url) ;
curl_setopt($socket, CURLOPT_NOBODY, true) ;
$message = curl_exec($socket)
? curl_getinfo($socket, CURLINFO_HTTP_CODE)
: curl_error($socket) ;
curl_close($socket) ;
return $message ;
}
À noter que le message renvoyé n'est pas forcément une erreur.
Je profites du thread pour soulever un point concernant curl et la
sécurité. En fournissant directement l'URL de l'utilisateur à Curl, n'y
a-t-il pas potentiellement un problème de sécurité ?
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Patrick Mevzek
> En fournissant directement l'URL de l'utilisateur à Curl, n'y
> a-t-il pas potentiellement un problème de sécurité ?
Si, multiples même.
Voir par exemple des papiers sur la sécurité d'OpenID (même problème :
l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y
connecter), ou un client HTTP « paranoïaque » dans un autre language :
http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm
(avec quelques explications sur les pièges évités).
Et bien sûr là on ne parle même pas d'éventuelles failles dans le client
HTTP en lui-même juste de failles découlant du fait d'accepter de
l'extérieur une information réutilisée telle quelle.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Mickaël Wolff
> Le Mon, 07 Jul 2008 12:36:13 +0000, Mickaël Wolff a écrit:
>> En fournissant directement l'URL de l'utilisateur à Curl, n'y
>> a-t-il pas potentiellement un problème de sécurité ?
>
> Si, multiples même.
J'ai un peu fouillé, et c'est en fait un énorme trou si on ne fait pas
attention. Merci pour les infos.
Pascale, le bout de code que j'ai fournit à titre d'illustration n'est
pas sécurisé. Il ne faut pas l'utiliser en production. Je regarde pour
faire une classe mieux fagotée, je la posterais ici.
Olivier Miakinen
>
>> En fournissant directement l'URL de l'utilisateur à Curl, n'y
>> a-t-il pas potentiellement un problème de sécurité ?
>
> Si, multiples même.
Même si cette URL n'est utilisée que pour une requête HEAD, et que la
seule information utile qu'on en retient est un éventuel code d'erreur ?
Je ne vois pas quel problème de sécurité cela pourrait poser pour
l'appelant : il y a *beaucoup* moins de risques que pour un simple
internaute cliquant sur un lien avec un navigateur qui ferait un GET
au lieu d'un HEAD et qui, en outre, interpréterait le JavaScript.
Et même pour l'appelé : s'il n'implémente pas d'effet de bord aux
requêtes HEAD, il ne risque pas grand chose -- et inversement s'il
reformate son disque dur en réponse à un HEAD, c'est bien fait pour
sa pomme !
> Voir par exemple des papiers sur la sécurité d'OpenID (même problème :
> l'utilisateur fournit une URL à un serveur qui doit s'en servir et s'y
> connecter),
Tu aurais un lien (si possible traduit en français) ?
> ou un client HTTP « paranoïaque » dans un autre language :
> http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm
> (avec quelques explications sur les pièges évités).
Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas
allé voir ce qu'était LWP::UserAgent dont il dérive).
> Et bien sûr là on ne parle même pas d'éventuelles failles dans le client
> HTTP en lui-même juste de failles découlant du fait d'accepter de
> l'extérieur une information réutilisée telle quelle.
Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur
l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Mickaël Wolff
> Tu aurais un lien (si possible traduit en français) ?
C'est vrai que moi aussi ça m'aurait aider. Cependant, en essayant
l'url file:///etc/passwd dans curl_init, même en configurant l'option
CURLOPT_NOBODY à true le contenu du fichier est affiché :-D
> Je n'ai pas bien compris ce que ça fait (il faut dire que je ne suis pas
> allé voir ce qu'était LWP::UserAgent dont il dérive).
Ce que je pense qu'il faut en retirer, c'est la limitation du timeout
(pour éviter les redirections éternelles), l'exclusion d'hôtes sensibles
afin d'éviter de détourner la fonctionnalité pour sonder le voisinage
réseau, etc. Tiens, si ça ce trouve, en utilisant la fonctionnalité
telnet, on peut éventuellement utiliser ça pour faire du spam :-D (oui,
c'est une obsession).
> Oui, bien sûr. Mais dans ce cas, quel genre de contrôle ferais-tu sur
> l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Vérifier que c'est une URL désignant une ressource HTTP est un bon
début en fait. C'est d'ailleurs ce que je suis en train de corriger dans
mes devs. Je n'avais pas réalisé la puissance de cURL.
Pascale
news:48723025$0$1117$426a...@news.free.fr:
> Pascale, le bout de code que j'ai fournit � titre d'illustration n'est
> pas s�curis�. Il ne faut pas l'utiliser en production. Je regarde pour
> faire une classe mieux fagot�e, je la posterais ici.
Bon, merci � tous de vous �tre pench�s sur mon cas (-:
Je crois que tout le monde a compris ce que je veux faire, mais quelques
pr�cisions ne peuvent pas nuire. La personne qui s'inscrit au site a le
droit de rentrer, parmi ses coordonn�es, l'adresse de son site (le http://
est positionn� automatiquement, on contr�le que l'utilisateur ne le met pas
2 fois). Le but est de pr�venir la saisie d'adresses de sites farfelues ou
erron�es. Je ne veux en aucun cas que le site s'ouvre automatiquement sur
l'ordinateur de la personne qui s'inscrit, je veux simplement pr�venir la
saisie d'adresses erron�es (je suis emb�t�e non seulement avec ceux qui
tapent avec leurs moufles, avec ceux qui veulent mettre un texte du style
��en chantier��, et aussi avec ceux, plus nombreux qu'on ne croit, qui
confondent adresse de site et adresse courriel, ce qui fait qu'on se
retrouve avec des URL du genre http://machinc...@fai.fr).
Le contr�le de l'URL s'effectue non seulement � l'inscription, mais �
chaque fois que la personne modifie quelque chose dans ses coordonn�es.
Si je peux avoir un message d'erreur plus pr�cis que ��URL erron�e��, ce
sera pas plus mal (:
--
Pascale
Olivier Miakinen
>
> C'est vrai que moi aussi ï¿œa m'aurait aider. Cependant, en essayant
> l'url file:///etc/passwd dans curl_init, mï¿œme en configurant l'option
> CURLOPT_NOBODY ￜ true le contenu du fichier est affichￜ :-D
Peut-ï¿œtre bien, mais je te rappelle le dï¿œbut du code de Pascale :
-----------------------------------
$siteini=$_POST['siteini'];
$site="http://".$siteini;
$file = @fopen($site,'r');
-----------------------------------
Je veux bien manger ma barbe si l'url html://file:///etc/passwd ouvre
quoi que ce soit en local...
> [...] l'exclusion d'hï¿œtes sensibles
> afin d'ￜviter de dￜtourner la fonctionnalitￜ pour sonder le voisinage
> rï¿œseau
Ah oui, lￜ je suis d'accord. Par exemple en lui passant une adresse IP.
>, etc. Tiens, si ￜa ce trouve, en utilisant la fonctionnalitￜ
> telnet, on peut ï¿œventuellement utiliser ï¿œa pour faire du spam :-D (oui,
> c'est une obsession).
Mï¿œme rï¿œponse que pour file : c'est impossible puisque c'est Pascale qui
rajoute http:// au dï¿œbut.
> Vï¿œrifier que c'est une URL dï¿œsignant une ressource HTTP est un bon
> dï¿œbut en fait.
Cf. supra. Pas besoin de le vï¿œrifier : on l'impose.
Patrick Mevzek
> Le but est de prï¿œvenir la saisie d'adresses de sites farfelues ou
> erronï¿œes.
Mon conseil est alors :
- de ne faire qu'un test syntaxique (pas de connexion ￜ la ressource
pointï¿œe par l'URL)
- d'autoriser https:// (ï¿œventuellement)
- et de permettre aux gens bien de donner directement l'URL avec http://
au dï¿œbut :-)
Vous n'avez donc besoin ni de fopen, ni de curl.
Mais d'une bonne bibliothï¿œque d'analyse des URLs (non il ne ne suffit pas
d'avoir http:// au dￜbut, il y a plusieurs rￜgles ￜ vￜrifier... on peut
s'en sortir lￜ avec une expression rￜguliￜre mais mieux vaut laisser cￜ ￜ
une bibliothï¿œque optimisï¿œe pour ca)
> Le contrï¿œle de l'URL s'effectue non
> seulement ￜ l'inscription, mais ￜ chaque fois que la personne modifie
> quelque chose dans ses coordonnï¿œes.
Pourquoi ne pas revￜrifier *que* si le champ ￜ Adresse du site ￜ est
modifiￜ (et donc ne pas revￜrifier si on change que le reste) ?
> Si je peux avoir un message d'erreur
> plus prￜcis que ￜￜURL erronￜeￜￜ, ce sera pas plus mal (:
L'URL est bonne syntaxiquement ou non. Aprï¿œs la ressource est accessible
ou non, et si elle ne l'est pas cela ne signifie pas *nï¿œcessairement* que
l'URL est mauvaise : cela peut ï¿œtre un problï¿œme temporaire d'accï¿œs
n'importe oￜ entre les deux serveurs, un code HTTP 500 ou 503, etc.
De toute faï¿œon, j'imagine (mais je peux me tromper je n'ai pas tout le
contexte), que vos utilisateurs ne sont pas tous les administrateurs des
sites web renseignï¿œs, donc mï¿œme si vous donnez une erreur trï¿œs prï¿œcise,
ils ne pourront de toute faï¿œon rien corriger d'eux-mï¿œmes (au mieux
transfￜrer au support technique de la sociￜtￜ gￜrant leur site web, avec
des rï¿œsultats non garantis). Donc ce qui est utile pour eux, et pour vous,
c'est juste ￜ l'URL est-elle valide syntaxiquement ￜ et pas ￜ la ressource
pointï¿œe par l'URL est-elle accessible maintenant de suite depuis un
serveur trￜs spￜcifique ￜ.
D'autre part, vous n'avez aucune garantie que le site appartient bien/est
gￜrￜ par la personne en question. Tout le monde pourra mettre
http://www.google.com/
Mieux vaut donc que le champ soit optionnel.
Sinon, il faut mettre en place une vï¿œrification style : Placez un
fichier ayant un nom ￜ dynamique, choisi alￜatoirement ￜ sur votre serveur
et on teste.
Pascale
news:48726851$1...@neottia.net:
> M�me r�ponse que pour file : c'est impossible puisque c'est Pascale qui
> rajoute http:// au d�but.
Je pourrais ne pas le faire, c'�tait juste pour faciliter la vie des
utilisateurs (et la n�tre, par la m�me occasion).
--
Pascale
Patrick Mevzek
> Je veux bien manger ma barbe si l'url html://file:///etc/passwd ouvre
> quoi que ce soit en local...
[..]
> Mï¿œme rï¿œponse que pour file : c'est impossible puisque c'est Pascale qui
> rajoute http:// au dï¿œbut.
[..]
En thￜorie, oui. En pratique dￜs qu'on utilise un outil basￜ sur du C, et
donc des chaï¿œnes terminï¿œes par U+0000, des bugs surgissent. C'est
frï¿œquent, rï¿œgulier, et cela ne disparaï¿œtra jamais totalement.
La derniￜre faille curl mentionnￜ dans mon autre message, ￜ savoir :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4850
en est un exemple d'ailleurs, mï¿œme si effectivement elle ne serait
probablement pas exploitable dans le cas prￜcis ￜvoquￜ ici.
Donc, coller http:// au dï¿œbut peut faire partie d'une politique de
sￜcuritￜ, mais ce ne doit ￜtre qu'un maillon, pas le seul.
On peut aprï¿œs, vï¿œrifier syntaxiquement la chose. C'est un deuxiï¿œme maillon.
Et un U+0000 sera normalement bloquￜ lors de ce deuxiￜme maillon.
>> Vï¿œrifier que c'est une URL dï¿œsignant une ressource HTTP est un bon
>> dï¿œbut en fait.
>
> Cf. supra. Pas besoin de le vï¿œrifier : on l'impose.
Et si on veut du HTTPS :-) ?
Patrick Mevzek
> Mï¿œme si cette URL n'est utilisï¿œe que pour une requï¿œte HEAD, et que la
> seule information utile qu'on en retient est un ï¿œventuel code d'erreur ?
Oui.
Mais le problￜme de sￜcuritￜ n'est pas *que* sur le serveur faisant la
requï¿œte, ce dernier peut devenir l'origine d'une attaque de type deni de
service (distribuￜ ou non).
Voici quelques exemples de choses (tirￜes d'un papier sur la sￜcuritￜ
d'OpenID que j'avais lu mais je n'ai plus la rï¿œfï¿œrence en tï¿œte) auxquelles
il faut penser, c'est ￜ dire des URLs ennuyeuses :
- http://www.nsa.gov:1/, http://www.nsa.gov:2/, http://www.nsa.gov:3/
on fait une attaque de dï¿œni de service sur tous les ports, ou un
ￜquivalent ￜ nmap ￜ (mￜme si ce n'est pas du HTTP sur tous les ports, le
client risque de retourner un code diffￜrent entre ￜ pas de rￜponse ￜ et
ￜ une rￜponse qui ne ressemble pas ￜ du HTTP ￜ).
Et, indￜpendamment d'une rￜponse ou non du serveur appelￜ, cela peut ￜtre
gï¿œnant juste d'initier un trafic vers certaines destinations...
- https://192.168.1.15/internal/auth?ip=1.1.1.1
URL interne ￜ un rￜseau normalement
- http://localhost:8080/
mï¿œme genre, et contournement d'un ï¿œventuel pare-feu local (sur le
serveur web)
- http://www.youtube.com/largemovie.flv
dï¿œni de service en temps et RAM consommï¿œe (sauf si on fait un HEAD, ok)
- file:///dev/null
il faut probablement veiller ￜ ne faire que du HTTP/HTTPS
- http://www.example.com/register.pl?user=toto&pass=titi
remplissage ￜ automatique ￜ de formulaires ￜ distance (sauf CAPTCHA et
autres), ou spam de blogs et autres, etc...
> Je ne vois pas quel problￜme de sￜcuritￜ cela pourrait poser pour
> l'appelant : il y a *beaucoup* moins de risques que pour un simple
> internaute cliquant sur un lien avec un navigateur qui ferait un GET au
> lieu d'un HEAD et qui, en outre, interprï¿œterait le JavaScript.
Il est difficile de quantifier les dangers respectifs de diffï¿œrentes
pratiques.
L'appelant devient la source d'un certain trafic (une requï¿œte HTTP), comme
dï¿œlï¿œgataire du client qui a soumis l'URL. Il est alors *responsable* de ce
trafic, comme l'est un proxy HTTP. Il vaut mieux qu'il soit absolument sï¿œr
de la lￜgitimitￜ de ce trafic, car sinon il est lui-mￜme vulnￜrable (cf
exemple http://localhost:8080/ plus haut) ou devient un intermï¿œdiaire
pour exploiter des vulnï¿œrabilitï¿œs ailleurs (ce qui n'est pas beaucoup plus
enviable... avec les lois en prￜparation c'est un coup ￜ perdre son accￜs
ADSL :-))
> Et mￜme pour l'appelￜ : s'il n'implￜmente pas d'effet de bord aux
> requï¿œtes HEAD, il ne risque pas grand chose -- et inversement s'il
> reformate son disque dur en rￜponse ￜ un HEAD, c'est bien fait pour sa
> pomme !
Pas seulement. Il peut faire confiance implicite au serveur appelant,
parce qu'il est dans le mￜme rￜseau, etc... et donc permettre l'accￜs ￜ
une ressource privￜe. Oui, le modￜle de sￜcuritￜ du serveur appelￜ est en
partie en dï¿œfaut. Mais, en pratique, ce genre de dï¿œfaut est frï¿œquent.
Ou ￜ l'opposￜ, il peut mettre en place de la QoS et donc refuser l'accￜs
au serveur appelant, parce qu'il a dￜjￜ vu son IP trop souvent dans le
passￜ, alors que la ressource demandￜe serait accessible depuis un client
ￜ normal ￜ.
De mï¿œme, un client HTTP s'identifie (User-Agent & co, mais aussi en-tï¿œtes
Accept souvent absent par exemple, ce qui est dￜtectￜ par des outils
comme mod_security, etc.) diffï¿œremment d'un navigateur, ce qui peut
entraï¿œner une diffï¿œrence de rï¿œponse de la part d'un serveur (ok, le
problￜme est du ressort du serveur HTTP appelￜ, mais en pratique on voit
souvent ce genre de situations).
>> ou un client HTTP ￜ paranoￜaque ￜ dans un autre language :
>> http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.03/lib/LWPx/ParanoidAgent.pm
>> (avec quelques explications sur les piï¿œges ï¿œvitï¿œs).
>
> Je n'ai pas bien compris ce que ï¿œa fait (il faut dire que je ne suis pas
> allￜ voir ce qu'ￜtait LWP::UserAgent dont il dￜrive).
LWP::UserAgent est un client HTTP en Perl (comme curl donc).
LWPx::ParanoidAgent est une sous-classe du prï¿œcï¿œdent, donc toujours un
client HTTP comme curl mais qui en plus vï¿œrifie certaines choses comme :
- suppression de la fonctionnalitￜ proxy (requￜtes directes toujours)
- utilisation seulement des "schemes" http et https
- impossible de se connecter sur des IPs privï¿œes (192.168.x etc ...)
- prise en compte de listes noires de noms/IPs
- prise en compte d'un time out global pour ï¿œtre sï¿œr de s'arrï¿œter au bout
d'un certain temps et de ne pas rester bloquￜ ￜ la merci d'un serveur
distant qui rï¿œpond, intentionnellement ou non, trï¿œs lentement.
(cas prￜcis ￜvoquￜ au dￜbut de ce fil)
En tenant compte des redirections HTTP (autre point ￜ prendre en compte
globalement, les navigateurs dï¿œtectent les boucles de redirection et
s'arrï¿œtent aprï¿œs un certain nombre de sauts, je ne sais pas si c'est le
cas, par dï¿œfaut, dans tous les clients HTTP), des chaï¿œnes de CNAME dans les
DNS (qui pourraient provoquer des boucles), etc.
>> Et bien sￜr lￜ on ne parle mￜme pas d'ￜventuelles failles dans le
>> client HTTP en lui-mï¿œme juste de failles dï¿œcoulant du fait d'accepter
>> de l'extï¿œrieur une information rï¿œutilisï¿œe telle quelle.
>
> Oui, bien sï¿œr. Mais dans ce cas, quel genre de contrï¿œle ferais-tu sur
> l'URL qui pourrait minimiser les risques lors de la connexion par CURL ?
Par rapport au besoin du posteur initial, il me semble qu'un simple test
syntaxique sur l'URL entrï¿œe suffit (ce qui n'est mï¿œme pas fait dans
l'exemple donnￜ au dￜbut, mￜme coller http:// systￜmatiquement au dￜbut,
ca me paraï¿œt dangereux, moi si on me demande une adresse web, c'est une
URL, donc je mets dￜjￜ le http:// au dￜbut :-)), il n'y a pas besoin de
curl. Je ne vois pas bien l'intï¿œrï¿œt de vï¿œrifier si le serveur en question
rￜpond, existe, etc. (sauf si on cherche rￜellement ￜ rￜcupￜrer quelque
chose dessus, genre une image pour un avatar ou autre) parce qu'il
pourrait y avoir *plein* de problￜmes, y compris du cￜtￜ de l'appelant
(problï¿œmes rï¿œseau, etc.) qui font que le serveur ne rï¿œpond pas, et
rï¿œpondra plus tard, ou le contraire, etc. [ Ca me rappelle ZoneCheck cette
affaire :-)] Ca, plus les risques auxquels on s'expose fait que je ne
trouve pas utile d'aller faire la requï¿œte HTTP en question.
Maintenant s'il y en a rï¿œellement besoin, il est fort probable qu'il n'y
en a pas besoin de maniï¿œre synchrone. Je prendrais donc l'URL que me donne
l'utilisateur et (aprï¿œs un ï¿œventuel simple test syntaxique), la stocke
quelque part. Aprï¿œs un processus asynchrone indï¿œpendant traite toutes les
URLs en attente.
Ainsi :
- il est complￜtement dￜcorrￜlￜ du serveur web, et ne peut pas planter ce
dernier ni permettre un contrï¿œle quelconque, si tant soit peu ï¿œvidemment
qu'on le sï¿œpare correctement (exemple: utilisateur diffï¿œrent, rï¿œpertoires
sï¿œparï¿œs, droits prï¿œcis, etc.)
- si curl ou n'importe quel client est vulnï¿œrable, on arrï¿œte
temporairement les vï¿œrifications, ou on change de client, etc. Tout ceci
sans consï¿œquences pour le service web, et a priori assez simplement parce
qu'on aura qu'une dizaine de lignes de code spￜcifiques pour cette tￜche ￜ
corriger, plutï¿œt qu'une ï¿œventuelle non nï¿œgligeable partie du code (PHP ou
non) du serveur web, dￜs qu'on n'a pas pensￜ ￜ mettre ca proprement dans
une fonction/un fichier ￜ part.
Ok, c'est plus ￜ complexe ￜ ￜ mettre en oeuvre, mais ca utilise les bonnes
pratiques de la sￜcuritￜ (sￜparation des processus, donner toujours le
minimum de droits pour faire une tï¿œche, etc.)
Cette approche asynchrone ne fonctionne pas pour des besoins comme ceux
d'OpenID, d'oￜ toutes les prￜcautions explorￜes plus haut, sans que cela
soit exhaustif ï¿œvidemment.
Tout ce qui prï¿œcï¿œde est ï¿œvidemment en grande partie complï¿œtement
indￜpendant ￜ la fois du client HTTP en question (curl) et du langage (PHP).
Aprￜs il faut ajouter les failles de sￜcuritￜ propres ￜ ces deux ￜlￜments.
Pour curl lui-mï¿œme par exemple :
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=curl
(en particulier la plus rï¿œcente
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4850
est problï¿œmatique pour ce qui nous intï¿œresse ici)
Pour PHP et sa sￜcuritￜ, trop de liens ￜ mentionner :-)
ￜ noter que personnellement, pour moi, allow_url_fopen est mieux ￜ Off,
donc pas de fopen('http://...') comme ￜvoquￜ au dￜbut.
(mￜlanger les ressources ￜ locales ￜ comme les fichiers sur le disque dur
du serveur et les ressources ￜ distantes ￜ accessibles par HTTP/FTP/etc.
en supprimant toute distinction entre les deux me paraï¿œt ï¿œtre une
mauvaise chose, en tout cas du point de vue de la sￜcuritￜ ; cela illustre
une faￜon gￜnￜrale de penser aux problￜmes de sￜcuritￜ que je donne en
cours, ￜ savoir que quand une information change de contexte, ou qu'on
perd le contexte, cela crￜￜ un risque. Cf toutes les attaques type XSS,
etc.)
Olivier Miakinen
dￜtaillￜe, ￜ laquelle je ne rￜpondrai qu'en partie (mais j'ai bien tout lu).
Le 07/07/2008 22:30, Patrick Mevzek a ï¿œcrit :
>
> [...]
>
> Voici quelques exemples de choses [...] auxquelles
> il faut penser, c'est ￜ dire des URLs ennuyeuses :
>
> [ liste d'exemples ]
Je me rends. ;-)
> il faut probablement veiller ￜ ne faire que du HTTP/HTTPS
Voire que du HTTP. Le besoin de Pascale est de valider une page perso,
pas de se connecter ￜ un service bancaire.
Cela dit, comme tu l'expliquais, une simple analyse syntaxique devrait
suffire. Et sinon, peut-ￜtre une requￜte DNS, non ? Tu n'as pas parlￜ de
cette ￜventualitￜ, alors que justement pour le contrￜle des adresses de
courriel c'est toi qui conseillais d'en faire une tandis que moi je
l'estimais inutile...
> L'appelant devient la source d'un certain trafic (une requï¿œte HTTP), comme
> dï¿œlï¿œgataire du client qui a soumis l'URL. Il est alors *responsable* de ce
> trafic, comme l'est un proxy HTTP. [...]
Oui, c'est juste. Mï¿œme pour un simple HEAD il pourrait se le voir reprocher.
> Maintenant s'il y en a rï¿œellement besoin, il est fort probable qu'il n'y
> en a pas besoin de maniï¿œre synchrone. Je prendrais donc l'URL que me donne
> l'utilisateur et (aprï¿œs un ï¿œventuel simple test syntaxique), la stocke
> quelque part. Aprï¿œs un processus asynchrone indï¿œpendant traite toutes les
> URLs en attente.
> Ainsi :
> - [ deux bonnes raisons pour le faire ]
Oui, c'est une excellente suggestion, ￜ se rappeler car cela pourrait
servir dans d'autres situations.
> ￜ noter que personnellement, pour moi, allow_url_fopen est mieux ￜ Off,
> donc pas de fopen('http://...') comme ￜvoquￜ au dￜbut.
[OUI]
> (mￜlanger les ressources ￜ locales ￜ comme les fichiers sur le disque dur
> du serveur et les ressources ￜ distantes ￜ accessibles par HTTP/FTP/etc.
> en supprimant toute distinction entre les deux me paraï¿œt ï¿œtre une
> mauvaise chose, en tout cas du point de vue de la sￜcuritￜ ; [...]
Absolument.
Et encore merci pour cette rï¿œponse.
--
Olivier Miakinen
Patrick Mevzek
> Cela dit, comme tu l'expliquais, une simple analyse syntaxique devrait
> cette éventualité, alors que justement pour le contrôle des adresses de
> courriel c'est toi qui conseillais d'en faire une tandis que moi je
> l'estimais inutile...
Oui, parce que je fais cette différence (certes faible et discutable)
entre les deux cas :
- quand on demande une adresse email, en général on va réellement en avoir
besoin c'est à dire envoyer un email dans le futur, que ce soit un «
Bienvenu » au début, une newsletter, un rappel de mot de passe, etc.
Bref c'est une ressource « chaude ».
- dans le cas exposé, si j'ai bien compris, l'URL du site n'est qu'un
élément de la fiche d'identification, cela ne joue pas de rôle particulier
dans le service fourni, au mieux on met un lien en face du nom de
l'utilisateur et voila. Donc si l'URL ne pointe pas vers une ressource
accessible (le test DNS permettant d'éliminer certains cas triviaux de
ressources non accessibles), cela ne dégrade pas significativement le
service proposé, et cela n'embête en fait que l'internaute qui va cliquer
sur le lien, et pas le serveur qui gère la base d'utilisateurs renseignés
avec une URL. D'où mon avis d'en faire le « minimum » au moment où l'on
recueille l'URL de l'utilisateur, et d'éviter de dépendre de ressources
externes (que ce soit le DNS ou le serveur HTTP pointé, ces deux éléments
étant en-dehors du contrôle du gestionnaire du serveur web qui recuille
l'URL, alors qu'un test syntaxique impose juste une bonne bibliothèque
locale pour faire ca, et aucune dépendance externe).
Donc, compte tenu de cette différence, le test DNS ne me paraît pas
primordial ici. Mais il peut en tout cas être fait bien plus facilement et
avec moins de risques (mais pas aucun, a CNAME b + b CNAME a c'est
embêtant) qu'une requête HTTP.
Olivier Miakinen
>
> - quand on demande une adresse email, en général on va réellement en avoir
> besoin c'est à dire envoyer un email dans le futur, que ce soit un «
> Bienvenu » au début, une newsletter, un rappel de mot de passe, etc.
> Bref c'est une ressource « chaude ».
> - dans le cas exposé, si j'ai bien compris, l'URL du site n'est qu'un
> élément de la fiche d'identification, cela ne joue pas de rôle particulier
> dans le service fourni, au mieux on met un lien en face du nom de
C'est très clair. Encore merci.
> Donc, compte tenu de cette différence, le test DNS ne me paraît pas
> primordial ici. Mais il peut en tout cas être fait bien plus facilement et
> avec moins de risques (mais pas aucun, a CNAME b + b CNAME a c'est
> embêtant) qu'une requête HTTP.
Oui.
Cordialement,
--
Olivier Miakinen
Pascale
news:48728777$1...@neottia.net:
> Voire que du HTTP. Le besoin de Pascale est de valider une page perso,
> pas de se connecter à un service bancaire.
Tout à fait : nos inscrits sont des associations, et en 4 ans, personne ne
nous a jamais demandé de pouvoir saisir une adresse en https://
Le http:// est mis automatiquement parce que c'est autant de risques
d'erreurs en moins (: (on contrôle qu'il n'est pas entré 2 fois).
> Cela dit, comme tu l'expliquais, une simple analyse syntaxique devrait
> suffire.
On en avait une, mais sûrement insuffisante (et puis les regexp et moi,
hummmm... (: ). Difficile de déjouer les sournoiseries du style adresse de
site chez Free à laquelle l'utilisateur ajoute soigneusement un www. au
début...
Depuis que je fais le contrôle avec fopen on a quand même beaucoup moins de
déchet, ce qui nous évite autant de courriers pour dire « vous vous êtes
trompés, SVP veuillez corriger,... ».
À chaque inscription, un message nous est envoyé et nous vérifions quand
même manuellement l'existence de l'URL, car le contrôle actuel ne renvoie
pas d'erreur par exemple si le nom de domaine est abandonné et que le site
est redirigé vers un portail quelconque de services commerciaux ou encore,
si l'utilisateur confond adresse courriel et URL.
Récemment, on a eu un cas assez curieux : une assoc' très sérieuse de
juristes nous rentre une adresse de site qui lue en diagonale paraît
cohérente et lorsque nous l'essayons, nous atterrissons sur un forum Dragon
Ball Z ! En fait, la personne de l'assoc' qui avait saisi les informations
s'était trompée et avait mis wwww au lieu de www et, pour une raison qui
m'échappe, cette adresse était redirigée sur ce fameux forum...
> Oui, c'est juste. Même pour un simple HEAD il pourrait se le voir
> reprocher.
Comment, c'est MAL, ce que je fais ?...
Je veux bien me contenter d'une analyse syntaxique, mais ça me paraît plus
que très compliqué d'obtenir quelque chose d'efficace.
--
Pascale
Pascale
news:48736516$0$25171$426a...@news.free.fr:
> - quand on demande une adresse email, en général on va réellement en
> avoir besoin c'est à dire envoyer un email dans le futur, que ce soit
> un « Bienvenu » au début, une newsletter, un rappel de mot de passe,
> etc. Bref c'est une ressource « chaude ».
Il faut surtout que les visiteurs du site puissent joindre les inscrits
(via un formulaire, l'adresse courriel n'est jamais visible).
> - dans le cas exposé, si j'ai bien compris, l'URL du site n'est qu'un
> élément de la fiche d'identification, cela ne joue pas de rôle
> particulier dans le service fourni, au mieux on met un lien en face du
> nom de l'utilisateur et voila. Donc si l'URL ne pointe pas vers une
> ressource accessible (le test DNS permettant d'éliminer certains cas
> triviaux de ressources non accessibles), cela ne dégrade pas
> significativement le service proposé, et cela n'embête en fait que
> l'internaute qui va cliquer sur le lien
Oui, et ça, on veut pas... Nous tenons au maximum à ce que les données
soient à jour et fiables, ce qui est une lutte de tous les jours (-;
--
Pascale
Patrick Mevzek
>> Voire que du HTTP. Le besoin de Pascale est de valider une page perso,
>> pas de se connecter à un service bancaire.
>
> Tout à fait : nos inscrits sont des associations, et en 4 ans, personne ne
> nous a jamais demandé de pouvoir saisir une adresse en https://
> Le http:// est mis automatiquement parce que c'est autant de risques
> d'erreurs en moins (: (on contrôle qu'il n'est pas entré 2 fois).
Oui cela ne servira probablement à rien mais c'était une remarque en
passant pour penser à ce qu'on exclut, si on prend le cas des «
validations d'email », il y a tellement de routines qui interdisent les
adresses avec un TLD de plus de 3 caractères (et avec ce qui a été annoncé
récemment, ca va faire des ravages).
> À chaque inscription, un
> message nous est envoyé et nous vérifions quand même manuellement
> l'existence de l'URL, car le contrôle actuel ne renvoie pas d'erreur par
> exemple si le nom de domaine est abandonné et que le site est redirigé
> vers un portail quelconque de services commerciaux
Et donc, même la requête HTTP ne sert « à rien », s'il faut après une
validation humaine sur le contenu, chose que vous ne pourrez de toute
façon pas automatiser à 100%.
> Je veux bien me contenter d'une analyse syntaxique, mais ça me paraît
> plus que très compliqué d'obtenir quelque chose d'efficace.
Utiliser une bibliothèque toute faite.
Je vois :
http://pear.php.net/package/Net_URL2
qui dit :
Easy parsing of Urls
(je n'ai vérifié ni si c'est facile, ni si c'est correct syntaxiquement
parlant)
Pascale
news:4873c47f$0$6429$426a...@news.free.fr:
> Oui cela ne servira probablement à rien mais c'était une remarque en
> passant pour penser à ce qu'on exclut, si on prend le cas des «
> validations d'email », il y a tellement de routines qui interdisent
> les adresses avec un TLD de plus de 3 caractères (et avec ce qui a été
> annoncé récemment, ca va faire des ravages).
Quid ? quomodo ?... (:
> Et donc, même la requête HTTP ne sert « à rien », s'il faut après une
> validation humaine sur le contenu, chose que vous ne pourrez de toute
> façon pas automatiser à 100%.
Disons qu'on cherche à éviter en amont un maximum d'erreurs afin de ne pas
avoir à écrire aux gens (ce qui suppose de surveiller ensuite s'ils ont
corrigé ou pas).
> Utiliser une bibliothèque toute faite.
> Je vois :
> http://pear.php.net/package/Net_URL2
> qui dit :
> Easy parsing of Urls
>
> (je n'ai vérifié ni si c'est facile, ni si c'est correct
> syntaxiquement parlant)
Merci, je l'ai téléchargé... M'enfin, d'ici que je me connecte suffisamment
de neurones pour piger comment l'utiliser et voir si ça fonctionne bien...
--
Pascale