¿Pueden los piratas informáticos encontrar tokens secretos que se pasan a las solicitudes HTTP GET?

Confías en un principio llamado seguridad a través de la oscuridad , que generalmente está mal visto. Existe un principio ampliamente aceptado llamado Principio de Kerckhoffs que dice:

  

Un criptosistema debe ser seguro, incluso si todo sobre el sistema, excepto la clave, es de conocimiento público.

Una forma alternativa y más general del principio se llama máxima de Shannon:

  

El enemigo conoce el sistema.

Básicamente, esto significa que no debes nunca confiar en un mecanismo de oscuridad para proteger tu sistema. Debe asumir que los atacantes conocen el código y pueden descubrir cualquier vulnerabilidad como esta.

Como tal, su mecanismo de acceso debe implicar una autenticación adecuada, por ejemplo, ingresar un conjunto de credenciales que se pueden verificar en el lado del servidor, usando hashing de contraseña adecuado . Esto significa que incluso si un atacante conoce su código, no puede explotarlo.

Como se menciona en otra parte de este sitio (vea esto y this , su "secreto" se puede descubrir en los registros del servidor web y muchos otros medios.

El uso de esto como un medio de control de acceso se conoce como "seguridad a través de la oscuridad" y se puede descubrir fácilmente.

Sin embargo, algunos sitios menos seguros usarán una variación de este tema y lo usarán para proteger una sesión después de que un usuario inicie sesión. La idea aquí es usar un valor HTTP GET en lugar de una cookie de sesión. No recomendaría implementarlo usted mismo, pero está incluido en muchos paquetes de software (Microsoft Windows Identity Foundation), por ejemplo, cuando las cookies del lado del cliente están deshabilitadas.

Si esta es una función privilegiada que no debe ser ejecutada por cualquier persona, entonces debe proteger su función al verificar la identidad del usuario (por ejemplo, la identificación de la sesión).

Además, debe asegurarse de tener un token CSRF, si alguien envía un enlace a uno de sus usuarios con esa solicitud GET y el usuario la abre, podría terminar ejecutando una función que no deseaba. ejecutar.

Ahora, dependiendo de lo que haga su función y de cuál sea el parámetro GET, los "piratas informáticos" pueden descubrir qué hace.

Puede ser que su función solo muestre información (inmutable) que pueda estar bien. Me gustaría referirme a esta pregunta: ¿Qué tan poco probable es que se adivine un enlace de Google Doc?

Además de las otras respuestas publicadas, existe el problema general de que los navegadores web y sus usuarios generalmente no consideran que las URL sean información confidencial. Se almacenan en archivos históricos, marcadores, etc., sin cifrado por los navegadores, y los usuarios los compartirán con gusto por correo electrónico, mensajería instantánea o servicios de intercambio de URL / marcadores en la nube, sin esperar una sola URL para regalar su acceso. También pueden capturarse en registros de proxy web, registros de firewall y otros intermediarios, que nuevamente consideran que la información confidencial no se encuentra en la URL.

Si alguno de ellos es visto por una araña web, o si un usuario simplemente copia la URL de su navegador a su blog o wiki, será indexado y fácil de encontrar para los piratas en los motores de búsqueda.

Ocultar y no proteger la funcionalidad no es una buena práctica de seguridad.

Hay formas indirectas de que esta funcionalidad puede filtrarse, como:

• Las vulnerabilidades en otras partes de su aplicación web pueden llevar a un acceso arbitrario a los archivos haciendo que su archivo index.php sea legible.
• El texto HTML y el código JavaScript pueden filtrar el nombre de la variable oculta o puede sugerir el tipo de esa funcionalidad oculta.
• Mensajes de error que contienen fragmentos del código something .
• Adivinar los nombres de variables comunes o forzarlos de forma brutal.
• La copia de seguridad o el uso de varias versiones de ese index.php con diferentes extensiones ( index.bak , index.php.1 , etc.) puede hacer que el contenido sea legible.

En primer lugar, asegúrese de que el token secreto sea lo suficientemente largo y cambie con cada acceso. Usar siempre el mismo token es muy arriesgado, por las razones señaladas en las otras respuestas.

Cuando se usan diferentes tokens, todavía hay varias amenazas aquí, que se pueden mitigar (parcialmente):

• Detección de HTTP: si la conexión no está encriptada, una persona con un rastreador de wifi o un hombre en el medio en algún lugar de la red puede ver el token y usarlo de inmediato. Asegúrese de que la conexión esté siempre a través de HTTPS.
• Pérdida de datos del usuario: si el usuario marca la URL o la envía por correo y la computadora del usuario es hackeada / robada, el secreto está fuera. Esta amenaza se puede mitigar haciendo que el token sea válido solo por un breve lapso de tiempo. Si el token se puede vincular a una función de usuario como la dirección IP o el agente de usuario, la seguridad aumenta un poco (pero la usabilidad puede verse afectada).
• Pérdida de datos del lado del servidor: lo más fácil de mitigar es la pérdida de los registros HTTP: la corta vida útil del token y la vinculación con la ayuda de usuario también están aquí.

Otra buena estrategia es restringir el nivel de acceso de los usuarios identificados solo por un token: permite solo acciones muy específicas y potencialmente no peligrosas.