Riesgos de seguridad distintos a los [cerrado]

0

Estoy trabajando en el sitio web de ASP.NET core MVC, y no sé si me estoy perdiendo algún riesgo de seguridad que deba vigilar (aparte de los lógicos)

Aquí hay una lista de lo que he estudiado y lo que he hecho para protegerlo:

  • Hombre en el ataque central (SSL, HSTS precargado)

  • Inyección SQL (nunca use datos de URL, dejando que el marco filtrarlos)

  • XSS (nunca usa datos sin procesar, aplica CSP)

  • ataque de redireccionamiento abierto (nunca redireccione a nada que no sea local)

  • CSRF (generando y validando siempre el token en cualquier publicación)

  • Jacking de clic (ajustar las opciones de xframe, denegar iframe y aplicar el mismo origen)

  • Inicios de sesión de fuerza bruta (limitación de intentos de inicio de sesión, bloqueo cuenta después de cierta cantidad de intentos de inicio de sesión)

¿Algo más de lo que deba tener cuidado?

    
pregunta m s lma 17.05.2017 - 19:14
fuente

4 respuestas

0

El manejo adecuado de la sesión y el control de acceso a nivel de función es un punto muy importante en la seguridad web ( Consulte Gestión de sesiones de OWASP y Control de acceso a nivel de función ).

Asegúrese siempre de que los tokens de sesión solo sean válidos para acciones que un determinado usuario puede realizar. Y solo para ese usuario determinado.

Ese es un problema muy grande, y el 99% de todos los sitios web que he probado hasta ahora son vulnerables a los ataques que se desarrollan alrededor de eso. P.ej. cuando los tokens podrían usarse para realizar acciones, el usuario que ha iniciado sesión en ese momento no debería poder hacerlo. Me gusta: reemplazar una identificación en una solicitud con la identificación de otro usuario (o registro). ¡Se sorprendería de la frecuencia con la que este método extremadamente simple funciona para obtener la PII de otros usuarios!

  • Todas las direcciones URL solo son accesibles para usuarios con ciertos privilegios.
  • Los usuarios no deberían poder simplemente agregar campos a una solicitud. Buen ejemplo: ya vi múltiples sitios web / aplicaciones, donde era posible secuestrar otras cuentas de usuario simplemente agregando un campo de 'correo electrónico' en el formulario donde cada usuario podría cambiar su propia información de perfil.
  • Asegúrese de que su forma de otorgar roles a los usuarios / administradores sea segura y que los usuarios no puedan otorgarse privilegios / roles adicionales.
  • Los formularios de restablecimiento de contraseñas también suelen ser un buen punto de entrada para los atacantes, y solo para enviar spam a otros usuarios.

Las sesiones deben destruirse al cerrar la sesión / cambiar la contraseña, y no deben reutilizarse en ningún momento.

Además de eso, también debe preocuparse por la divulgación de información (cuando un atacante aplica errores, por ejemplo, con solicitudes o métodos HTTP no válidos, como OPTION en lugar de OPTIONS). Y, por supuesto, siempre asegúrese de que su sitio web utilice solo las bibliotecas más actualizadas (javascript, módulos de servidor, etc.).

Nunca divulgue información confidencial, por ejemplo, asegúrese de que los tokens de sesión nunca se transmitan a través de solicitudes GET.

También asegúrate de que tu servidor solo permita ciertos métodos HTTP (por ejemplo, no permitas "TRACE").

Validación de entrada: asegura todos los formularios de carga de archivos, son muy vulnerables. P.ej. carga útil en el nombre de archivo. También he visto a menudo que el tamaño máximo de archivo solo se validó en el lado del cliente.

Use captchas cuando sea necesario, y asegúrese de que no puedan ser evitados debido a una mala implementación.

Por último, pero no menos importante, también debería preocuparse por las redirecciones abiertas.

En realidad hay muchas cosas por las que debería preocuparse. Inyección, por ejemplo: no solo hay inyección SQL, sino que la inyección de Javascript también es un alto riesgo para la seguridad de su aplicación. Ocurre con más frecuencia que la inyección SQL, con diferencia.

