¿Estoy trabajando en exceso de ingeniería si considero una injusticia intencional del usuario?

12

¿Se trata de una ingeniería excesiva si agrego protección contra las faltas intencionales de un usuario (por decirlo suavemente), si el daño en el que el usuario puede incurrir no está relacionado con mi código?

Para aclarar, estoy exponiendo un simple servicio RESTful de JSON como este:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

El servicio en sí no está destinado a ser utilizado a través de un navegador, sino solo desde aplicaciones de terceros, controladas por el usuario (como aplicaciones de teléfonos, aplicaciones de escritorio, etc.). Además, el servicio en sí debería ser sin estado (es decir, sin sesión).

La autenticación se realiza con la autenticación básica sobre SSL.

Estoy hablando de un posible comportamiento "dañino" como este:

El usuario ingresa la URL de GET en un navegador (sin razón, pero ...). El navegador solicita la Autenticación básica, la procesa y almacena la autenticación para la sesión de navegación actual. Sin cerrar el navegador, el usuario visita un sitio web malintencionado, que tiene un javascript CSAF / XSRF malicioso CSRF / XSRF . a nuestro servicio.

El escenario anterior es altamente improbable, y sé que desde una perspectiva empresarial no debería preocuparme demasiado. Pero por el bien de mejorar la situación, ¿cree que si también se requiere el nombre de usuario / contraseña en los datos de JSON POST, esto ayudará?

¿O debería eliminar la Autenticación básica por completo, deshacerme de GET y usar solo POST / PUT con información de autorización en ellos? Como la información obtenida a través de GET también puede ser sensible.

En el otro lado, ¿el uso de encabezados personalizados se considera implementación REST pura? Puedo soltar la Autenticación básica y usar encabezados personalizados. De esa manera, se puede evitar al menos el ataque CSRF desde un navegador, y las aplicaciones que usan el servicio establecerán el nombre de usuario / contraseña en un espacio personalizado. Lo malo de este enfoque es que ahora el servicio no se puede consumir desde un navegador.

    
pregunta Sunny 18.08.2011 - 20:49

4 respuestas

6

¿Ingeniería excesiva? De ningún modo. Las medidas anti-XSRF son una parte necesaria de cualquier aplicación o servicio web seguro. Puede o no ser "altamente improbable" que alguien elija atacarte, pero eso no hace que tu software sea menos inseguro.

Los sistemas comúnmente han sido atacados usando XSRF, y aunque los resultados son menos inmediatos, obviamente malos que los de inyección SQL o XSS, son lo suficientemente malos como para comprometer todas las funciones interactivas del usuario.

Eso significa que no puede tener una interfaz REST "pura" donde los parámetros only son las propiedades de la llamada en sí. Debe incluir algo en la solicitud que un atacante no pueda adivinar. Ese podría ser el par de nombre de usuario y contraseña, pero esa no es la única opción posible. Podría tener un nombre de usuario junto con el token generado a partir de un hash con sal de la contraseña. Podría tener tokens emitidos por el propio servicio en el momento de la autenticación (que podrían recordarse en la sesión o verificarse criptográficamente).

  

¿Debo deshacerme de GET

No, las solicitudes GET se utilizan para solicitudes de lectura que no tienen una operación de escritura activa (son "idempotentes"). Solo son operaciones de escritura que requieren protección XSRF.

    
respondido por el bobince 18.08.2011 - 22:33
32

Nunca confíes en nada. Cada solicitud es un ataque. Cada usuario es un hacker. Si desarrolla con esta mentalidad, su aplicación será mucho más segura, estable y menos susceptible de ser secuestrada por un usuario malintencionado. Todo lo que necesita es una persona inteligente para encontrar una manera de evitar su seguridad para que esté en problemas graves con sus datos (uno de sus recursos más valiosos ).

Si ha identificado un agujero de seguridad en su aplicación, haga todo lo que crea que necesita hacer para cerrar la brecha. Su API, especialmente, debe ser la pieza de software más desconfiada que existe. Requeriría las credenciales e iría con las solicitudes de publicación.

    
respondido por el Jarrod Nettles 18.08.2011 - 20:59
0

Si el código se establece y se mantiene, los casos extremos se deben examinar y tratar caso por caso.

FIJACIÓN DEBIDO A ALGUNOS ERRORES EN MI PARTE:

GET debe seguir utilizándose como parte de un servicio RESTful adecuado, la autenticación debe seguir existiendo en cualquier caso. Lo que intentaba suponer es que, por motivos de seguridad, GET es muy similar a POST, pero la publicación hace su trabajo sin colocar la información en una barra de direcciones, que suele ser la gran diferencia de seguridad (y por qué no me gusta GET), pero como publicado por @Lee,

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Dado que esto será utilizado por aplicaciones de terceros, se deben seguir las buenas prácticas para un servicio RESTful para que el implementador final no se confunda en esta parte.

    
respondido por el Jeff Langemeier 18.08.2011 - 20:56
0

Debe considerar todas las eventualidades plausibles, incluido el hecho de que el usuario sea malintencionadamente activo e ingrese (con éxito) la ingeniería inversa de cualquier barrera de "seguridad por oscuridad".

Pero al mismo tiempo, debe evaluar el impacto de un ataque exitoso y la probabilidad de que se produzca un intento. Por ejemplo:

  • Es menos probable que un servicio interno protegido por un firewall sólido esté sujeto a ataques que un servicio en la Internet pública.

  • El impacto de alguien que derriba un foro de discusión de clientes es menor que el impacto de que roben las tarjetas de crédito de los clientes.

Mi punto es que la "seguridad total" es "infinitamente costosa" ... y prácticamente inalcanzable. Lo ideal es que tome sus decisiones sobre dónde dibujar la línea basándose en un análisis exhaustivo de costo-beneficio.

    
respondido por el Stephen C 19.08.2011 - 00:31

Lea otras preguntas en las etiquetas