Audit sécurité de sites web, quels outils?

[assilabox]

Salam,

 

Pour faire un audit de sécurité d'un site web il faut analyser le code et tester les possibilités d'intrusion et d'injection de code.

 

Quels outils utilisez-vous pour réaliser les test d'injection? (je connais quelques uns comme wapiti mais je voudrais avoir les avis de personnes qui ont l'habitude de réaliser ce genre d'audit)

 

Y a t-il des outils pour rechercher des vulnérabilités dans le code?

 

Merci et A++

[Fr0mY0u]

franchement, les softs pour ce genre de choses ne sont pas interessants.

 

la meilleure chose c'est de faire cela manuellement.

Grosso modo, pour savoir s'il y a une faille de type sql, il suffit de faire deux tests et c'est bon

 

Sinon c'est bien de vouloir automatiser la recherche mais nous ne sommes pas certains du taux de reussite

 

salam

[Intranet]

Je suis d'accord avec Fr0mY0u vaut mieux le faire manuellement c'est plus efficace, ça prend du temps certes mais ça donne un très bon résultat

[assilabox]

Salam,

 

Je suis d'accord avec vous,

 

mais il ne s'agit pas d'un seul site mais de plusieurs, environ 10000 page de code en PHP et 1.000.000 lignes de code!

[Fr0mY0u]

oui je vois ce que vs voulez dire...

Je ne suis pas sur que c'est faisable parce en codant en php, on peut suivre différentes logiques...

 

Or pour une sql injection par exemple (tres basique), il est plus simple et surtout plus rapide d'utiliser un outil qui va faire:

id='

id=1&name='

id=1&name=test&year='

jusqu'a trouver une reponse favorable a une faille sql plutot que d'analyser des milliers de lignes :/

 

Enfin c'est ce que je crois.

De ce coté la je pense qu'il y a pas mal de soft

Modifié le 11 décembre 2008 par Fr0mY0u

[Invité HAVOC]

Personnellement j'utilise Acunetix Web Vulnerability Scanner, il est performant et fiable.

[Boss_Med]

+1 HAVOC et Shadow Security Scanner fait aussi l'affaire (sql + xss).

environ 10000 page de code en PHP et 1.000.000 lignes de code!

je comprend par ça que ta l'accès au code source ?

[Fr0mY0u]

+1 HAVOC et Shadow Security Scanner fait aussi l'affaire (sql + xss).

 

je comprend par ça que ta l'accès au code source ?

 

oui je pense qu'il veut trouver des failles dans des cms genre joomla, wordpress...

[assilabox]

je comprend par ça que ta l'accès au code source ?

 

Oui j'ai accès au code source, c'est pour un audit sécurité et merci pour Shadow Security Scanner

 

oui je pense qu'il veut trouver des failles dans des cms genre joomla, wordpress...

 

non c'est pour des sites web écrits a la main, je me demande si il y a aussi des outils pour évaluer des vulnérabilités dans le code

 

Personnellement j'utilise Acunetix Web Vulnerability Scanner, il est performant et fiable.

 

Merci Havoc

Modifié le 11 décembre 2008 par assilabox

[Invité HAVOC]

Pour ce qui est du scanner dont j'ai parlé, j'ai l'habitude de l'utiliser et il effectue en gros les choses suivantes :

- Vérification des failles XSS.

- Vérification des failles SQL.

- Vérification de la sécurisation du serveur (services, serveur HTTP,...etc).

 

En général, quand on code un site on peut commettre des failles SQL ou XSS, voir des failles de type Cookies Injection (je ne sais plus si le scanner les vérifies ou pas).

Il faut donc prendre de bons réflexes de programmation : Magic Quotes, htmlentities(), addslash()... sont des fonctions à user et abuser !

[Fr0mY0u]

+1

[Boss_Med]

j'avais un script shell simple que j'ai moi même créé qui évalue la recherche des failles RFI + command exec mais je l'ai perdu si je le trouve je le poste ici dsl .

pour les failles (sql blind ou bien login bypassing .. + xss + etc ...) y a pas un autre moyen que chercher à la main regarde ces 2 là par ex :

[/url]1 et 2.

PS:si ce sont des cms publique tu peu tjr chercher sur les différents sites de vulnérabilité.

[Fr0mY0u]

sinon il y a aussi les bots IRC ...

[assilabox]

