php - para - meta tags online
Principales técnicas para evitar el ''raspado de datos'' de una base de datos del sitio web (14)
¿Qué hay de crear algo similar a la protección de troll del tablero de anuncios ... Si se detecta un rasguño (quizás una cierta cantidad de accesos por minuto desde una IP, o un rastreo dirigido que se parece a un rastreo del mapa del sitio), entonces puede comenzar a presentar datos de basura, como cambiar un par de dígitos del número de teléfono o agregar nombres tontos a los campos de nombre.
¡Apaga esto para las IP de Google!
Estoy configurando un sitio con PHP y MySQL que es esencialmente un front-end web para una base de datos existente. Comprensiblemente, mi cliente está muy interesado en evitar que alguien pueda hacer una copia de los datos en la base de datos, pero al mismo tiempo quiere que todo esté disponible públicamente e incluso un enlace "ver todos" para mostrar todos los registros en la base de datos.
Si bien he puesto todo en marcha para evitar ataques, como los ataques de inyección de SQL, no hay nada que impida que alguien vea todos los registros como html y ejecute algún tipo de script para analizar estos datos en otra base de datos. Incluso si tuviera que eliminar el enlace "ver todos", alguien podría, en teoría, usar un proceso automatizado para revisar cada registro uno por uno y compilarlos en una nueva base de datos, esencialmente comprimiendo toda la información.
¿Alguien tiene alguna buena táctica para prevenir o incluso disuadir esto que podrían compartir?
El uso de algo como Adobe Flex, un front-end de la aplicación Flash, solucionaría esto.
Aparte de eso, si desea que sea fácil para que los usuarios accedan, es fácil para los usuarios copiar.
Hay pocas maneras de hacerlo, aunque ninguna es ideal.
Presentar los datos como una imagen en lugar de HTML. Esto requiere un procesamiento adicional en el lado del servidor, pero no sería difícil con las librerías de gráficos en PHP. Alternativamente, puede hacer esto solo para solicitudes que superen cierto tamaño (es decir, todas).
Cargue un shell de página, luego recupere los datos a través de una llamada AJAX e insértelo en el DOM. Utilice las sesiones para establecer un hash que debe devolverse con la llamada AJAX como verificación. El hash solo sería válido por un cierto tiempo (es decir, 10 segundos). Esto es solo agregar un paso adicional que alguien tendría que saltar para obtener los datos, pero evitaría el simple raspado de la página.
Mi sugerencia sería que esto es ilegal de todos modos, por lo menos tiene un recurso legal si alguien raspa el sitio web. Entonces, tal vez lo mejor sea incluir un enlace al sitio original y dejar que la gente se deshaga de él. Cuanto más se rasguen, más enlaces aparecerán en Internet, creando más y más su pagerank.
Las personas que raspan generalmente no se oponen a incluir un enlace al sitio original, ya que crea una especie de relación con el autor original.
Así que mi consejo es preguntarle a su jefe si esto podría ser lo mejor para la salud del sitio web.
No hay una solución fácil para esto. Si los datos están disponibles públicamente, entonces se pueden raspar. Lo único que puede hacer es hacer la vida más difícil para el raspador haciendo que cada entrada sea un poco única agregando / cambiando el HTML sin afectar el diseño. Esto posiblemente dificultaría que alguien cosechara los datos usando expresiones regulares, pero aún no es una solución real y diría que cualquiera que esté suficientemente determinado encontraría la manera de lidiar con eso.
Le sugeriría que le diga a su cliente que esta es una tarea inalcanzable y que continúe con las partes importantes de su trabajo.
No sé por qué disuadirías esto. El cliente está ofreciendo los datos.
Es de suponer que crean valor de una manera única que no se refleja de forma trivial en los datos.
De todas formas.
Puede verificar el navegador, la resolución de la pantalla y la dirección IP para ver si es probable que sea algún tipo de raspador automático.
La mayoría de las cosas, como cURL y wget, a menos que estén configuradas cuidadosamente, obviamente no son navegadores.
Normalmente, para eliminar una cantidad decente, uno tiene que hacer cientos, miles (y más) solicitudes a su servidor. Le sugiero que lea esta pregunta relacionada sobre el desbordamiento de pila:
¿Cómo evitas que los guionistas golpeen tu sitio web cientos de veces por segundo?
Quite las manos del teclado y pregúntele a su cliente por qué quiere que los datos estén visibles pero no puedan ser raspados.
Está pidiendo dos cosas incongruentes y tal vez tener una discusión sobre su razonamiento dará algunos frutos.
Puede ser que él realmente no quiera que sea accesible al público y que necesite agregar autenticación / autorización. O puede decidir que hay valor en abrir realmente una API. Pero no lo sabrás hasta que lo pidas.
Realmente no hay nada que puedas hacer. Puede intentar buscar un proceso automatizado en su sitio, pero al final ganarán.
Regla de oro: si quiere tener algo para usted, manténgalo fuera de Internet.
Si bien no hay nada que impida que una persona determinada raspe el contenido disponible públicamente, puede hacer algunas cosas básicas para mitigar las preocupaciones del cliente:
Límite de velocidad por cuenta de usuario, dirección IP, agente de usuario, etc. - esto significa que restringe la cantidad de datos que un grupo de usuarios en particular puede descargar en un período de tiempo determinado. Si detecta que se transfiere una gran cantidad de datos, cierra la cuenta o la dirección IP.
Requerir JavaScript: para garantizar que el cliente tenga cierta semejanza con un navegador interactivo, en lugar de una araña barebones ...
RIA: haga que sus datos estén disponibles a través de una interfaz de aplicación de Internet enriquecida. Las cuadrículas basadas en JavaScript incluyen ExtJs, YUI, Dojo, etc. Los entornos más ricos incluyen Flash y Silverlight como menciones a 1kevgriff .
Codificar los datos como imágenes. Esto es bastante intrusivo para los usuarios normales, pero puede codificar algunas de sus tablas de datos o valores como imágenes en lugar de texto, lo que anularía la mayoría de los analizadores de texto, pero no es infalible, por supuesto.
robots.txt - para negar arañas web obvias, agentes de usuarios de robots conocidos.
Agente de usuario: *
No permitir: /
Utilice metatags robot. Esto dejaría de conformar las arañas. Esto evitará que Google te indexe por ejemplo:
<meta name = "robots" content = "noindex, follow, noarchive">
Existen diferentes niveles de disuasión y la primera opción es probablemente la menos intrusiva.
Si los datos se publican, es visible y accesible para todos en Internet. Esto incluye a las personas que desea que lo vean y las personas que no quiere ver.
No puedes tenerlo de ambas maneras. Puede hacerlo para que los datos solo puedan ser visibles con una cuenta, y las personas crearán cuentas para absorber los datos. Puede hacerlo para que los datos solo puedan ser visibles desde las direcciones IP aprobadas, y las personas seguirán los pasos para obtener la aprobación antes de ingerirla.
Sí, puede hacer que sea difícil de conseguir, pero si desea que sea conveniente para los usuarios típicos, también debe hacerlo para los maliciosos.
Trate de usar Flash o Silverlight para su interfaz.
Si bien esto no puede detener a alguien si está realmente determinado, sería más difícil. Si está cargando sus datos a través de servicios, siempre puede usar una conexión segura para evitar el raspado de intermediarios.
Utilice el hecho de que los raspadores tienden a cargar muchas páginas en una sucesión rápida para detectar comportamientos de raspado. Muestre un CAPTCHA por cada carga de n páginas durante x segundos, y / o incluya un retraso de crecimiento exponencial para cada carga de página que se vuelve bastante larga cuando, por ejemplo, se cargan decenas de páginas por minuto.
De esta manera, los usuarios normales probablemente nunca verán su CAPTCHA, pero los raspadores alcanzarán rápidamente el límite que los obliga a resolver los CAPTCHA.
forzar un reCAPTCHA cada 10 cargas de página para cada IP única