Infografía de las 20 principales vulnerabilidades de OWASP y cómo solucionarlas
El Open Web Application Security Project (OWASP) es una organización bien establecida dedicada a mejorar la seguridad de las aplicaciones web a través de la creación de herramientas, documentación e información, la última de las cuales incluye un top 10 anual de vulnerabilidades de aplicaciones web. La siguiente es una recopilación de las vulnerabilidades críticas más recientes que han aparecido en sus listas, así como información sobre cómo remediar cada una de ellas.
Principales vulnerabilidades de OWASP
Inyección de 1. SQL
Descripción: Las vulnerabilidades de inyección SQL se producen cuando los datos entran en una aplicación desde una fuente que no es de confianza y se utilizan para construir dinámicamente una consulta SQL. La inyección SQL puede provocar la pérdida o corrupción de datos, la falta de responsabilidad o la denegación de acceso. La inyección a veces puede conducir a la toma de control completa del host.
Corrección/Recomendación: Se debe utilizar una validación de entrada adecuada del lado del servidor para filtrar los caracteres peligrosos de la entrada del usuario. Además, el uso de instrucciones preparadas o procedimientos almacenados con parámetros puede garantizar que la entrada se procese como texto.
Fragmento de código de muestra (validación de entrada):
Entrada de cadena=request.getParameter ("SeqNo");
String characterPattern="[0-9a-zA-Z]";
if (! input. matches (characterPattern))
{
out.println ("Entrada no válida ");
}
2. Secuencias de comandos entre sitios (XSS)
Descripción: en estos casos, los datos controlados por el usuario no válidos se procesan dentro de la aplicación, lo que lleva a la ejecución de scripts maliciosos. Las vulnerabilidades XSS pueden permitir a los atacantes capturar información del usuario y/o inyectar código HTML en la aplicación web vulnerable.
Corrección/Recomendación: Se debe emplear una validación de entrada y una codificación de salida adecuadas del lado del servidor tanto en el lado del cliente como en el del servidor para evitar la ejecución de scripts. Los caracteres peligrosos deben filtrarse de la entrada del usuario [por ejemplo: | , & , ; , $, % , @ , ' , " , \' , \" , <> ,() , + , CR (Retorno de carro, ASCII 0x0d) , LF (Avance de línea, ASCII 0x0a) ,(signo de coma) ,\].
Fragmento de código de muestra (técnica de codificación):
<input type="text" maxlength="30" name="ecsChangePwdForm" size="40" readonly="true" value='<%=ESAPI.encoder().encodeForHTML(request.getParameter("userName"))%>'/>
3. Fuga de información
Descripción: La aplicación web puede revelar datos del sistema o información de depuración generando excepciones o mensajes de error. La fuga de datos del sistema o la depuración de información a través de un flujo de salida o una función de registro puede permitir a los atacantes obtener conocimientos sobre la aplicación y crear ataques especializados contra ella.
Corrección/Recomendación:
- Asegúrese de que los códigos de error y otros mensajes visibles para los usuarios finales no contengan información confidencial.
- Desinfecte todos los mensajes, eliminando cualquier información confidencial innecesaria.
- Asegúrese de que la depuración, los mensajes de error y las excepciones no estén visibles.
Fragmento de código de ejemplo:
catch (Exception e)
{
if(log.isDebugEnabled()) log.debug (contexto, EVENTS. ADHOC,
"Caught InvalidGSMException Exception -- "
+ e.toString() );
}
4. Inyección de fotogramas
Descripción: la validación incorrecta de los parámetros de entrada podría llevar a los atacantes a inyectar fotogramas para poner en peligro la información confidencial del usuario. La inyección de fotogramas es un método común empleado en los ataques de phishing
Corrección/Recomendación: Utilice una lista blanca de entradas aceptables que se ajuste estrictamente a las especificaciones seguras
Fragmento de código de ejemplo:
Cadena de entrada=request.getParameter ("entrada");
Patrón de caracteres de cadena="[./a-zA-Z0-9?"="&]";
if (! input. matches (character Pattern))
{
out.println ("Entrada no válida ");
}
5. Redirección de URL
Descripción: aunque es habitual que las aplicaciones web redirijan o reenvíen a los usuarios a otros sitios web o páginas, los atacantes suelen aprovechar las aplicaciones vulnerables sin contar con la validación de redireccionamiento adecuada. Esto puede provocar un redireccionamiento malintencionado a una página que no es de confianza.
Corrección/Recomendación: Utilice una lista blanca de entradas aceptables que se ajusten estrictamente a las especificaciones y para las URL o dominios aprobados utilizados para la redirección.
Fragmento de código de ejemplo:
Cadena de entrada=request.getParameter ("entrada");
Patrón de caracteres de cadena="[./a-zA-Z0-9?"="&]";
if (! input. matches (character Pattern))
{
out.println ("Entrada no válida ");
}
6. Tiempo de espera de sesión faltante
Descripción: los atacantes pueden obtener acceso no autorizado a las aplicaciones web si los tiempos de espera de inactividad no están configurados correctamente.
Corrección/Recomendación: Asegúrese de que la funcionalidad de tiempo de espera esté configurada y funcione correctamente.
Fragmento de código de ejemplo:
<webapp>
<session-config>
<session-timeout>15</session-timeout>
</session-config>
</webapp>
7. Información confidencial pasada como texto sin cifrar en GET URL
Descripción: las aplicaciones web que usan solicitudes GET para pasar información a través de la cadena de consulta lo hacen en texto no cifrado. Esto hace que cualquier información confidencial pasada con GET sea visible en el historial del navegador y en los registros del servidor.
Corrección/Recomendación: El uso de POST en lugar de GET garantiza que la información confidencial no esté visible en los parámetros de la cadena de consulta.
8. Cookies de ID de sesión no marcadas como seguras
Descripción: Si las cookies de ID de sesión para una aplicación web están marcadas como seguras, el navegador no las transmitirá a través de una solicitud HTTP sin cifrar. No marcarlas como tales permite que los atacantes puedan acceder a las cookies y verlas en texto sin cifrar.
Corrección/Recomendación: Asegúrese de que las cookies confidenciales estén configuradas con el atributo "seguro" para garantizar que siempre se transmitan a través de HTTPS.
Fragmento de código de ejemplo:
Cookie cookie=nueva Cookie("myCookieName");
cookie.secure(verdadero);
9. Secuencias de comandos de fotogramas cruzados (XFS)
Descripción: Los exploits de XFS se utilizan junto con XSS para dirigir los navegadores a una página web controlada por los atacantes. En estos casos, la página maliciosa carga una página de terceros en un marco HTML. Los scripts de la página del atacante pueden robar datos de la página de terceros, sin que el usuario lo sepa.
>Corrección/Recomendación: Se debe utilizar una validación adecuada para filtrar cualquier entrada maliciosa que pueda inyectarse en un marco y ejecutarse en el navegador del usuario, dentro del contexto del marco de la página principal.
Fragmento de código de ejemplo:
if (top == self) }
document.documentElement.style.display='block';
}
else {
top.location=self.location;
}
10. La información confidencial se muestra como texto sin cifrar en la pantalla
Descripción: La información confidencial (por ejemplo, contraseñas, información de tarjetas de crédito) no debe mostrarse como texto sin cifrar en la pantalla. Además de los ataques de shoulder surfing, los datos confidenciales almacenados como texto sin cifrar a menudo encuentran su camino hacia las cachés del lado del cliente, que pueden ser fácilmente robados si se descubren.
Corrección/Recomendación: La información confidencial debe enmascararse para que no sea visible para los usuarios
Fragmento de código de ejemplo:
<asp:TextBox ID="txtSSN" TabIndex="6" runat="server" Width="206px" MaxLength="11" TextMode="Password"></asp:TextBox>
11. Información confidencial almacenada en caché
Descripción: los navegadores suelen almacenar una copia de los elementos solicitados en sus cachés: páginas web, imágenes, etc. Esto crea una brecha de seguridad para las aplicaciones que almacenan, procesan y muestran datos confidenciales, ya que los atacantes que obtienen acceso a la caché del navegador del usuario tienen acceso a cualquier información contenida en ella.
Corrección/Recomendación: Se deben usar encabezados HTTP Cache-Control como Cache-Control: no-cache, no-store Pragma: no-cache.
Fragmento de código de ejemplo:
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Caduca" content="0" />
12. Fuerza de cifrado inadecuada
Descripción: Las aplicaciones que utilizan tamaños de clave de menos de 1024 bits para el cifrado pueden aprovecharse mediante ataques de fuerza bruta.
Corrección/Recomendación: Utilice un tamaño de clave de bits de versión superior, 2048 bits o mayor.
13. Inyección CRLF (retorno de carro y alimentación de línea)
Descripción: Las vulnerabilidades de seguridad CRLF se producen cuando se inserta contenido malicioso en los encabezados de respuesta HTTP del navegador después de que un usuario desprevenido haga clic en un enlace malicioso. Los piratas informáticos suelen inyectar código malicioso en el navegador del usuario a través de la aplicación/servidor web, lo que dificulta la detección casual.
Corrección/Recomendación: Codifique la URL de todas las cadenas antes de la transmisión. Asegúrese de que los metacaracteres del shell y los terminadores de comandos (por ejemplo, ; CR o LF) se filtran de los datos del usuario antes de que se transmitan.
Fragmento de código de ejemplo:
Cadena autor=request.getParameter(AUTHOR_PARAM);
Cookie cookie=new Cookie("author", ESAPI.encoder().encodeForURL(author));
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
14. Violación de los límites de confianza
Descripción: las aplicaciones web a menudo mezclan erróneamente datos de confianza y no de confianza en las mismas estructuras de datos, lo que provoca incidentes en los que se confía o se utilizan datos no validados o sin filtrar.
Corrección/Recomendación: Se debe utilizar la validación de entrada y la codificación de salida adecuadas en los datos antes de moverlos a límites de confianza.
Fragmento de código de ejemplo:
String sessionPolicyId=request.getParameter("id");
if(sessionPolicyId.matches("[0-9a-zA-Z_]+") {
session.setAttribute("sessionPolicyId",sessionPolicyId);
}
15. Recorrido por el directorio
Descripción: Al aceptar entradas de usuario que controlan o influyen en las rutas o nombres de archivo utilizados en las operaciones del sistema de archivos, las aplicaciones web vulnerables podrían permitir a los atacantes acceder o modificar recursos del sistema que de otro modo estarían protegidos.
Corrección/Recomendación: Una lista blanca de entradas de datos aceptables que se ajusten estrictamente a las especificaciones puede evitar vulnerabilidades de recorrido de directorios.
Fragmento de código de ejemplo:
Entrada de cadena=request.getParameter("fileName");
if (ESAPI.validator().isValidFileName(Contexto de cadena, Entrada de cadena, booleano allowNull))
{
Archivo archivo=nuevo Archivo(entrada);
}
16. Fijación de la sesión
Descripción: En estos casos, las aplicaciones web vulnerables autentican a los usuarios sin destruir primero las sesiones existentes asociadas a dichos usuarios. Esto permite a los atacantes acceder a las cuentas de los usuarios secuestrando sus sesiones activas.
Corrección/Recomendación: Destruya los identificadores de sesión existentes antes de autorizar una nueva sesión de usuario.
Fragmento de código de ejemplo:
sesión.invalidar();
session=request.getSession(true);
17. Uso de un algoritmo criptográfico riesgoso
Descripción: Las aplicaciones web que utilizan algoritmos no estándar están débilmente cifradas, lo que permite a los piratas informáticos obtener acceso con relativa facilidad utilizando métodos de fuerza bruta.
Corrección/Recomendación: Al almacenar o transmitir datos confidenciales, utilice algoritmos criptográficos sólidos y actualizados para cifrar esos datos antes de enviarlos/almacenarlos.
Fragmento de código de ejemplo:
MessageDigest md=MessageDigest.getInstance("SHA-256");
FileInputStream fis=new FileInputStream("c:\\loging.log");
byte[] dataBytes=nuevo byte[1024];
int nread=0;
while ((nread=fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
};
byte[] mdbytes=md.digest();
18. Gestión de credenciales
Descripción: Almacenar contraseñas en texto sin formato puede comprometer fácilmente el sistema, especialmente si se trata de archivos de configuración/origen.
Corrección/Recomendación: Evite almacenar contraseñas en lugares de fácil acceso. Utilice hashes criptográficos como alternativa al texto sin formato.
19. SQL Inyección Hibernar
Descripción: Hibernate es un popular marco de trabajo ORM para Java, como tal, proporciona varios métodos que permiten la ejecución de consultas SQL nativas. Los atacantes suelen aprovechar Hibernate para ejecutar sentencias SQL maliciosas creadas dinámicamente.
Corrección/Recomendación: La validación adecuada de la entrada del lado del servidor puede servir como una defensa básica para filtrar caracteres peligrosos. Las instrucciones preparadas o los procedimientos almacenados con parámetros se pueden usar para representar los datos como texto antes de su procesamiento o almacenamiento.
Fragmento de código de ejemplo:
Consulta hqlQuery=session.createQuery("seleccionar producto de Pedidos como pedidos donde orders.id =?");
Resultados de la lista=hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list();
20. Apagado o liberación incorrecta de recursos
Descripción: el cierre incorrecto de recursos se produce cuando una aplicación web no libera un recurso del sistema antes de que esté disponible para su reutilización. A continuación, se puede lanzar un ataque de denegación de servicio (Dos) agotando el grupo de recursos del servidor.
Corrección/Recomendación: Todos los recursos creados o asignados deben liberarse correctamente después de su uso.
Fragmento de código de ejemplo:
try {
Connection con=DriverManager.getConnection(some_connection_string);
}
catch ( Exception e ) {
log( e );
}
finalmente {
if( stmt != null )
stmt.close();
con.close() }
En resumen, los 20 elementos enumerados anteriormente son las vulnerabilidades de aplicaciones web más comunes, según OWASP. Si bien muchos de estos se pueden remediar a través de prácticas de codificación más seguras, algunos pueden requerir la identificación de parches relevantes específicos del proveedor. En última instancia, esto depende de las tecnologías, marcos y paquetes específicos que se utilicen en la aplicación web.
¿Necesita una forma más fácil de descubrir vulnerabilidades en su aplicación web? Con la tecnología de pruebas basadas en políticas, UpGuard puede escanear y monitorear automáticamente su aplicación web en busca de configuraciones incorrectas y brechas de seguridad.
Infografía
