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

Estoy escribiendo una simple API REST, y quiero restringir el acceso solo a mi cliente móvil. En otras palabras, estoy tratando de evitar que un usuario malintencionado, por ejemplo. usando curl para hacer una solicitud POST no autorizada.

Por supuesto, esto es imposible. Sin embargo, existen ciertas contramedidas que dificultan el éxito de un hacker. En este momento, estoy cifrando todas las solicitudes con una clave privada, almacenada en el lado del cliente (obviamente, esto no es lo ideal, pero la dificultad en la ingeniería inversa de una aplicación de iOS puede disuadir a todos, excepto a los piratas informáticos más determinados).

Una idea simple que tuve es devolver el código de respuesta HTTP incorrecto para una solicitud no autorizada. En lugar de devolver un "401 no autorizado", ¿por qué no devolverlo, por ejemplo? "305 Use Proxy", es decir, a propósito es confuso. ¿Alguna vez alguien ha pensado en hacer esto?

36
Los comentarios no son para discusión extendida; esta conversación ha sido movido a chatear .
agregado el autor Rory Alsop, fuente
@Pascal Está pensando en usar 404 en lugar de 403. El estándar HTTP explícitamente permite esto para evitar revelar la existencia de un recurso a un usuario al que no se le permite acceder. Puede evitar que el 401 filtre información sobre la existencia si lo requiere para todas las ubicaciones que coinciden con el patrón de otras ubicaciones que requieren autenticación. (Espero que volver a publicar este comentario esté bien; creo que esta es una información importante).
agregado el autor jpmc26, fuente
Si no devuelve los códigos de estado HTTP correctos, se podría decir que, estrictamente hablando, no se habla HTTP. Así que una vez que hayas llegado tan lejos, simplemente deberías implementar un protocolo completamente diferente ...
agregado el autor Magnus Johansson, fuente
@Pascal este es el enfoque adoptado por GitHub (al menos) al intentar acceder a un repositorio privado cuando no está autenticado o no autorizado.
agregado el autor Alexandre Amato, fuente
Se llama "seguridad por oscuridad". Puede ralentizar a alguien, pero eso es todo.
agregado el autor sluukkonen, fuente
Para su valor, leí en algún lugar en un documento oficial en HTTP (lo siento, no recuerdo la fuente), que se permite devolver 404 en lugar de 401 para no filtrar información sobre la existencia de recursos a clientes no autorizados.
agregado el autor Pascal, fuente

11 Respuestas

¿Alguien ha pensado alguna vez en hacer esto?

