¿Devuelve el código de respuesta HTTP incorrecto a propósito?

  

¿Alguien ha pensado alguna vez en hacer esto?

Sí, en realidad hubo una charla sobre esto exactamente en el punto de configuración 21 ( video , slides ).

Su conclusión fue que trabajar con códigos de respuesta como seguridad ofensiva a veces puede resultar en una desaceleración severa de los escáneres automáticos, escáneres que no funcionan y una cantidad masiva de falsos positivos o falsos negativos (obviamente no hará nada para nada) escaneos manuales).

Si bien la seguridad por oscuridad nunca debe ser su única defensa, puede ser beneficiosa como defensa en profundidad (otro ejemplo: se recomienda no transmitir números de versión de todos los componentes usados).

Por otra parte, una API REST debería ser lo más limpia posible, y responder con códigos HTTP intencionadamente incorrectos puede ser confuso para los desarrolladores y clientes legítimos (esto es un problema un poco menos para los navegadores, donde los usuarios no lo hacen. en realidad ver los códigos). Debido a esto, no lo recomendaría en su caso, pero sigue siendo una idea interesante.

En realidad no ralentizará al atacante en una cantidad apreciable, pero causará que cualquier futuro desarrollador que trabaje en su plataforma se sienta realmente molesto con usted. También puede hacer que algunas características interesantes de las bibliotecas de solicitudes HTTP no sean tan agradables, ya que funcionan con información incorrecta.

Esta es una forma muy débil de seguridad a través de la oscuridad . Al diseñar un sistema como este, debería pensar en reducir la velocidad de un atacante cientos de años, no en decenas de minutos; de lo contrario, todavía perderá.

  

En lugar de devolver un "401 no autorizado", ¿por qué no devolverlo, por ejemplo? "305 Use Proxy", es decir, a propósito es confuso.

Sí, confundirá a un atacante. Pero para un entrenado, puede que no sea por más de dos segundos sin parar. Y los códigos de estado no son tan útiles, principalmente cuando se trata de nombres de archivos de fuerza bruta.

Diga que tengo una clave válida y puedo observar que devuelve códigos de 200 rangos para mi autenticación. Si cambio un poco en mi clave, y para cada solicitud que devuelvas 305s, inmediatamente pensaré "Hmm. Parece que el desarrollador podría haber arruinado". Si devuelves códigos aleatorios, sabré que fue a propósito y simplemente los ignoraré.

  

la dificultad en la ingeniería inversa de una aplicación de iOS puede disuadir a todos, excepto a los hackers más decididos

Sí, lo hará, pero dado que solo se necesita uno para publicarlo, nuevamente se está desacelerando ...

Esto es seguridad a través de la oscuridad, es decir, no proporciona mucha seguridad en absoluto. La solución que está sugiriendo solo ralentizará a un atacante, no impedirá que utilicen su propio cliente. De hecho, su método de cifrar las solicitudes, dependiendo de su implementación, puede hacer que su aplicación sea menos segura al abrir ataques en otras partes del sistema de cifrado. Se debería invertir su esfuerzo tratando de asegurar las funciones de la API en sí mismas (es decir, hacerles una prueba con el lápiz y protegerlas contra ataques como la inyección de SQL), en lugar de intentar evitar que clientes no autorizados accedan a ellas.

Pero el usuario ya está utilizando su protocolo.

¡Su problema es que la interfaz de su servidor de lo que el usuario puede hacer no es segura!
¡Usted decide qué datos envía su servidor a quién!
(Hola, queridos periódicos en línea. ¡Sí, te estoy mirando!)

Diseñarlo, asumiendo que el usuario es el cliente. No es tu código. Porque él es. No debería importar qué cliente se use.
Su aplicación se ejecuta en una CPU que está bajo el control del hardware del usuario. Su código es solo una lista de comandos / datos, y el usuario y su CPU pueden procesarlo como quieran. Incluyendo no procesándolo.
Él decide lo que hace su CPU. No confunda su gracia de aceptar el código de su aplicación tal como está con el derecho a una ejecución ciega. Tú eres el que confía aquí, y esa confianza es muy fugaz.
Especialmente con tácticas de mala calidad como esta.

En cualquier caso: le entrega al usuario la clave de cifrado y todo, y espera que no lo use él mismo, porque lo puso en algún lugar de su cesta de código. ... Al igual que el DRM, eso es aceite de serpiente y nunca puede funcionar.
Solo se necesita una persona una para encontrar dónde colocar la clave. (Ese sería yo, por ejemplo). Todos los demás solo tienen que buscarlo en Google.

