Comment tester la sécurité de son site?
- Auteur de la discussion unlu
- Date de début
- Statut
Pour pouvoir tester la sécurité d'un site, il faut faire un audit du code source pour déceler les fonctions dangereuses, voir si toutes les entrées utilisateur sont bien protégées, si tous les paramètres sont bien vérifiés, voir s'il n'y a pas de possibilité d'injection SQL.
Tout ceci doit se faire manuellement, il n'y a pas de recette miracle.
Tout ceci doit se faire manuellement, il n'y a pas de recette miracle.
julio38 a dit:
lol
Tu reçoit chaque jour des centaines d'attaques et les hébergeurs ne peuvent rien dire.
Ce n'est pas pour une dizaine d'attaques en plus que ça va changer quelque chose :wink:
De plus, tu peux lancer des attaques: si ton hébergeur est professionnel et s'il sécurise bien son infrastructure, alors il n'y verra rien du tout.
De toute façon, c'est la seule méthode fiable à 100%.
WRInaute occasionnel
Par exemple ici : http://www.phpsecure.info/v2/.php?zone=pArticlejeffousse a dit:
Le soucis avec l'insulte d'un hacker, c'est qu'il peut y arriver et alors, le site est mal en point. Tandis que si c'est le webmaster, il peut stopper son attaque s'il voit que ça marche ou alors remettre en ordre ce qu'il a défais.
On part du principe que l'on veut détruire ce site et pas "rechercher une faille". De cette manière, on trouve toujours une porte dérobée et on teste la sécurité du site en question.
De plus, il est conseillé de tester soi-même la sécurité de son propre site avant de le mettre en ligne afin d'être sur qu'il n'a pas de failles critiques (mais, il se peut qu'un hacker plus expérimenté puisse trouver une faille).
Je suis désolé de te contredire mais il suffit de lancer des attaques "connues" (type injection SQL, DOS...) et puis lancer d'autres attaques que l'on connaît et que l'on sait effectué afin de tester différents points de sécurité dans un site.shrom a dit:
On part du principe que l'on veut détruire ce site et pas "rechercher une faille". De cette manière, on trouve toujours une porte dérobée et on teste la sécurité du site en question.
De plus, il est conseillé de tester soi-même la sécurité de son propre site avant de le mettre en ligne afin d'être sur qu'il n'a pas de failles critiques (mais, il se peut qu'un hacker plus expérimenté puisse trouver une faille).
cedfr a dit:
Si tu crois qu'il *suffit* de tester des attaques connues pour tester la sécurité d'un site, je ne donne pas cher de celle de ton/tes site/s. De cette façon, on se protège des script kiddies pas du hack de son site.
C'est bien parce qu'il est impossible d'automatiser les tests de sécurité d'un site qu'il existe des concours comme ceux de NGSEC.
Les erreurs de conception et de programmation sont rarement standards, un type d'injection SQL peut marcher sur un site et pas sur un autre. D'autant que le nombre de failles potentielles est quasi infini.
La seule solution fiable est de faire un audit du code source pour détecter les mauvaises conceptions et les failles potentielles.
jeffousse a dit:
Il n'y a pas de prix défini, c'est en fonction du nombre de lignes de code, de la compréhension des codes source ...
Je crois que la plupart des boites se basent sur un tarif aux 100 lignes de code comme pour le bug de l'an 2000 ou le passage à l'euro.
Attention quand même à certains fumistes qui sous prétexte d'un audit vont trouver des failles qui n'existent pas.
Je suis désolé, mais ce n'est pas en regardant son code source qu'on va svoir si le site est vulnérable ou non. Cette tâche (de contrôler son code) est a effectué lors du codage (tout bon webmaster se doit de vérifier au moment de son codage, l'intégrité de ce dernier).shrom a dit:
Ensuite, il est beaucoup plus intéressant de tenter des attaques pour les déceler (car j'ai le regret de t'annoncer que tu ne trouvera pas dans ton code ceci: echo"attention, ici ça ouvre une faille").
Pour ma part, j'ai toujours tester mes sites en les attaquants (comme beaucoup de mes confrères avec qui je parle quotidiennement).
Le mieux est de passer à l'acte et de se mettre dans la peau d'un hacker. Il faut se demander ce que pourrait faire l'autre et anticiper (ça parait même logique).
Cependant, chacun sa technique: si tu pense que visionner ton code source est le mieux et le plus fiable (tâche, soit dit en passant, que tu aurais du déjà effectuée), alors c'est ton choix. Mais, je continu à penser et à affirmer que la meilleure méthode est de tester directement la sécurité du site.
:wink:
cedfr a dit:
C'est le seul moyen de vérifier que toutes les variables sont vérifées, que les instructions SQL sont bien protégées, qu'on n'utilise pas d'inclusions de fichiers trop fortement liés avec une variable.
Au passage, les équipes d'OpenBSD ( système d'exploitation le plus réputé pour la sécurité ) procède de cette façon.
Mais tous les codeurs ne sont pas forcément sensibilisés à la sécurité. A forciori, un codeur PHP est incapable de savoir si on peut récupérer des infos en cas de débordement de tampon depuis un core dump.
Combien de webmasters croient qu'il suffit de stocker en md5 un mot de passe dans une BDD pour que celui-ci soit protégé ?
C'est intéressant en effet, encore faut il en avoir les compétences, le temps pour tester toutes les combinaisons possibles sur un script et on passe a côté de 90% des failles.
De cette façon, on ne se protège que des script kiddies.
Vous les attaquez sur les méthodes que vous connaissez, mais le propre d'un crakage de système est justement de ne pas utilisez des méthodes toutes faites.
J'ai personellement l'habitude avec mes confrères de faire auditer le code par quelqu'un d'autre et je récupère du code à auditer de la part d'autres.
Sauf qu'il est impossible d'anticiper toutes les attaques à moins d'être au niveau des meilleurs hackers tandis que de voir qu'une variable n'est pas protégée dans le code source s'identifie en quelques secondes.
Je suis d'accord que le minimum est de contrôler son code source, mais il est de la responsabilité du webmaster de faire cette vérification avant de le publier et de le mettre en ligne.
Je persiste dans l'idée que "tenter d'attaquer" son site est la meilleure solution (mais elle peut être combiné au contrôle du code source qui peut être effectué en premier et l'attaque permet de confirmer le niveau de sécurité du site).
Si vous parlez de référence, je peux alors citer la moitié des sociétés multinationales qui engagent des hackeurs professionnels pour des contrats et qui ont pour fonction de mettre à rude épreuve les script, les sites afin de vérifier plusieurs points de sécurité.
Dans tous les cas, que ce soit avec le code source ou les attaques, il se peut que le site soit vulnérable puisque de nouvelles failles peuvent apparaître chaque minute (celles-ci peuvent ne pas être désseler dans le code source, mais également peuvent être inconnues du webmaster qui tente d'"hacker son site").
Je pense donc que les deux méthodes sont complémentaires même si je persiste dans mon idée qu'un webmaster soucieux de la qualité de son site effectue un contrôle lors du codage afin de ne pas créer de failles et substitu certaines fonctions qui peuvent ouvrir une porte dérobée par d'autres qui seraient mieux appropriées niveau sécurité des données.
Je persiste dans l'idée que "tenter d'attaquer" son site est la meilleure solution (mais elle peut être combiné au contrôle du code source qui peut être effectué en premier et l'attaque permet de confirmer le niveau de sécurité du site).
Si vous parlez de référence, je peux alors citer la moitié des sociétés multinationales qui engagent des hackeurs professionnels pour des contrats et qui ont pour fonction de mettre à rude épreuve les script, les sites afin de vérifier plusieurs points de sécurité.
Dans tous les cas, que ce soit avec le code source ou les attaques, il se peut que le site soit vulnérable puisque de nouvelles failles peuvent apparaître chaque minute (celles-ci peuvent ne pas être désseler dans le code source, mais également peuvent être inconnues du webmaster qui tente d'"hacker son site").
Je pense donc que les deux méthodes sont complémentaires même si je persiste dans mon idée qu'un webmaster soucieux de la qualité de son site effectue un contrôle lors du codage afin de ne pas créer de failles et substitu certaines fonctions qui peuvent ouvrir une porte dérobée par d'autres qui seraient mieux appropriées niveau sécurité des données.
cedfr a dit:
Justement, ce sont des hackers pro qui font autre chose que de tester s'il y a des possibilités d'injection SQL et autres bouts de scripts trouvés sur phpsecure.info ou fr.comp.securite.
Ils testent avant tout la sécurité du système ( firewall, config des serveurs, possibilités de DOS, tentative de MIM, scan infrastructure réseau, social engineering ... ).
Au passage, les normes internationales de sécurité ( COBIT, ISO ... ) requises pour du code devant être fournit à l'armée par exemple reposent sur des audits et non sur des tests d'intrusion.
shrom a dit:
Mais je n'ai jamais dis que les tests s'arrêtaient aux injections SQL ou qu'il y avait utilisation de scripts divers. Je pense que chaque webmaster doit pouvoir tester la sécurité de son site en lançant des attaques variées, divers (et un peu plus solides que de simples injections de requettes dans la base de donnée).
Si chaque webmaster faisait l'effort de bien tester les facettes de son site (en tentant de récupérer des mots de passe, des id de sessions, des données sécurisées...), on aurait moins de soucis avec le hackage des sites. Certes, les hackeurs arriveront, pour certains, à trouver d'autres failles ou déroberont une porte d'entrée; mais il est essentiel que les webmasters testent la vulnérabilité de leurs sites respectifs.
Lire le code, c'est bien beau; mais il est nécessaire de passer à l'acte défois et de voir en temps réel ce qui peut se passer.
:wink:
Tout nouvel inscrit sur ce forum, je tombe sur se sujet piquant et interessant.
Concernant la sécurité d'un site internet, deja il faut distinguer deux types d'attaques :
- 1.Celles visant votre serveur
- 2.Celles visant votre code
1.Celles visant votre serveur
Du coté du serveur cette sécurité passe donc plus souvent par l'hébegeur, ou par vous dans le cas ou vous vous heberger. Cela consiste principalement a se tenir au courant des dernieres failles de sécurité paru, sur certaine version des applications. Windows propose régulierement des MAJ de sécurité. Du coté de UNIX l'open source favorise enormement les défense, puisque des qu'une faille est trouvé, elle est tres rapidement corrigée.
Il faut donc se tenir au courant des processus qui tourne sur notre serveur :
Vous pourrez vous tenir au courant de ces failles sur :
http://www.zataz.net/alertes/
https://login.passport.net/ppsecure/uis ... 6&id=42814
http://www.vulnerabilite.com/users/
http://www.frsirt.com/
- 2.Celles visant votre code
Les failles de sécurité conernant votre code, se concentre principalement sur le CSS (Cross Site Scripting), et autre erreur d'include mal gérer. Ce type d'erreur vient de mauvais code de la part du webmaster. erreur entrainant par exemple la donnée de nom d'utilisateur, ou de login. L'audit de code concerne donc cette partie uniquement.
Sur le fait de tester des attaques connu sur son serveur c'est bien mais pas suffisant. Cela evitera comme cela a ete dit les attaques de Script Kiddies qui font les sites par centaines pour voire ceux faillible. Alors qu'un hacker visera votre site en particulier et tentera toute sortes de vulnerabilité.
Pour une sécurité optimum, il faudrai faire un audit de code, et de réseau.
Kali_
Concernant la sécurité d'un site internet, deja il faut distinguer deux types d'attaques :
- 1.Celles visant votre serveur
- 2.Celles visant votre code
1.Celles visant votre serveur
Du coté du serveur cette sécurité passe donc plus souvent par l'hébegeur, ou par vous dans le cas ou vous vous heberger. Cela consiste principalement a se tenir au courant des dernieres failles de sécurité paru, sur certaine version des applications. Windows propose régulierement des MAJ de sécurité. Du coté de UNIX l'open source favorise enormement les défense, puisque des qu'une faille est trouvé, elle est tres rapidement corrigée.
Il faut donc se tenir au courant des processus qui tourne sur notre serveur :
- - OS (Debian, OpenBSD, FreeBSD, Windows Server...)
- Apache
- Mail
- FTP
- SQL
- PhpMyAdmin
Vous pourrez vous tenir au courant de ces failles sur :
http://www.zataz.net/alertes/
https://login.passport.net/ppsecure/uis ... 6&id=42814
http://www.vulnerabilite.com/users/
http://www.frsirt.com/
- 2.Celles visant votre code
Les failles de sécurité conernant votre code, se concentre principalement sur le CSS (Cross Site Scripting), et autre erreur d'include mal gérer. Ce type d'erreur vient de mauvais code de la part du webmaster. erreur entrainant par exemple la donnée de nom d'utilisateur, ou de login. L'audit de code concerne donc cette partie uniquement.
Sur le fait de tester des attaques connu sur son serveur c'est bien mais pas suffisant. Cela evitera comme cela a ete dit les attaques de Script Kiddies qui font les sites par centaines pour voire ceux faillible. Alors qu'un hacker visera votre site en particulier et tentera toute sortes de vulnerabilité.
Pour une sécurité optimum, il faudrai faire un audit de code, et de réseau.
Kali_
Nouveau WRInaute
Mes compétences en php augmente de jour en jour et la c'est la sécurité qui me préoccupe, quelqu'un pourrait il me conseiller pour moi même attaquer mes site et trouver les failles.
En effet je lis pas mal de tutos sur la sécurité php et autre mais je ne trouve aucun scrypt d'attaque simple ou autre qui me permettrait de trouver mes faille et donc d'améliorer ma maniére de coder. Si quelqu'un souhaite attaquer un de mes sites pour voir qu'il me MP on verra cela ensemble et je vous en remercie d'avance.
Vision-storm
En effet je lis pas mal de tutos sur la sécurité php et autre mais je ne trouve aucun scrypt d'attaque simple ou autre qui me permettrait de trouver mes faille et donc d'améliorer ma maniére de coder. Si quelqu'un souhaite attaquer un de mes sites pour voir qu'il me MP on verra cela ensemble et je vous en remercie d'avance.
Vision-storm
WRInaute accro
Topic déterré mais je répond quand même:
Pour les failles d'injection SQL: SQL Inject Me: https://addons.mozilla.org/en-US/firefox/addon/7597
Un phpinfo() pour la sécurité: http://phpsec.org/projects/phpsecinfo/
Pour des failles exploitables: http://www.milw0rm.com/
Autre site intéressant: http://www.phpsecure.info/
Injection de headers dans la fonction mail(): http://www.phpsecure.info/v2/article/MailHeadersInject.php
Pour les failles d'injection SQL: SQL Inject Me: https://addons.mozilla.org/en-US/firefox/addon/7597
Un phpinfo() pour la sécurité: http://phpsec.org/projects/phpsecinfo/
Pour des failles exploitables: http://www.milw0rm.com/
Autre site intéressant: http://www.phpsecure.info/
Injection de headers dans la fonction mail(): http://www.phpsecure.info/v2/article/MailHeadersInject.php
Nouveau WRInaute
spout a dit:
je te remercie de ta reponse cela va me donner de la lecture car le sujet est vraiment d'actualité pour moi et que je sais juste sécuriser mes formulaire
Il date ce topic !
Mais je me pose la même question. Dans le numéro 227 de Capital ils parlent d'un logiciel gratuit iranien qui peut être utilisé facilement pour détecter les failles d'un site. J'imagine bien que personne ne me donnera le nom de ce logiciel, mais je me demande néanmoins comment faire pour le trouver et lui soumettre mon site web pour envoyer les failles à mon agence web pour corrections.
Mais je me pose la même question. Dans le numéro 227 de Capital ils parlent d'un logiciel gratuit iranien qui peut être utilisé facilement pour détecter les failles d'un site. J'imagine bien que personne ne me donnera le nom de ce logiciel, mais je me demande néanmoins comment faire pour le trouver et lui soumettre mon site web pour envoyer les failles à mon agence web pour corrections.
iXav a dit:
En effet, remonter un topic de 2005...
J'ai lu le même article sur Capital, il est quand même assez exagéré. Gros titre pour public non-geek. Il existe beaucoup de logiciels de ce genre, certains conçus par des hackers, d'autres par des sociétés d'audits (j'en avais même testé un gratuit l'année dernière, assez efficace).
Finalement je l'ai trouvé, mais étant sur Mac... et puis je n'ai pas envie d'installer ce truc.
Est-ce que je peux demander à mon agence de web (qui fait notre site web et qui est censé s'assurer qu'il soit solide niveau sécurité) de le tester en ma présence ? (en ma présence = plus par curiosité que par manque de confiance).
Est-ce que je peux demander à mon agence de web (qui fait notre site web et qui est censé s'assurer qu'il soit solide niveau sécurité) de le tester en ma présence ? (en ma présence = plus par curiosité que par manque de confiance).
WRInaute accro
Confier la vérification d'un produit a celui qui le fabrique est sûrement la plus mauvaise idée qui soit (bonjour l'impartialité).iXav a dit:
Sinon si ce sont des pros tu n'a pas besoins de cela a moins que le site soit "critique" tu saura vite ce qui ne colle pas en production (comprend qu'il est sûrement acceptable de perdre 3 francs 6 sous suite a un hack que de dépenser une fortune dans un audit pas forcement concluant si tu n'a pas les moyens de vérifier sa véracité). Suffit de gérer les sauvegardes et d'avoir la possibilité de changer vite les accès au serveur et a la base.
Après il te reste aussi le test grandeur nature pour ce qui est de classique en lançant ici une url tu aura sûrement de la visite ciblée :wink:
Le truc c'est que je n'ai pas envie de donner ce logiciel à un ami qui à un PC... si ce logiciel a un spyware ou que-sais-je, ce serait pas cool.
Avec mon prestataire ça m'ennuierait aussi bien sûr, mais j'aurai moins de craintes, ils sont censés savoir ce qu'ils font. :mrgreen:
Avec mon prestataire ça m'ennuierait aussi bien sûr, mais j'aurai moins de craintes, ils sont censés savoir ce qu'ils font. :mrgreen:
Bonjour à tous,
pour une fois que je trouve un sujet ou je peu me permettre de vous éclairez je vais le faire.
Premièrement il existe 2 type de faille que l'on peu exploiter au travers d'un site web:
1-Une faille qui provient du site en lui même (Faille dans le code php... )
2-Une faille qui provient du serveur (Faille qui provient par exemple d'un mauvais paramétrage serveur)
Dans le premier type de faille il en existe plusieurs type :
-Rfi (Remote file inclusion)
-Lfi (Local file inclusion)
-Xss (Cross Site Scripting)
-SQL injection
-Remode code execution
-CRSF (Cross Site Request Forgering)
Dans le deuxième type de faille il y en a tellement que je vais faire une petite liste exhaustive :
-Buffer Overflow
-HTTP Authentication Bypass
-Directory Traversal Vulnerability
-Authentication Bypass Vulnerability
-Source Disclosure
-......
Et les traditionnelles Brute-force ssh, ftp et mail...
J'espère vous avoir fait partager un peu plus de mon expérience en sécurité informatique.
PS:
J'ai plusieurs logiciel qui me permettent de faire des audits.Je peu vous en faire un "gratuitement'.Envoyer votre demande par MP.
pour une fois que je trouve un sujet ou je peu me permettre de vous éclairez je vais le faire.
Premièrement il existe 2 type de faille que l'on peu exploiter au travers d'un site web:
1-Une faille qui provient du site en lui même (Faille dans le code php... )
2-Une faille qui provient du serveur (Faille qui provient par exemple d'un mauvais paramétrage serveur)
Dans le premier type de faille il en existe plusieurs type :
-Rfi (Remote file inclusion)
-Lfi (Local file inclusion)
-Xss (Cross Site Scripting)
-SQL injection
-Remode code execution
-CRSF (Cross Site Request Forgering)
Dans le deuxième type de faille il y en a tellement que je vais faire une petite liste exhaustive :
-Buffer Overflow
-HTTP Authentication Bypass
-Directory Traversal Vulnerability
-Authentication Bypass Vulnerability
-Source Disclosure
-......
Et les traditionnelles Brute-force ssh, ftp et mail...
J'espère vous avoir fait partager un peu plus de mon expérience en sécurité informatique.
PS:
J'ai plusieurs logiciel qui me permettent de faire des audits.Je peu vous en faire un "gratuitement'.Envoyer votre demande par MP.
- Statut
Discussions similaires