Sí, en realidad se habló exactamente sobre esto 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 disminución severa de los escáneres automáticos, escáneres que no funcionan y una cantidad masiva de falsos positivos o falsos negativos (obviamente hará poco o nada para los escaneados 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 otro lado, una API REST debe ser lo más limpia posible, y responder con códigos HTTP intencionadamente equivocados puede ser confuso para los desarrolladores y clientes legítimos (esto es un poco menos un problema para los navegadores, donde los usuarios realmente no ven el códigos). Debido a esto, no lo recomendaría en su caso, pero sigue siendo una idea interesante.

82
agregado
Si bien reconozco que la legitimidad de la "seguridad por oscuridad" es una barrera de entrada (es decir, expulsar a los chiquillos de guión), creo que se usa demasiado y es tan perjudicial para la seguridad de la aplicación real. De los dos campos relacionados, criptografía y seguridad de la información, uno se basa en la "oscuridad", mientras que el otro no. Por cierto, el que hace se hace más fácil la mayor parte del tiempo. Además, la oscuridad se aplica a todas las partes (incluidos los pentesters que pagas) e introduce una mayor complejidad, por lo tanto, los vectores de ataque.
agregado el autor Ryan Versaw, fuente
@ ypercubeᵀᴹ Ahora que he leído mi comentario, suena como si estuviera diciendo que, si bien me refería exactamente a lo contrario: en la criptografía, el principio de Kerckhoffs es esencialmente el opuesto ideológico de "Seguridad por oscuridad".
agregado el autor Ryan Versaw, fuente
@ K.Steff Cada gobierno que usa algoritmos criptográficos clasificados usa "seguridad por oscuridad" en la criptografía.
agregado el autor mostlyinformed, fuente
@ K.Steff "la criptografía se basa en la oscuridad" ? ¿Querías escribir "esteganografía"?
agregado el autor cupe, fuente
Creo que esta es una respuesta muy práctica. Me enoja cuando alguien pone seguridad por oscuridad porque leen que era malo en un blog o algo así. En el mundo real, definitivamente puede ser útil. Simplemente no puede ser el único truco en tu bolsa, eso es todo.
agregado el autor corsiKa, fuente
+1 por la mención de desarrolladores. Cuando hago un cambio en un sistema y de repente obtengo un 404 donde obtuve un 200 de repente, tengo un juego de whack-a-mole que identifica dónde se tomó la decisión de enviar una respuesta diferente. Todo lo que puedo decirle a OP es si decide hacer esto, por favor documéntelo correctamente o su nombre será guardado en algún momento en el futuro
agregado el autor booboo, fuente

En realidad no ralentizará a un 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 solicitud 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 . Cuando diseñe un sistema como este, debería pensar en reducir la velocidad de un atacante por cientos de años, no por decenas de minutos; de lo contrario, todavía perderá.

57
agregado
@Nacht "la seguridad por oscuridad es la única posibilidad" es decir, "ninguna seguridad es la única posibilidad" (alerta de hipérbole). Si no puede proteger un sistema y lo necesita, no lo implemente. Lo mismo ocurre con los modelos de negocios, como anuncios.
agregado el autor Ryan Versaw, fuente
"Cuando diseñes un sistema como este, deberías pensar en reducir la velocidad de un atacante cientos de años, no decenas de minutos; de lo contrario, aún perderás". ¿Contra un atacante dedicado, decidido, experto? Sí. ¿Pero para derrotar a los programas automáticos de ataque o los atacantes humanos que buscan los objetivos más fáciles y más vulnerables para aprovechar? No. Es probable que se muevan a lo largo. Y eso, BTW, a su vez, a menudo le brindará una mejor visibilidad para detectar más amenazas, ya que enfrentan la derrota de las mejores medidas de seguridad "reales" que tiene la capacidad de implementar.
agregado el autor mostlyinformed, fuente
Esta pregunta es sobre un escenario donde la seguridad por oscuridad es la única posibilidad. Tu primer párrafo es bueno, pero el segundo es irrelevante.
agregado el autor Francisco Corrales Morales, fuente
@Cruncher, no, la seguridad por oscuridad nunca va a ralentizar a nadie cientos de años. Está diciendo que necesita seguridad "adecuada", lo cual es imposible con el diseño actual del OP.
agregado el autor Francisco Corrales Morales, fuente
@mostltinformed OP mencionó específicamente a un usuario malicioso que usa curl o algún otro método para realizar solicitudes (no autorizadas). El atacante ya ha diseñado la aplicación iOS para obtener una clave necesaria para realizar el ataque, entre otras cosas. No va a ser detenido por un pequeño inconveniente relacionado con los códigos de devolución.
agregado el autor Robert, fuente
Duro, pero justo. Me gusta :) . Pone en perspectiva la naturaleza de la debilidad.
agregado el autor J.A.K., fuente
Creo que esto REALMENTE depende de suposiciones sólidas sobre el atacante. Ciertamente, no ralentizará a un atacante experto que se dirija específicamente al sitio, pero puede frustrar los intentos de escaneo automático o los atacantes lentos que podrían confundirse con el código de respuesta. Por lo tanto, no necesariamente agrega seguridad, pero puede mejorar las cosas. La pregunta es si vale la pena el tiempo de implementar algo que pueda ralentizar a un atacante menos decidido.
agregado el autor Kat, fuente
@Nacht ¿cómo es irrelevante el segundo? Es muy relevante. Está diciendo que si vas a usar la seguridad en la oscuridad, es mejor que sea una buena oscuridad. Está diciendo que esta defensa en particular no va a frenar a nadie sofisticado en absoluto.
agregado el autor Cruncher, fuente

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.

Digamos que tengo una clave válida y puedo observar que devuelves 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 los piratas informáticos menos a los más decididos

