D'aucuns connaîtraient-ils un moyen de se protéger du screen scraping? Le
risque étant de me faire "absorber" ma base de données en multipliant les
requêtes avec un analyseur de code html.
Je pense à:
- coder le contenu dans un fichier jpeg avant de l'afficher;
- limiter le nombre d'accès sur une période donnée, puis progressivement
pénaliser la performance (mais là, je ne sais pas vraiment comment au plan
technique)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
Le Tue, 13 Jul 2004 09:46:42 +0000, Lc a écrit :
Je pense à: - coder le contenu dans un fichier jpeg avant de l'affich
C'est quand même un emmerdement considérable, si l'utilisateur normal a plus de quelques lettres à recopier. Il ne faut pas essayer de se protéger au détriment des utilisateurs "légaux" du système.
- limiter le nombre d'accès sur une période donnée, puis progressivement pénaliser la performance (mais là, je ne sais pas vraiment comment au plan technique)
Si tes données sont affichées par un script genre php/asp/perl/etc c'est très facile; tu peux utiliser l'adresse IP source pour limiter le nombre de requètes sur une période donnée, avec le défaut important que les gens derrière un routeur (par exemple les employés d'une entreprise) risquent d'être pénalisés; ou mieux utiliser les sessions avec cookies pour empêcher un utilisateur donné de revenir trop souvent -par exemple en n'autorisant qu'un nombre limité d'accès avec la même session, ou en utilisant le cookie pour identifier l'utilisateur et compter au niveau du serveur le nombre d'accès.
Enfin là ce n'est pas du domaine de la sécurité, mais de la programmation de site web dynamique classique.
-- Les défauts n'apparaissent qu'après que le programme ait passé (avec succès) la phase d'intégration. Loi de Klipstein.
Le Tue, 13 Jul 2004 09:46:42 +0000, Lc a écrit :
Je pense à:
- coder le contenu dans un fichier jpeg avant de l'affich
C'est quand même un emmerdement considérable, si l'utilisateur normal a
plus de quelques lettres à recopier. Il ne faut pas essayer de se
protéger au détriment des utilisateurs "légaux" du système.
- limiter le nombre d'accès sur une période donnée, puis progressivement
pénaliser la performance (mais là, je ne sais pas vraiment comment au plan
technique)
Si tes données sont affichées par un script genre php/asp/perl/etc c'est
très facile; tu peux utiliser l'adresse IP source pour limiter le nombre
de requètes sur une période donnée, avec le défaut important que les
gens derrière un routeur (par exemple les employés d'une entreprise)
risquent d'être pénalisés; ou mieux utiliser les sessions avec cookies
pour empêcher un utilisateur donné de revenir trop souvent -par exemple
en n'autorisant qu'un nombre limité d'accès avec la même session, ou en
utilisant le cookie pour identifier l'utilisateur et compter au niveau du
serveur le nombre d'accès.
Enfin là ce n'est pas du domaine de la sécurité, mais de la
programmation de site web dynamique classique.
--
Les défauts n'apparaissent qu'après que le programme ait passé (avec
succès) la phase d'intégration.
Loi de Klipstein.
Je pense à: - coder le contenu dans un fichier jpeg avant de l'affich
C'est quand même un emmerdement considérable, si l'utilisateur normal a plus de quelques lettres à recopier. Il ne faut pas essayer de se protéger au détriment des utilisateurs "légaux" du système.
- limiter le nombre d'accès sur une période donnée, puis progressivement pénaliser la performance (mais là, je ne sais pas vraiment comment au plan technique)
Si tes données sont affichées par un script genre php/asp/perl/etc c'est très facile; tu peux utiliser l'adresse IP source pour limiter le nombre de requètes sur une période donnée, avec le défaut important que les gens derrière un routeur (par exemple les employés d'une entreprise) risquent d'être pénalisés; ou mieux utiliser les sessions avec cookies pour empêcher un utilisateur donné de revenir trop souvent -par exemple en n'autorisant qu'un nombre limité d'accès avec la même session, ou en utilisant le cookie pour identifier l'utilisateur et compter au niveau du serveur le nombre d'accès.
Enfin là ce n'est pas du domaine de la sécurité, mais de la programmation de site web dynamique classique.
-- Les défauts n'apparaissent qu'après que le programme ait passé (avec succès) la phase d'intégration. Loi de Klipstein.
Nicob
On Tue, 13 Jul 2004 09:46:42 +0000, Lc wrote:
- coder le contenu dans un fichier jpeg avant de l'afficher
Tout dépend du travail que sont prêts à accomplir les "voleurs" pour accéder à ces infos. Si tu veux te protéger aussi de l'OCR sur les fichiers d'images, tu devras employer des techniques compliquant grandement la lecture (cf. les Hotmail/Geektools/...) et risquant donc de rebuter les lecteurs "classiques".
- limiter le nombre d'accès sur une période donnée, puis progressivement pénaliser la performance (mais là, je ne sais pas vraiment comment au plan technique)
Le problème est l'identification de la source :
- un cookie classique (ou identifiant ASP ou PHP ou ...) pourra être manipulé côté client
- un check sur l'IP source risque de pénaliser ceux situés derrière un proxy d'entreprise ou de FAI, mais impose l'utilisation d'une base de proxies pour être contournée
Un grand classique, qui marche étonnament bien, c'est le lien invisible qui n'est suivi que par les bots et où le script appellé banni la source :)
Plus de détails sur le contexte permettrait de voir les risques encourus et les moyens de protection à mettre en oeuvre (watermarking pour identifier les fuites, ...)
Nicob
On Tue, 13 Jul 2004 09:46:42 +0000, Lc wrote:
- coder le contenu dans un fichier jpeg avant de l'afficher
Tout dépend du travail que sont prêts à accomplir les "voleurs" pour
accéder à ces infos. Si tu veux te protéger aussi de l'OCR sur les
fichiers d'images, tu devras employer des techniques compliquant
grandement la lecture (cf. les Hotmail/Geektools/...) et risquant donc de
rebuter les lecteurs "classiques".
- limiter le nombre d'accès sur une période donnée, puis
progressivement pénaliser la performance (mais là, je ne sais pas
vraiment comment au plan technique)
Le problème est l'identification de la source :
- un cookie classique (ou identifiant ASP ou PHP ou ...) pourra être
manipulé côté client
- un check sur l'IP source risque de pénaliser ceux situés derrière un
proxy d'entreprise ou de FAI, mais impose l'utilisation d'une base de
proxies pour être contournée
Un grand classique, qui marche étonnament bien, c'est le lien invisible
qui n'est suivi que par les bots et où le script appellé banni la source :)
Plus de détails sur le contexte permettrait de voir les risques
encourus et les moyens de protection à mettre en oeuvre (watermarking
pour identifier les fuites, ...)
- coder le contenu dans un fichier jpeg avant de l'afficher
Tout dépend du travail que sont prêts à accomplir les "voleurs" pour accéder à ces infos. Si tu veux te protéger aussi de l'OCR sur les fichiers d'images, tu devras employer des techniques compliquant grandement la lecture (cf. les Hotmail/Geektools/...) et risquant donc de rebuter les lecteurs "classiques".
- limiter le nombre d'accès sur une période donnée, puis progressivement pénaliser la performance (mais là, je ne sais pas vraiment comment au plan technique)
Le problème est l'identification de la source :
- un cookie classique (ou identifiant ASP ou PHP ou ...) pourra être manipulé côté client
- un check sur l'IP source risque de pénaliser ceux situés derrière un proxy d'entreprise ou de FAI, mais impose l'utilisation d'une base de proxies pour être contournée
Un grand classique, qui marche étonnament bien, c'est le lien invisible qui n'est suivi que par les bots et où le script appellé banni la source :)
Plus de détails sur le contexte permettrait de voir les risques encourus et les moyens de protection à mettre en oeuvre (watermarking pour identifier les fuites, ...)