des failles RFI

 

c'est quoi les failles RFI ?

[SecDz]

mais il ne s'agit pas d'un seul site mais de plusieurs, environ 10000 page de code en PHP et 1.000.000 lignes de code!

 

C'est un travail d'équipe de pros....en plus rien ne garantira qu'ils trouveront tous. Il y a des sociétés qui font ça comme business, mais pas en Algérie et ça coute très cher.

 

Si tu cherches des outils gratuits, ce lien maintien une liste intéressante en plusieurs formats (html, pdf, mm)

 

Pour le RFI voir ça par exemple

[Fr0mY0u]

le RFI c'est une faille qui permet d'inclure une page externe au site web

on peut par exemple inclure un shell present sur un autre server. c'est la plus grande faille a mon avis qu'on puisse trouver parcque l'on peut rapidement devenir administrateur non pas du site mais du server

[Invité HAVOC]

Acunetix Scanner vérifie aussi la présence de failles RFI (qu'on peut aussi appeler dans certains cas : faille include, en référence à une fonction PHP qui peut aboutir à une telle faille).

[assilabox]

Merci SecDz, Fr0mY0u, Havoc et Boss_Med, je connaissais la technique sans connaitre son nom

 

Pour vérifier si des vulnérabilités de type RFI existent dans le code il faudrait :

 

• Analyser comment les fonctions include et require ont été utilisées dans le code
  
• Analyser s'il n'existe pas dans le code des champs de formulaire de type file ou des fonctions php comme move_uploaded_file qui permettent l'upload de fichier avec une extension exécutable sur le sreveur.
  

Y'a t-il autre chose a vérifier?

[meriem]

Salam tout le monde ,

Y a aussi la fonction "htmlspecialchars" qu'il faut toujours l'aligner aux autres fonctions afin de se prémunir des éventuelles attaques terroristes .........( non la je plaisante ), je m'explique: "si on se retrouve en face d'un site ou l'on pourrait insérer des données, l'internaute posterait n'importe quoi du texte, du code HTML ou bien du javascript , vbscprit, ce dernier sera enregistré dans la BD, permettant ainsi d'afficher des choses que le développeur n'aurait pas souhaiter voir sur son site.

[meriem]

c'est encore moi , en abordant ce thème il y a un fait qui me dérange, c'est celui de mettre le login et le passe de l'administrateur sur le code php en clair, est-ce que ça représente un danger ? est ce qu'il y a une autre façon de se connecter au serveur en mode crypté???

(désolée de poser d'autres questions mais je crois que c'est toujours en relation avec le sujet sinon j'ouvrirais un autre topic si ce dernier nécessite un espace à part). Merci.

[Invité HAVOC]

c'est encore moi , en abordant ce thème il y a un fait qui me dérange, c'est celui de mettre le login et le passe de l'administrateur sur le code php en clair, est-ce que ça représente un danger ? est ce qu'il y a une autre façon de se connecter au serveur en mode crypté???

(désolée de poser d'autres questions mais je crois que c'est toujours en relation avec le sujet sinon j'ouvrirais un autre topic si ce dernier nécessite un espace à part). Merci.

 

 

Pour commencer, insérer le mot de passe admin dans un script php ne cause pas de problème d'attaques à distance comme le langage PHP est server-side, par contre, il est sujet au attaque local car pour obtenir le mot de passe il suffira de lire simplement le script PHP... ce qui est faisaible si le hacker a accès à la machine ou s'il a réussi à uploader sur le serveur un shell.

 

Concernant le cryptage des données lors de leur envoi vers le serveur, on peut utiliser des protocoles comme le HTTPS.

[tewfik]

meriem dit :

 

c'est encore moi , en abordant ce thème il y a un fait qui me dérange, c'est celui de mettre le login et le passe de l'administrateur sur le code php en clair, est-ce que ça représente un danger ? est ce qu'il y a une autre façon de se connecter au serveur en mode crypté???

(désolée de poser d'autres questions mais je crois que c'est toujours en relation avec le sujet sinon j'ouvrirais un autre topic si ce dernier nécessite un espace à part). Merci.

 

Bonsoir,

 

Comme a dit Havoc, il s'agit d'un risque surtout local. Ceci dit, je vous rappel le bug qui a eu surtout du succès avec la disclosure des scripts php du site websms de l'opérateur ota.

Le bug concernait la lecture des sources php en remote, y compris la config et les mots de passes de la base de données[1].

 

Vos scripts sont, apres tout, parsés par un serveur web, qui peut etre sujets à failles. Ne faites pas confiance à celui qui sert vos scripts, prenez vos précautions.

 

Imaginez votre sécurité d'un point de vue pessimiste : vous ne voudriez pas que l'attaquant puisse, en lisant vos codes de base de donnée, se propager au reste de vos données, et surtout pas les données de vos utilisateurs/clients.

 

A mon sens, avec php, le mieux serait de crypter les scripts les plus sensibles. Il existe des outils pour cela, mais si vous êtes dans l'administration systeme, je vous conseillerais tres fortement de crypter en utilisant votre propre extension php (en partant du template fourni) et de crypter vos codes en asymmetric.

 

Bien entendu, l'attaquant pourrait acceder à cette extension, extraire la clé privée, decrypter vos codes, et se propager davantage. Cependant, ces taches demandent et du temps et du savoir-faire. Comme la sécurité est une notion relative, votre role sera de minimiser le risque.

 

Aussi, mefiez vous du faux sentiement de sécurité : ce n'est pas en encodant vos scripts en base64 qu'ils sont à l'abri.

 

Je crois que Havoc, en parlant de https, voulait parler du lien entre le client et vos scripts. Si vous souhaitez échanger l'authentification en crypté avec votre serveur de base de données, je vous conseillerais plutot de vous poser la question suivante : ferais-je confiance au lien qui lie mes scripts au serveur de base de donnée ?

 

Bon courage.

 

[1] un ptit echantillon par ici :

( je me permet de le poster car je pense qu'il a du faire le tour du net, et que de toute façon le bug a été patché )

 

fichier config.php :

 

if($_SERVER['SERVER_NAME'] == 'thor.tis.hr')
{
 define('ORA_USER', 'web2sms');
 define('ORA_PWD', 'web2sms');
 define('ORA_SID', 'TIS');
}else
{
 define('ORA_USER', 'websms');
 define('ORA_PWD', smsbew');
 define('ORA_SID', '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.10.20)(PORT=1521)))(CONNECT_DATA=(SID=TWEBSMS)))');
}
// (...)
?>

[Invité HAVOC]

Une réflexion personnelle au sujet des mots de passe admin m'amène à penser qu'il est préférable d'enregistrer son mot de passe admin hashé en MD5 dans son script PHP que de le mettre dans la BD, car si un pirate a un accès en lecture/ecriture à votre BD il peut facilement s'approrier le compte admin sans avoir à décrypter le mot de passe hashé en MD5, il lui suffit en effet d'éditer votre BD pour insérer le hash MD5 de son propre mot de passe.

 

De même, vos mots de passe doivent au minimum avoir 10 caractères car les rainbow tables permettent de nos jours d'obtenir facilemement un passe de 8 caractère hashé en MD5, il faut donc de long mot de passe pour éviter de telles méthodes.

 

Il faut aussi penser à ne jamais utiliser le mot de passe "root" d'une BD dans ses scripts PHP, il faut utiliser un simple compte ayant le droit sur les tables utilisées par le site uniquement, ainsi... si on se fait attaqué on garde toujours la main sur sa BD, vous imaginez si un hacker qui accède à votre BD avec un compte root et qu'il change le mot de passe du compte? On se retrouve un peu embêté quand même ^^

 

Bref... la sécurité se vérifie sur différents points ! (maillons de la chaine)

[Invité salimdz]

les dix vulnérabilités de sécurité applicatives web les plus critiques

 

les dix vulnérabilités de sécurité applicatives web les plus critiques

edition 2007

 

a1 – cross site scripting (xss)

a2 – failles d’injection

a3 – execution de fichier malicieux

a4 – référence directe non sécurisée à un objet

a5 – cross site request forgery (csrf)

a6 – fuite d'information et traitement d'erreur incorrect

a7 – violation de gestion d'authentifications et de sessions

a8 – stockage de données cryptographiques non sécurisé

a9 – communications non sécurisées

a10 – défaillance dans la restriction des accès url

[SecDz]

Dans une approche de sécurisation "multicouches" ou "défense en profondeur" il serait utile de mettre en place un firewall applicatif ou WAF......bien comprendre que c'est une brique parmi d'autres (audit de code entre autres)