Podría continuar con esta lista por un tiempo, pero te sugiero que sigas leyendo algunas listas de verificación como esta: enlace

    
respondido por el Martin Fürholz 17.05.2017 - 20:16
fuente
3

Algo que he aprendido de la experiencia: los desarrolladores (yo incluido) pueden y DEBERÁN olvidar cosas. SQLi es un gran ejemplo: si confía en que los desarrolladores utilicen una cadena_de_ escape (user_input) cada vez que se use, lo olvidarán.

Ditto XSS y XSRF: los desarrolladores siempre se perderán al menos un lugar donde se pueden escapar las cadenas. Y CSP no es una solución al 100% para XSS.

Es absolutamente crítico que se usen marcos / bibliotecas que sean invulnerables a esos problemas (o donde sea necesario suscribirse). No conozco ASP.net específicamente, por lo que realmente no puedo recomendar uno, pero un término que se debe buscar es "auto-escape contextual" (para XSS).

En cuanto a otros problemas, sugiero revisar el OWASP Top 10 : hacen una bonita buen trabajo de mostrar lo que es lo importante.

Una cosa que debería vigilar especialmente es la "referencia directa insegura de objetos" o la "búsqueda forzada", asegurando que las ACL se apliquen en cada carga de página. Y volviendo a lo primero que dije, deberían aplicarse automáticamente: el desarrollador no debería tener que acordarse de hacerlo. Cualquier comportamiento inseguro debe ser explícitamente opt-in.

Espero que ayude!

    
respondido por el Ron Bowes 17.05.2017 - 19:57
fuente
2

La lista que tiene es un buen punto de partida, pero hay muchos más que debe tener en cuenta. Muchos de ellos dependerán de lo que está haciendo en su aplicación y de los requisitos de su aplicación. Aquí hay una breve lista para comenzar:

Control de acceso:
Asegúrese de que solo los usuarios autenticados y autorizados tengan acceso a las acciones de su controlador. Recuerde, cualquier método público en una clase que herede de Controller puede solicitarse desde la web, no solo los métodos que devuelven un ActionResult. La mejor manera de manejar esto es decorar todos sus controladores con el atributo [Autorizar], y cualquier método que deba ser accesible para usuarios no autenticados debe tener aplicado el atributo [Permitir anónimo].

Vulnerabilidades relacionadas con la carga de archivos: Hay muchas vulnerabilidades posibles relacionadas con las cargas maliciosas. Si no está desinfectando correctamente los archivos cargados, es posible que un usuario malintencionado pueda sobrescribir algunos de sus archivos existentes, incluidos los archivos de javascript y las plantillas de Razor (Busque la inclusión de archivos locales para obtener más información). Idealmente, debería cambiar el nombre de los archivos cargados a algo que el usuario no pueda controlar o adivinar. Además, idealmente, esto debería estar fuera de la raíz web.

Otras áreas de investigación son la falsificación de solicitudes en el lado del servidor, el desvío criptográfico, el registro de la cuenta / los defectos de restablecimiento de la contraseña, etc. La lista sigue y sigue.

    
respondido por el user52472 17.05.2017 - 19:53
fuente
0

Como han dicho otros, echa un vistazo a la Proyecto Top 10 de OSWAP . Tenga en cuenta algunas nuevas adiciones a su lista propuesta de 2017: Protección insuficiente contra ataques y API desprotegidas.

Incapsula también tiene una buena lista de amenazas de seguridad de aplicaciones web que recomiendo revisar . Por supuesto, la recomendación es un WAF, pero es bueno que esté considerando la seguridad al principio del diseño. Ha cubierto algunas de estas amenazas pero también considere:

  • APT
  • Ataques de ingeniería social
  • Inclusiones de archivos remotos

y hay muchos más. Desafortunadamente, las amenazas no tienen fin, pero tomarlas en serio las reducirá sustancialmente.

¿Puedo preguntar qué funcionalidad requiere su sitio web o cuál es su orientación ya que afecta a vulnerabilidades específicas a las que prestar atención adicional además de los (importantes) elementos básicos?

    
respondido por el avi 18.05.2017 - 14:49
fuente

Lea otras preguntas en las etiquetas