|
|
 |
|
 |
 |
 |
 |
 |
 |
 |
|
Alertes récentes
|
|
|
jaime mieux...
|
|
|
Éviter les botnet dans vos applications web
|
Sommaire:
Introduction
Un botnet c'est quoi?
Le résultat
Sauvegarder les post
Ne pas confirmer
Éviter les fopen()
Conclusion
Références
|
1. Introduction.
|
Ce document vous donnera des trucs et astuces afin d'éviter l'utilisation botnet de vos sites et applications Web. Nous ne pouvons garantir qu'en suivant ces conseils, vos applications Web seront sans failles. Nous croyons que l'application de ces techniques peut grandement améliorer la sécurité de vos productions.
|
2. Un Botnet c'est quoi?
|
Un Botnet est une machine vulnérable qui exécute une tâche. Tandis que la majorité sont des applications cachées dans votre ordinateur de maison, certains sites vulnérables et applications Web peuvent aussi être considérés comme botnet. Un site qui peux étre utilisé par une autre site pour effectuer une opération. Lorsqu'un site utilise un autre site pour obtenir de l'information, on dit que cette opération est un mashup. Mais lorsqu'une application utilise et automatise un site pour générer une action qui produit un résultat sur ce site (comme l'envoi d'un courriel par exemple), on dit qu'il s'agit d'un Botnet.
Selon les dires de wikipedia, les botnet peuvent étre très efficaces:
"A botnet consisting of several hundred compromised machines can effortlessly churn out millions of messages per day. This also complicates the tracing of spammers." [1]
|
3. Le résultat
|
Le résultat de ce genre d'attaque peut varier. Le plus commun consiste en l'envoi de spam. Une application externe (un site vulnérable) peut utiliser vos formulaires afin d'envoyer du spam. Il est très fréquent d'utiliser un site vulnérable afin que l'attaque ne puisse être retracée. Ainsi nous avons ce schéma décrivant une attaque type, non retra&ccdil;able.
Il est très facile de trouver un site vulnérable sur l'Internet. Puisque énormément de webmestres utilisent des applications libre source, lorsqu'une vulnérabilité est découverte, elle affecte des milliers de sites. Enfin, notez que dans le schéma ci-dessus, le Site A est facultatif, un personne totalement stupide pourrait agir sans converture. La dynamique des publications en sécurité de l'information est, en soit, un autre débat.
Comme nous le disions, ces vulnérabilités entraînent souvent l'envoi de spam, qui représente pour certains un quotidien plutôt déplaisant, mais peuvent aussi amener à un salissage du nom de domaine ou de la réputation de l'hébergeur.
|
4. Sauvegarder les post
|
Afin déviter l'automatisation des méthodes de type POST, nous conseillons fortement la réglementation du nombre de requêtes pouvant être faites quotidiennement sur vos formulaires par la même personne. Nous avons produit ci-dessous un schéma de table SQL pouvant être utilisée pour ce type de régulation.
CREATE TABLE post_log (
id int(11) not null auto_increment,
self varchar(255) default null,
ip varchar(255) default null,
hitdate datetime default null,
primary key (id)
) ENGINE=MyISAM;
Ainsi, vous pouvez effectuer un compte des envois POST faits par la méme ip. Ceci est trés important quand vous envoyés un courriel avec l'exécution de votre script. D'autres méthodes peuvent être utiliser pour corriger ce problème, tel l'utilisation de captcha. [2]
|
5. Ne pas confirmer
|
Si le dernier point vous semblait être de la paranoïa, peut-être serez vous convaincu par celui-ci. Si votre formulaire envoie un courriel, que le formulaire peut être envoyé des milliers de fois par le même utilisateur et qu'aucune sécurité n'est utilisée pour vérifier que l'utilisateur est bien humain, alors votre site est probablement vulnérable. Même si le contenu du courriel ne peut être modifié, c'est une faille suffisante pour congestionner le serveur d'envois de courriel ou encore le serveur de réception.
De plus, il est possible qu'à la suite d'une telle attaque, le serveur victime soit ajouté sur une liste noire [3], répertorié comme serveur spammeur.
|
6. Éviter le fopen() sur un URL interne
|
Les gros hébergeurs tel que Godaddy et compagnie ne permettent pas les fonctions fopen() vers d'autres sites. La raison est très simple, un fopen() peut facilement devenir un proxie. Ce dernier peut parraître exagéré, mais nous avons rencontré ce genre de problème dans le passé. Un engin de recherche effectuait le filtrage des mots clés pour ensuite les passer dans un fopen() vers un autre script qui effectuait la recherche dans la base de données. Ce dernier script effectuant la recherche n'effectuait pas de filtrage adéquat, laissant possibles les attaques par injection SQL.
La companies était pourtant relativement grosse (environ 30 employés), comme quoi même les entreprises bien établies peuvent commettre des erreurs. Enfin, nous pouvons considérer que l'utilisation d'un fopen() à l'intérieur d'un même site est une mauvaise pratique.
|
6. Conclusion
|
En conclusion, nous pouvons dire que malgrés les trucs et astuces présentés dans ce document, l'erreur est humaine, donc toujours possible. Il arrive parfois que les budgets de développement d'application Web soient tellement serrés que l'aspect sécurité soit négligé. C'est pourquoi il est primordial de toujours évaluer les risques et dommages pouvant être causés suite à une faille de sécurité bien exploitée et par le fait même, inclure les frais relatifs à la sécurisation de votre application dans l'estimation initiale des frais de développement.
|
8. Références
|
[1] http://en.wikipedia.org/wiki/E-mail_spam#Using_other_people.27s_computers
[2] http://www.captcha.net/
[3] http://www.spamhaus.org
|
|
|
| partenaires |
|
Hébergement
Rapide et sécuritaire
1.866.509.4313 |
|
|
|
| | |