Pero me sorprende que solo piense en cifrar el protocolo contra el usuario, en lugar de protegerlo de los ataques de intermediarios.
Suponiendo que la razón por la que se hace esto (sí, le estoy hablando nuevamente a la "industria del contenido"): si su usuario es su enemigo, tal vez debería buscar un modelo de negocio basado en la imparcialidad y en el que todos ganen. en lugar de timar al usuario y tener que lidiar con la reacción.

P.S .: Ignora todas las respuestas de "seguridad a través de la oscuridad". Esta es una falacia que resulta en un comportamiento correcto pero aún se basa en suposiciones no válidas. Usarlo como un argumento, es, en el mejor de los casos, amateur y no es realmente competente.
En realidad, la seguridad de toda es a través de la oscuridad. Algunos son más oscuros (= mejor disfrazados). La razón real por la que esto es malo es porque lo que llamamos seguridad real es un bazillion más oscuro, lo que le otorga una actual (estadística) de alta oscuridad confiable, en oposición a muy Oscuridad simple que es demasiado probable para que alguien pueda surgir de la nada.

Como ya explicaron otros, la seguridad por oscuridad ralentiza al máximo a un atacante.

En su caso específico, diría que no tendrá un efecto apreciable. Para llegar a este punto, su atacante ya tuvo que aplicar ingeniería inversa a su aplicación y extraer la clave privada. Eso significa que tu atacante no es un idiota y sabe lo que está haciendo. Un poco de oscuridad le costará menos tiempo de lo que le toma implementarlo.

Como ya lo han mencionado otros, estás proponiendo usar Security by Obscurity. Si bien esta técnica tiene su propósito, considere lo siguiente antes de elegir adoptar este enfoque:

• Proporcionar soporte técnico para su API. El uso de códigos de respuesta HTTP engañosos dificulta que alguien que no sea usted proporcione soporte. Deben considerar si la situación en particular está enviando el código de respuesta correcto o si está enviando uno oscuro. Si decide seguir siendo el único contacto para cualquier solicitud de asistencia, esto no debería ser un problema.
• ¿Qué es un "usuario malicioso"? Tenga cuidado al categorizar una solicitud como maliciosa, ya que puede tener efectos adversos. Supongamos que se determina que una IP está enviando tráfico malicioso y se utilizan contramedidas. Ahora suponga que la misma IP es en realidad un proxy con cientos o miles de usuarios detrás. Ahora has aplicado tu contramedida a todos ellos. Este mismo principio puede aplicarse a la identificación de actividad maliciosa en encabezados y / o cuerpos.
• El código de la aplicación es el más lento. La solicitud debe atravesar toda la pila para finalmente llegar a la lógica de "seguridad". Esta arquitectura no se escala bien y es lenta. Las solicitudes incorrectas deben detenerse lo antes posible, lo cual es la premisa para utilizar los firewalls de aplicación web (WAF).
• Extendiendo el acceso. En caso de que su API sea accesible para más clientes, entonces se diseñó originalmente para ellos, esos nuevos clientes deberán conocer el posible uso de códigos de respuesta HTTP engañosos.
• Usuarios maliciosos persistentes. Como han mencionado otros, esta técnica es solo un golpe de velocidad.

Mejor enfoque

Concentre su tiempo en la lista blanca de todas las buenas solicitudes conocidas. Esto es mucho más fácil que intentar identificar todas las posibles solicitudes erróneas. Cualquier cosa que no aparezca en la lista blanca debe obtener inmediatamente un código de respuesta adecuado, como HTTP 400 o HTTP 405, si filtra por verbos HTTP (como ejemplos). Preferiblemente esto sucede antes de que la solicitud llegue a su código de aplicación.

Junto con las solicitudes permitidas de la lista blanca, asegúrese de que su aplicación esté protegida en base a las Pautas OWASP . Obtendrás resultados mucho mejores si pasas tu tiempo con OWASP, luego intentarás determinar qué es un usuario malintencionado y devolver un código de respuesta HTTP desconocido.

Fundamentalmente, NO PUEDES evitar que clientes no autorizados envíen solicitudes. Lo más cercano posible sería tener algún tipo de control criptográfico en el cliente, pero como dijo Sherlock Holmes, "lo que uno puede inventar, otro puede descubrir". (Lo sé con certeza, porque he violado la seguridad del lado del cliente de las personas en varias ocasiones).

En su lugar, cree su API de tal manera que cualquier persona tenga permiso para usarla utilizando clientes personalizados. Hazlo amigable ¿Qué pierdes por eso? Los atacantes atacarán sin importar lo que hagas, y si haces que tu API sea fácil de usar, alguien creará algo en lo que nunca pensaste, y hará que tu servidor sea aún más grande de lo que nunca imaginaste que podría ser. ¿Qué podría hacer un cliente que habla tanto con su API como con alguna otra? ¿Qué innumerables posibilidades existen, y realmente te perjudicará permitirlas?