Sí, lo hará, pero como solo se necesita uno para publicarlo, nuevamente se está reduciendo la velocidad ...

8
agregado
Hace mucho tiempo escribí un código que lanza un ataque a cualquiera que intente este tipo de cosas. Terminé aprendiendo que no es la más inteligente de las ideas. Mucho más sano podría ser una mala solicitud -> IP prohibida durante 100 horas en el nivel de firewall.
agregado el autor Joshua, fuente

Esto es seguridad a través de la oscuridad, lo que quiere decir que 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 para 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.

6
agregado
Esa es una pregunta completamente diferente de la original, y también sigue siendo difícil. Necesitaría algún mecanismo del lado del servidor para determinar si el usuario realmente ha visto el anuncio. Es posible que envíe un token firmado digitalmente que incluya la marca de tiempo cuando se recibió la solicitud del anuncio y la duración del anuncio. Luego, ese token debería volver a enviarse y validarse cuando el usuario desee solicitar el punto final protegido. Me gustaría investigar soluciones DRM. Rodar este por tu cuenta sin la experiencia de criptografía sería difícil de hacer de forma segura.
agregado el autor Denis, fuente
Aunque estoy confundido. Todo el mundo está diciendo que OP necesita seguridad real y NADIE ha mencionado cómo hacerlo todavía. El problema es que no quieren que se llame el punto final a menos que se vea un anuncio. ¿Cómo logran esto?
agregado el autor Cruncher, fuente

Pero el usuario ya está utilizando su protocolo.

Your problem is that your server’s interface of what the user can do is not secure!
You decide what data your server sends out to whom!
(Hello, dear online newspapers. Yes, I’m looking at you!)

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 das al usuario la clave de cifrado y todo, y esperas que no la use él mismo, porque la pones en algún lugar de tu 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 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 estafar 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 simple oscuridad que es demasiado probable para que alguien se le ocurra de la nada.

