Enviando HTTP 403 como. 200 - “Identificación silenciosa del administrador”

En general…

No devolvería un 200 OK a menos que quiera decirle a los clientes web que hay un recurso disponible en el URI solicitado y que está accesible (por ejemplo, para que los motores de búsqueda lo indexen). . Especialmente, nunca devolvería un 200 OK para áreas protegidas siempre y cuando el cliente solicitante no haya autorizado.

Details…

Permítame intentar proporcionarle un poco de información sobre los códigos de estado HTTP que mencionó:

200 OK 

Le dice a los bots (y geeks) que la solicitud de URI es válida y que el recurso de destino (página html, archivo css, descarga de ZIP, lo que sea) existe y se devuelve junto con ese encabezado.

Qué sucede: al cliente que solicita se le dice que el recurso existe y está disponible. Puede y será indexado por bots como los motores de búsqueda.

403 Forbidden

Le dice a los bots (y geeks) que la solicitud de URI no es válida ya que el cliente que solicita los datos no tiene la autorización adecuada para solicitar ese recurso.

Qué sucede: se le dice al cliente que solicita que el recurso existe pero que no está autorizado a buscarlo. Es como golpear la puerta a la nariz de alguien mientras dice "no se te permite hacer eso" porque se requiere autenticación. Los bots y motores de búsqueda benignos respetarán eso y tratarán este 403 Forbidden casi como si fuera un 404 No encontrado . No volverán a intentar visitar el URI a menos que tengan una buena razón para volver a visitar el URI. Ejemplo: al comprobar nuevos enlaces que apuntan a ese URI.

404 Not Found

Le dice a los bots (y a los geeks) que la solicitud de URI no es válida ya que el URI que se usa no apunta a los datos existentes en el servidor.

Qué sucede: se le dice al cliente que solicita que el recurso no existe. Es como decir "nada aquí, no intentes de nuevo" . Los bots y motores de búsqueda benignos no volverán a intentar visitar el URI a menos que tengan una buena razón para volver a visitar el URI. Ejemplo: al comprobar nuevos enlaces que apuntan a ese URI.

Desde un punto de vista de seguridad ...

Debes siempre devolver el encabezado correcto que coincida con la situación. Además de los obvios motivos del protocolo , permítame darle un ejemplo simple de por qué se necesitan los encabezados correctos: Imagine que alguien malintencionado intenta piratear su sitio. Si siempre devuelve un 200 OK , tendrá dificultades para filtrar las buenas de las solicitudes malas . Pero si usted, por ejemplo, observa una serie de 403 Forbidden en los registros de su servidor, es fácil concretar la marca de tiempo, la IP y el agente de usuario ... lo que le ayuda a filtrar y / o bloquear peticiones del cliente.

Cuando un usuario intente acceder a una página "admin", su navegador obtendrá un código de respuesta HTTP (200, 403 ...) pero también obtendrá una página que seguramente será distinto dependiendo de si el usuario es "un administrador" o "no un administrador". El Javascript que activa la carga puede ver el código pero también la página. Enmascarar el 403 como 200 solo afectará a los atacantes más estúpidos, a los que realmente no les importa, es decir, precisamente a los atacantes menos preocupantes.

Puede observar que cuando un usuario llega a un sitio que requiere autenticación, ese sitio a menudo redirige al usuario a una "página de inicio de sesión". Es decir, el sitio no envía una respuesta 401 (que sería lo que HTTP prescribe ), pero en cambio, una respuesta 200 para una página que simplemente contiene algún texto para consumo humano , el texto que dice "Debe iniciar sesión". Esto no es, y nunca ha sido, una característica de seguridad; sitios para eso porque las ventanas emergentes que muestra el navegador cuando se enfrentan con un 401 son simplemente feas.

Su caso de "403 vs 200" es exactamente el mismo: no quiere hacerlo por razones de seguridad (porque no brindará ninguna seguridad sobre la que se pueda hablar), pero puede querer hacerlo por razones estéticas ( por ejemplo, para redirigir fácilmente a los usuarios no autorizados a una página "no-admin" con buen aspecto).

En mi humilde opinión, esto solo crea un obstáculo muy pequeño para que cualquiera que ataque el sitio lo omita. ¿Eso significa que también falsifica el contenido cuando el inicio de sesión no es válido? ¿Crear un honeypot completo para todos los inicios de sesión inválidos?

La mayoría de los inicios de sesión no válidos no son causados por terroristas que intentan lograr el fin de la civilización como la conocemos, por lo general, es solo el botón de bloqueo de mayúsculas. Por lo tanto, debe informar a los usuarios que la información de autenticación que proporcionaron no fue exitosa.

Si la respuesta de autenticación pretende ser legible por una máquina, hay aún más razones para hacerlo simple e inequívoco (pero es posible que deduzco demasiado de su uso de Javascript).

  

solo enviará ataques a los usuarios que saben que son administradores

... de nuevo tal vez no. Esto, combinado con el código javascript, me hace pensar que hay algo un poco sospechoso en el modelo de seguridad aquí.

Hay muchas cosas que debería hacer para asegurar las transiciones de autenticación, pero creo que falsificar deliberadamente el código de respuesta HTTP en respuesta a credenciales no válidas en un esfuerzo por disuadir a los atacantes es contraproducente.

(Fingir el código de respuesta en respuesta a una solicitud que ya se considera un ataque es otra historia).

Si se trata de un problema, puede implementar encabezado de control de acceso CORS , rechazando / solicitudes falsas que vienen con un origen que no proviene de un dominio de confianza.

Los navegadores compatibles con el encabezado CORS enviarán un encabezado de Origen al realizar una solicitud de origen cruzado, lo que le da al servidor la oportunidad de rechazar / falsificar la solicitud. Si los administradores de su sitio utilizan un navegador que puede realizar solicitudes de CORS pero no son conscientes de los encabezados de CORS, entonces realmente deberían considerar cambiar a un navegador más seguro.