Actitud paranoica: ¿Cuál es su grado acerca de las preocupaciones de seguridad web?

Question

esta pregunta se puede asociar a una pregunta subjetiva, pero esta no es realmente una.

Cuando desarrolla un sitio web, hay varios puntos que debe saber: ataques XSS, inyección de SQL, etc. Puede ser muy difícil (y tomar un largo tiempo para codificar) proteger todos los ataques potenciales.

Siempre trato de proteger mi aplicación, pero no sé cuándo detenerla.

Tomemos el mismo ejemplo: una red social como Facebook. (. Debido a un sitio web banco debe asegurar todos sus datas)

veo algunos enfoques:

1. No asegure XSS, inyección SQL ... Esto puede ser hecho en realidad cuando confía en tu usuario: volver final para una empresa privada. ¿Pero seguro este tipo de aplicación?

2. Ataques seguros solo cuando el usuario intenta acceder a datos no pertenecientes: este es el mejor método para mí.

3. Asegure todos, todos, todos: Protege todos los datos (propietario o no): el usuario no puede romper sus propios datos y otros datos de usuario: esto es muy largo de hacer y ¿es muy útil?

4. Ataques comunes seguros, pero no aseguran ataques muy duros (porque es demasiado largo para comparar código con la posibilidad de ser pirateado).

Bueno, no sé realmente qué hacer ... Para mí, trato de hacer 1, 2, 4, pero no sé si es la gran opción.

¿Existe un riesgo aceptable de no proteger todos sus datos? ¿Puedo asegurar todos los datos, pero me lleva el doble de tiempo codificar? ¿Cuál es el enfoque empresarial entre el riesgo y "el tiempo es dinero"?

Gracias por compartir esto porque creo que muchos desarrolladores no saben cuál es el límite.

EDIT: Veo muchas respuestas sobre XSS y inyección SQL, pero esto no es lo único que se debe tener en cuenta.

Tomemos un foro. Un hilo se puede escribir en un foro donde somos moderadores. Por lo tanto, cuando envía datos a la vista del cliente, agrega o elimina el botón "agregar" para este foro. Pero cuando un usuario intenta guardar un hilo en el lado del servidor, debe verificar que el usuario tenga derecho a puntearlo (no puede confiar en la seguridad de la vista del cliente).

Este es un ejemplo muy simple, pero en algunas de mis aplicaciones, tengo una jerarquía de derechos que pueden ser muy muy difícil de comprobar (se necesita una gran cantidad de consultas SQL ...) pero en otro lado, es realmente difícil encontrar el truco (los datos se pseudocifran en la vista del cliente, hay una gran cantidad de datos que modificar para que el pirateo se ejecute, y el hacker necesita una buena comprensión de las reglas de mi aplicación para hacer un truco): en este caso , ¿puedo verificar solo los agujeros de seguridad de la superficie (pirateo realmente fácil) o puedo verificar los agujeros de seguridad muy difíciles (pero disminuirá mi rendimiento para todos los usuarios, y me lleva mucho tiempo desarrollarlos).

La segunda pregunta es: ¿Podemos "confiar" (para no desarrollar un código largo y difícil que disminuya el rendimiento) en la vista del cliente para un hackeo muy difícil?

Aquí hay otro post hablando de este tipo de corte: (hibernación y la comprobación de colección) Security question: how to secure Hibernate collections coming back from client to server?

Answer 1

Creo que deberías tratar de asegurar todo lo que puedas, el tiempo dedicado a hacer esto no es nada comparado con el tiempo necesario para arreglar el lío hecho por alguien que explota una vulnerabilidad que dejaste en alguna parte.

La mayoría de las cosas de todos modos son bastante fácil de solucionar:

• inyecciones SQL tienen realmente nada que ver con SQL, que es la manipulación de cadenas solo, así que si usted no se siente cómodo con eso, sólo tiene que utilizar declaraciones preparadas con Los parámetros enlazados y olvídate del problema
• El exploit cross site se invalida fácilmente escapando (con htmlentities o menos) todos los datos no confiables antes de enviarlos como salida; por supuesto, esto debe ir acompañado de un amplio filtrado de datos, pero es una buena start
• robo de credenciales: nunca almacene datos que puedan proporcionar un acceso permanente a áreas protegidas - en su lugar guarde una versión hash del nombre de usuario en las cookies y establezca un límite de tiempo para las sesiones: de esta forma un atacante que pueda robar estos datos tendrá acceso limitado en lugar de permanente
• nunca supongamos que solo porque un usuario inicia sesión puede confiar en él: aplique las reglas de seguridad a todo el mundo
• trate todo lo que obtenga del exterior como potencialmente peligroso: incluso un sitio confiable del que obtenga datos podría verse comprometido, y usted no lo hace También quiero caerme, incluso tu propia base de datos podría verse comprometida (especialmente si estás en un entorno compartido), así que no confíes en sus datos, ya sea

Por supuesto que estoy es más, como los ataques de secuestro de sesión, pero esas son las primeras cosas que debe considerar.

EDITAR con respecto a su edición:

No estoy seguro de entender completamente sus ejemplos, sobre todo lo que entendemos por "la confianza en la seguridad del cliente". Por supuesto, todas las páginas con acceso restringido deben comenzar con una comprobación para ver si el usuario tiene derecho a ver el contenido y, opcionalmente, si tiene el nivel de privilegio correcto: puede haber algunas acciones disponibles para todos los usuarios, y algunas otros solo están disponibles para un grupo más restringido (como moderadores en un foro). Todos estos controles tienen que hacerse en el lado del servidor, porque puede nunca confiar en lo que el cliente le envía, ya sea a través de datos GET, POST e incluso COOKIES. Ninguno de estos son opcionales.

