consultando la URL proporcionada por el usuario, ¿cuáles son algunas de las mejores prácticas? [cerrado]

0

Tengo una aplicación web que importa datos de sitios web de terceros al aceptar una URL de un usuario, consultar esa URL y luego analizarla en busca de datos. Estoy algo preocupado por el abuso de la herramienta, así que me pregunto qué mejores prácticas debería implementar para mitigar el abuso. Actualmente, la herramienta solo está disponible para las personas que han creado una cuenta, por lo que cualquier abuso debe ser rastreable a una cuenta en particular.

Específicamente, me preguntaba si la solicitud que envío al sitio web de terceros debería incluir algún encabezado, como la inclusión de una dirección IP del solicitante original (similar a una solicitud de proxy).

    
pregunta Tim Tisdall 10.10.2017 - 16:02
fuente

3 respuestas

2

Cosas que vienen inmediatamente a la mente para proteger otros sitios -

  • Verificar usuarios: como mínimo, mediante verificación por correo electrónico.
  • Limitación de la tasa por dominio. Tanto por usuario como por límites globales.
  • Límites de uso por usuario. También puede convertir esto en un monetizador: mayor uso por una tarifa
  • Verifique Robots.txt en el dominio remoto y si le pide que no ejecute esa solicitud en particular, no lo haga o pídale al usuario que confirme que tiene permiso del propietario del dominio.
  • Deje en claro en su ToS que pasará los detalles del usuario a los sitios donde ocurrió el abuso y retirará los servicios al usuario.
  • Tal vez ofrezca una opción de exclusión para los propietarios de dominios para que su sitio no pueda ser escaneado. Si haces esto, asegúrate de verificar que son los dueños del dominio primero.

También necesitas protegerte. Recuerde que todo el contenido extraído de una URL podría ser proporcionado por el usuario (puede que posea el dominio) y, como tal, podría ser un intento de explotar su propia aplicación.

    
respondido por el Hector 10.10.2017 - 16:19
fuente
2

Hay algunas cosas que vienen a mi mente aquí.

Limite los sitios a los que se puede acceder
En el mejor de los casos, puede crear una lista blanca de sitios aprobados desde donde se pueden importar los datos. Luego puede verificar la URL ingresada en su lista y asumir que es probable que sea válida.
Si eso no es posible, ciertas direcciones deben estar en la lista negra (piense en localhost, 0.0.0.0, ..). Especialmente las direcciones locales (IPv4 e IPv6) podrían usarse para escanear puertos del servidor para acceder a servicios que solo están disponibles desde la máquina local. Tal vez hay un panel de administración accesible desde el localhost. O un sistema de base de datos que se ejecuta localmente en un puerto determinado al que se puede acceder.

Limitar el esquema de URL
Asegúrese de que solo se puedan usar 'http: //' y 'https: //' en las URL proporcionadas. Otro esquema que podría ser utilizado por un atacante es, por ejemplo, 'file: //' para cargar un archivo local desde su servidor. Otros esquemas como por ejemplo 'datos' o 'ftp' también pueden usarse para iniciar un comportamiento no deseado.

Solicitudes salientes con límite de velocidad
Para evitar un gran número de solicitudes salientes a otros sitios, se debe aplicar un límite de velocidad estricto. Para un usuario, un enfriamiento de diez segundos no debería ser un problema. Si alguien deseara usar su servicio para ocultar su identidad mientras hacía otro servicio con una demora de diez segundos, esto dejaría de ser efectivo.

Incluir un encabezado de contacto de abuso
Puede incluir un encabezado con información sobre cómo los administradores pueden comunicarse con usted si se sienten abusados por las solicitudes enviadas por su servicio. Eso hace que sea razonablemente fácil detener cualquier comportamiento equivocado al contactarlo.

No ejecutar scripts
Recomendaría no interpretar ningún script como el código JavaScript en el sitio que solicita.

Escape de la URL
Dependiendo de la herramienta (si la hubiera) que use para consultar el contenido del sitio, asegúrese de evitar la URL para evitar cualquier tipo de contenido o ataques de inyección de comandos en su servidor.     

respondido por el Denis 10.10.2017 - 16:32
fuente
-1

Yo usaría un certificado que el usuario puede emitir de forma similar a un pki si no desea usar un pki real. Así, cualquier usuario que se conecte debe tener el certificado.

    
respondido por el Hugo 10.10.2017 - 18:45
fuente

Lea otras preguntas en las etiquetas