4
agregado
@DavidRicherby: Me estás repitiendo el mismo punto como si fuera un argumento contrario. Es mi punto, que toda la seguridad solo difiere por la cantidad de trabajo que se necesita para descifrar/corregir (también conocido como oscuridad), y por lo tanto no hay una brecha mágica especial con "no basada en la oscuridad" "real seguridad".
agregado el autor NotoriousWebmaster, fuente
@DavidRicherby: ¿Me estás diciendo lo que I dije? ^^ Amigo, estoy de acuerdo contigo! (O mejor dicho, tú conmigo). ¿Qué más quieres? ¡Relajarse! Y por favor no "interpretes" las cosas que no dije. No dije que el término "seguridad" fuera inútil. Y sí, no hay seguridad 100%. Siempre. Todo es solo niveles de oscuridad. Puede elegir convenientemente una definición arbitraria de "seguro", pero luego se va a la tierra de fantasía.
agregado el autor NotoriousWebmaster, fuente
P.S .: Este es otro ejemplo de por qué el texto es un medio malo para la conversación humana. Todos los malentendidos.
agregado el autor NotoriousWebmaster, fuente
@Cruncher: una buena señal para cuando las personas creen más en algo porque entienden menos de eso, es cuando usan argumentos emocionales como "por una muy buena razón", pero no lo respaldan. Si no fuera una creencia, simplemente declararían esa razón en lugar de una fase desgastada. Por desgracia, una cosa muy común entre los humanos. Al igual que la reflexión de argumentos, la interpretación selectiva, los argumentos del hombre de paja, tomar todo como algo personal e insultante, etc.
agregado el autor NotoriousWebmaster, fuente
@DavidRicherby: y 1. ¿por qué estás haciendo argumentos en contra de eso entonces, y 2. cuándo comenzarás a hacer argumentos para respaldarlo? :)/me huele un poco al trolling
agregado el autor NotoriousWebmaster, fuente
La oscuridad de la frase seguridad a través de la oscuridad se refiere específicamente a la oscuridad del diseño del sistema en lugar del material clave. Es una forma de referirse al principio de Kerchov.
agregado el autor Filegedhiel, fuente
@DavidRicherby Quiero votar este comentario 100 veces. No es nada útil agrupar toda la seguridad en el mismo compartimiento con diferentes grados. Inventamos la terminología "seguridad a través de la oscuridad" por una muy buena razón.
agregado el autor Cruncher, fuente
@ Evi1M4chine Para alguien que reprendió los argumentos "emocionales", está seguro de ser muy emocional. La "muy buena" razón fue en realidad más que una apelación a la autoridad más que nada. Nada emocional al respecto. Tampoco te respondí directamente. Solo estaba reforzando el punto de David. No estamos en un debate aquí. El hecho de que mi argumento fuera incompleto no significa que sea inválido o infundado.
agregado el autor Cruncher, fuente
Un punto de vista interesante con respecto a "toda la seguridad es a través de la oscuridad". Si algo es imposible de romper en una vida humana, ¿no es seguro? :)
agregado el autor niilzon, fuente
Su afirmación de que "seguridad por oscuridad" no es un concepto útil no es realmente válida. Supongo que su punto es que tener, por ejemplo, una clave secreta es solo seguridad manteniendo la clave oculta. Sin embargo, si descubro su clave secreta, puede reemplazarla con una nueva clave, volver a utilizarla e intentar tener más cuidado con su nueva clave. Si descubro su algoritmo secreto, entonces tiene que construir un sistema completamente nuevo, que es mucho más trabajo. Además, puede dar límites mucho mejores en cuanto al tiempo que me llevará averiguar su clave, en comparación con el tiempo que me llevará averiguar su algoritmo.
agregado el autor William Pietri, fuente
@ Evi1M4chine No, no lo soy. Estás diciendo que toda seguridad es, en última instancia, seguridad al mantener algo oscuro. Estoy diciendo que no usamos la frase "seguridad por oscuridad" para referirnos a "seguridad por mantener algo oscuro". Es como afirmar que ningún sistema es seguro porque cualquier cosa puede ser hackeada por un oponente suficientemente determinado y suficientemente poderoso y, por lo tanto, la palabra "seguridad" es inútil porque nada es verdaderamente seguro. Eso no es lo que la palabra "seguridad" se usa para significar, y el término del que estás hablando no es lo que significa "seguridad por oscuridad".
agregado el autor William Pietri, fuente
@ Evi1M4chine "Por una razón muy buena [pero no declarada]" no es un argumento emocional. Pero es argumento por la oscuridad. ;-)
agregado el autor William Pietri, fuente
@ Evi1M4chine No, no estoy de acuerdo contigo. Usted dijo que el concepto de seguridad por oscuridad es "una falacia". Dije que no lo es. Es un concepto extremadamente útil.
agregado el autor William Pietri, fuente

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.

3
agregado
Bueno, técnicamente, esto es para OCULTAR el hecho de que necesitan obtener la clave privada de la aplicación. Es decir, esto sucede primero. Sin embargo, cualquier persona que pueda obtener la clave de la aplicación, no se detendrá por esto en absoluto.
agregado el autor Cruncher, fuente
Cualquier atacante no idiota observaría primero el tráfico legítimo e inmediatamente vería que las solicitudes están cifradas. Literalmente sería lo primero que se da cuenta.
agregado el autor Tom, fuente

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 modo 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?

1
agregado

Como otros ya han mencionado, usted está 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 con base en Pautas OWASP . Obtendrás resultados mucho mejores que pasas tu tiempo con OWASP y luego tratarás de determinar qué es un usuario malintencionado y devolver un código de respuesta HTTP desconocido.

1
agregado

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

  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 desea. 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 pasar para que te sientas frustrado en tus intentos de romperlo?

1
agregado

Generalmente no es una buena idea.

Hice un uso muy específico de esto una vez que tuvo un buen efecto cuando el sitio web de un cliente estaba siendo utilizado por un anillo de lavado de tarjetas de crédito robado. 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.

Aunque 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 tienen 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) por 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 cliente permitidas, etc.) Alternativamente si /members/my-profile tendrá 200 para un usuario autorizado y 403 o 401 de lo contrario, entonces, si /members/fdsasafdasfwefaxc fuera 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 si consideramos qué URI se relacionan con los recursos como uno de los bits de información que se está protegiendo.

0
agregado

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, ya. 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.

0
agregado