Yo no haría eso. En general, significa que está creando su propio estándar, lo que hace que:

1. su API será predictiva después de hacer un mapa de sus respuestas http a su significado real. Cambiar las respuestas HTTP podría funcionar en algunos "hackers" que se rendirían después de algunos intentos, pero no lo hará en otros, más decididos. ¿Desea proteger su API solo del tipo anterior, es decir, de 11 años de edad? No lo creo.

2. bastante confusión para los desarrolladores y probadores, especialmente los que están acostumbrados a operar de acuerdo con los estándares globales.

3. Elige de otra manera. Definitivamente hay unos pocos. Últimamente he estado luchando contra el mismo receptor de la cabeza por algunas semanas y se me ocurrieron al menos 2 formas más o menos confiables de lograr las restricciones deseadas [aunque no puedo publicarlas aquí].

Definitivamente hay formas mejores y MUCHO más efectivas de obtener lo que deseas. Intenta ver tu API desde un ángulo diferente ... Si fueras un hacker y tu vida dependiera de hackear esa API, ¿qué harías para tener éxito? ¿Qué debería suceder para que se sienta frustrado en sus intentos de romperlo?

Una buena razón para no hacer esto, especialmente para una aplicación móvil, es que es muy probable que su aplicación esté hablando con su servidor a través de varios proxies, por ejemplo, en la compañía telefónica. La mayoría de las grandes empresas utilizan proxies en su red para intentar proteger sus sistemas de contenido malicioso, y muchas compañías telefónicas reducen la calidad del video o las imágenes en tránsito. También hará que el uso de varias bibliotecas de sistemas para HTTP en su plataforma sea inútil para usted. Un enfoque que se usa comúnmente es derivar alguna clave o token de la información que el usuario probablemente no quiera compartir, como el hashing de su nombre y la información de la tarjeta de crédito. De esta manera, incluso si su aplicación es pirateada, la gente desconfiará de dar la información requerida a un programa aleatorio que descargó, lo que limita la capacidad de compartir cualquier ataque comprobado.

En general, no es una buena idea.

Hice un uso muy específico de este efecto, una vez que tuvo un efecto positivo cuando el anillo de lavado de tarjetas de crédito robado utilizaba el sitio web de un cliente. Hubo algunas características de identificación compartidas solo por las transacciones fraudulentas, así que en lugar de rechazarlas amablemente, el sitio demoraría la respuesta en un par de minutos (a nadie le gusta un sitio web que demora unos minutos en hacer algo) y luego devuelve un 500 con el sitio. mensaje estándar de "lo siento, no es usted, soy yo" para los errores del servidor (también se registraron los detalles para pasar a la policía). Tuvimos tres intentos de transacciones que obtuvieron esta respuesta de zarigüeya y nunca volvimos a saber de ellos.

Eso fue:

1. En respuesta a algo que sabíamos, fue un ataque en lugar de ser desagradable para los usuarios que tienen un problema.
2. No es una defensa contra un ataque a la seguridad del protocolo en sí, sino a nivel humano por encima de eso.
3. Explicable a través de otras explicaciones, es decir, estábamos fingiendo tener un sitio web realmente desagradable en una situación en la que era plausible (hay muchos sitios web desagradables por ahí) y no éramos un objetivo específico (los perpetradores seguirían adelante). a otra persona).

Los usuarios que tengan un problema deben ser ayudados, no abusados. "No puedo hacer eso porque no está correctamente autorizado" se niega a hacer algo de una manera útil. "No puedo hacer eso porque necesitas usar un proxy" cuando alguien no necesita usar un proxy es abusivo. Ser deliberadamente poco útil solo es apropiado cuando sabes que te están atacando y luego no debería parecer un mensaje obviamente falso o no has ocultado nada (potencialmente, en realidad has revelado algo si no se usa el mismo estado falso) para cada error del cliente).

Dicho esto, es apropiado para tomar medidas para que los estados no filtren información. P.ej. es aceptable (descrito como tal en los estándares) para /admin/ a 404, aunque sería 200 en otro caso (usuario autorizado, direcciones IP de clientes permitidas, etc.) Alternativamente, si /members/my-profile lo hará 200 para un usuario autorizado y 403 o 401 de lo contrario, entonces, si /members/fdsasafdasfwefaxc sería 404 para un usuario autorizado, es una buena idea que sea 403 o 401 para el usuario no autorizado. Esto no es tanto seguridad por oscuridad como para considerar qué URI se relacionan con los recursos como uno de los bits de información que se está protegiendo.