Answer 2

Todas las aplicaciones deben tener un cierto grado de seguridad. Por lo general, no solicita SSL en los sitios web de la intranet, pero debe encargarse de los ataques SQL/XSS.

Todos los datos que su usuario ingrese en su aplicación deben ser bajo su responsabilidad. Debe asegurarse de que nadie no autorizado tenga acceso a él. A veces, una información "no crítica" puede plantear un problema de seguridad, porque todos somos perezosos.

Hace algún tiempo, un amigo utiliza para ejecutar un sitio web de juegos. Los usuarios crean sus perfiles, foro, todo eso. Entonces, algún día, alguien encontró una inyección SQL abierta en alguna parte. Ese atacante obtiene toda la información de usuario y contraseña.

No es gran cosa, ¿eh? Quiero decir, ¿a quién le importa una cuenta de jugador en un sitio web? Pero la mayoría de los usuarios usaban el mismo usuario/contraseña para MSN, Counter Strike, etc. Así que conviértanse en un gran problema muy rápido.

conclusión es: todas las aplicaciones deben tener algún problema de seguridad. Debería echarle un vistazo al STRIDE para comprender sus vectores de ataque y tomar las mejores medidas.

Answer 3

creo que es útil distinguir entre prevenir la inyección de código y la autorización de datos sin formato.

En mi opinión, basta con unos buenos hábitos de codificación para eliminar por completo la inyección de SQL. Simplemente no hay excusa para eso.

XSS injection es un poco diferente, creo que siempre se puede evitar, pero puede no ser trivial si su aplicación presenta contenido generado por el usuario. Con esto simplemente quiero decir que puede no ser tan trivial para proteger su aplicación contra XSS, ya que se compara con la inyección SQL. Así que no me refiero a que esté bien permitir XSS: sigo pensando que no hay excusa para permitirlo, es más difícil de prevenir que la inyección de SQL si su aplicación gira en torno al contenido generado por el usuario.

Por lo tanto, la inyección SQL y XSS son cuestiones puramente técnicas: el próximo nivel es la autorización: qué tan completo debe ser un escudo de acceso a los datos que no es comercial para el usuario actual. Aquí creo que realmente depende de la aplicación, y puedo imaginar que tiene sentido distinguir entre: "usuario X no puede ver nada de usuario Y" vs "Sin molestarse usuario X con los datos de usuario Y podría mejorar la facilidad de uso y hacer la aplicación más conveniente de usar ".

Answer 4

"Datos de última hora" no es algo que nunca debería ser posible, por el usuario autorizado o por cualquier otra persona. Me gustaría presentar esto en "validación y saneamiento de la entrada del usuario", y es algo que siempre debes hacer. Si existe la posibilidad de que un usuario "rompa sus datos", tarde o temprano tendrá que validar todas las entradas en su aplicación. Escapar las consultas SQL también entra en esta categoría, que es a la vez una preocupación de seguridad y protección de datos.

La seguridad general en su aplicación deberá ser satisfactorio independientemente. Si tiene un sistema de administración de usuarios, debería hacer su trabajo correctamente. Es decir. los usuarios que no deben acceder a algo no deberían poder acceder a él.

El otro problema, los ataques XSS directos, no tiene mucho que ver con "datos de interrupción", pero con el acceso no autorizado a los datos. Esto es algo que depende de la aplicación, pero si conoce cómo funcionan los ataques XSS y cómo puede evitarlos, ¿hay alguna razón para que no?

En resumen:

• inyección de SQL, la validación de entrada y saneamiento van de la mano y son una visita obligada de todos modos
• ataques XSS pueden ser evitados por las mejores prácticas y un poco de conciencia, no deberías t necesidad de hacer mucho trabajo extra para que
• nada más allá de eso, como filtros "proactivas" ataque de fuerza bruta o ese tipo de cosas, que hacen causar trabajo adicional, dependerá de la aplicación

Simplemente hacer un hábito para cumplir con las mejores prácticas hace mucho por hacer una aplicación segura, ¿y por qué no? :)

---

necesita ver las aplicaciones web como la arquitectura cliente-servidor que son. El cliente puede hacer una pregunta, el servidor da respuestas. La pregunta es solo una URL, a veces con un poco de datos POST adjuntos.

¿Puedo tener /forum/view_thread/12345/ por favor?
¿PUEDO PUBLICAR este $data en /forum/new_thread/ por favor?
¿Puedo tener /forum/admin/delete_all_users/ por favor?

Su seguridad no puede depender únicamente de que el cliente no haga la pregunta correcta. Nunca.
El servidor siempre necesita evaluar la pregunta y responder No cuando sea necesario.

Answer 5

Personalmente prefiero asegurar todo en todo momento. Puede ser un enfoque paranoico, pero cuando veo toneladas de sitios web en internet, que son vulnerables a la inyección de SQL o incluso a ataques mucho más simples, y no se molestan en arreglarlo hasta que alguien los "piratee" y robe sus valiosos datos, me da mucho miedo Realmente no quiero ser el responsable de las contraseñas filtradas u otra información de usuario.

Simplemente solicite a alguien que tenga experiencia en hackeo que verifique su aplicación/sitio web. Debe darle una idea clara de lo que está mal y lo que debe actualizarse.

Quiere tener una fuerte ACL del lado de la API. Hace algunos días vi un problema en el que un chico había asegurado todas las UI, pero el sitio web era vulnerable a través de AJAX, solo porque su API (donde enviaba las solicitudes) solo confiaba en que cada solicitud se verificara. Básicamente podría extraer toda la base de datos a través de este error.