UNIVERSIDAD MARIANO GALVEZ DE GUATEMALA

INGENIERIA EN SISTEMAS DE INFORMACION

DISEÑO DE SISTEMAS

NOVENO SEMESTRE

Resumen OWASP

JORGE NERU BARRERA BARRERA 0900-10-1259

GUATEMALA, 19 DE ABRIL 2014.

INTRODUCCION

El sigueinte trabajo es un resumen del top 10 de la owasp que tiene como objetivo

que los desarrolladores elaboren aplicaciones web mas seguras ante las vulnerabilidades

actuales, adicional nos muestran herramientas que deben utilizarse para verificar los errors

mas communes de inseguridad del ambiente web.

Tabla de contenido

Introducción 2

Inyección de código 4

Perdida de autenticación y gestión de sesiones 6

Secuencia de sitios cruzados XSS 7

Referencia directa insegura a objetos

7

Configuración de seguridad incorrecta

8

Exposición de datos sensibles 8

Inexistente Control de Acceso a nivel de funcionalidades

9

Falsificación de peticiones en Sitios Cruzados (CSRF)

9

Uso de componentes con vulnerabilidades conocidas

10

Redicciones y reenvíos no validos

10

Conclusiones 11

Inyección de código:

Es básicamente la vulnerabilidad que existe en introducir código a través del intérprete que pueda

resultar en perdida de información o acceso a información sensitiva y/o confidencial.

Este tipo de riesgo se puede mitigar utilizando una API parametrizada que impida la inyección de

código a través del interprete por ejemplo utilizar procedimientos almacenados “Store Procedures”.

Es necesario que cuando se utilicen Frameworks se valide que no se está confiando demasiado en

el de tal forma que se puedan explotar sus vulnerabilidades.

Elaborar una lista blanca de caracteres también es muy importante sin embargo el intérprete puede

utilizar caracteres especiales para comunicarse con otros sistemas.

Ejemplos de querys seguros en lenguajes populares:

Language -

Library Parameterized Query

Java - Standard

String custname = request.getParameter("customerName");

String query = "SELECT account_balance FROM user_data WHERE

user_name = ? ";

PreparedStatement pstmt = connection.prepareStatement(

query );

pstmt.setString( 1, custname);

ResultSet results = pstmt.executeQuery( );

Java - Hibernate

//HQL

Query safeHQLQuery = session.createQuery("from Inventory

where productID=:productid");

safeHQLQuery.setParameter("productid",

userSuppliedParameter);

//Criteria API

String userSuppliedParameter =

request.getParameter("Product-Description"); // This

should REALLY be validated too

// perform input validation to detect attacks

Inventory inv = (Inventory)

session.createCriteria(Inventory.class).add

(Restrictions.eq("productDescription",

userSuppliedParameter)).uniqueResult();

Perdida de Autentificación y gestión de sesiones.

Es básicamente la vulnerabilidad que existe en las credencias y los identificadores de sesiones.

Las vulnerabilidades son las siguientes:

1. Las credenciales de los usuarios no están protegidas cuando se almacenan utilizando un

hash o cifrado.

2. Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión

de la sesión.

3. Los ID de sesión son expuestos en la URL.

4. Dejar los IDS in control de expiración.

5. Transmisión de contraseñas, ID de sesión y otras credenciales son transmitidas a travez de

canales no cifrados.

Existen actualmente algunas tecnologías que pueden utilizarse para mejorar la seguridad en cuanto

a autenticación de password y gestión de sesiones para tener mejor control.

Adicional debemos tomar en cuenta las siguientes recomendaciones:

1. Generar una guía de password para una aplicación:

a. Largo mínimo de password así como su máximo.

b. Complejidad de password debe tener mayúsculas, minúsculas, números y

caracteres especiales.

c. No utilizar 2 caracteres iguales juntos, etc.

2. Implementar un mecanismo de recuperación de password

3. Guardar los password de forma segura utilizando criptografía.

4. Trasmitir los password a través de TLS (Transport Layer protection)

5. Utilizar la re autenticación por funcionalidades sensitivas

6. Utilizar Multifactor Authentication ej. Tokens, biometría, números de teléfono, etc.

7. Autentificacion a travez de SSL, conocidas como doble autenticación donde el navegador y

el servidor envias sus respectivos certificados durante el proceso TLS handshake.

8. Correcto manejo de autenticación de mensajes, ej. “El usuario o password son incorrectos”

9. Utilizar un mecanismo de defensa ante ataques de fuerza-bruta, utilizando autenticación

multifactor, o bloqueo de cuentas por 20 min.

Secuencia de comandos en Sitios cruzados (XSS)

Consideremos que cualquier persona pueda enviar datos no confiables al sistema, el atacante envía

cadenas de comandos de ataque que explotan el intérprete del navegador.

La mayoría de fallas de XSS son detectadas de forma relativamente fácil por medio de pruebas o

análisis de código.

La vulnerabilidad consiste en que el atacante puede ejecutar secuencia de comandos en el

navegador de la víctima para secuestrar las sesiones de usuario, alterar la apariencia del sitio web,

insertar código, redirigir usuario, secuestrar el navegador.

Resumen de reglas para prevenir el XSS

Tipo de

Data Contexto Ejemplo de código Defensa

String HTML Body <span>UNTRUSTED DATA</span> HTML Entity Encoding

String Safe HTML

Attributes

<input type="text" name="fname"

value="UNTRUSTED DATA">

Aggressive HTML Entity

Encoding

Only place untrusted data

into a whitelist of safe

attributes (listed below).

Strictly validate unsafe

attributes such as

background, id and name.

String GET Parameter <a href="/site/search?value=UNTRUSTED

DATA">clickme</a>

URL Encoding

String

Untrusted URL

in a SRC or

HREF attribute

<a href="UNTRUSTED URL">clickme</a>

<iframe src="UNTRUSTED URL" />

Canonicalize input

URL Validation

Safe URL verification

Whitelist http and https

URL's only (Avoid the

JavaScript Protocol to

Open a new Window)

Attribute encoder

String CSS Value <div style="width: UNTRUSTED

DATA;">Selection</div>

Strict structural validation

CSS Hex encoding

Good design of CSS

Features

String JavaScript

Variable

<script>var currentValue='UNTRUSTED

DATA';</script>

<script>someFunction('UNTRUSTED

DATA');</script>

Ensure JavaScript

variables are quoted

JavaScript Hex Encoding

JavaScript Unicode

Encoding

Avoid backslash encoding

(\" or \' or \\)

HTML HTML Body <div>UNTRUSTED HTML</div>

HTML Validation (JSoup,

AntiSamy, HTML

Sanitizer)

String DOM XSS <script>document.write("UNTRUSTED

INPUT: " + document.location.hash);<script/>

DOM based XSS

Prevention Cheat Sheet

Referencia directa insegura a objetos

Esta vulnerabilida ocurre cuando el desarrollador hace referencia a un objeto como un archivo,

directorio, registro de la base de datos o clave, puede ser una dirección URL o un parámetro de un

formulario.

Por ejemplo en las aplicaciones bancarias de internet es común utilizar la cuenta del cliente como

clave primaria, sin embargo si la cuenta es utilizada directamente en la interfaz web aunque tenga

consultas parametrizadas de SQL que prevean la inyección un atacante puede manipular el número

de cuenta y cambiar el parámetro para que le muestre todas las cuentas.

Ejemplo de vulnerabilidad:

<select name="language"><option value="fr">Français</option></select>

…

require_once ($_REQUEST['language’]."lang.php");

Si el codigo permite al usuario cambiar paths, o nombres de archive puede llegar a directories o

archivos.

Configuración de seguridad incorrecta

Se debe asegurar que el servidor de producción cuente con una configuración adecuada, asi como

un manejo adecuado del manejo de errores que no muestre demasiada información al usuario lo

que puede llevar a que estos exploren esos fallos.

Así también es necesario que dentro de la configuración a los usuarios no se permita acceso a

directorios o configuraciones que puedan en algún momento acceder a los archivos compilados del

lenguaje utilizado en los que puedan utilizar ingeniería inversa y encontrar fallas en el manejo de la

validación de usuarios.

Configurar los ambientes de desarrollo, UAT y producción con los mismo niveles de seguridad y

passwords diferentes.

Mantener actualizado nuestro software tanto como SO, DBMS, parches de seguridad y tener

siempre actualizados nuestros componentes.

Exposición de datos Sensibles

Esta categoría surge de la fusión y ampliación de las anteriores A7 y A9. Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos almacenados mediante técnicas criptográficas adecuadas (p.ej. manteniendo el hash de la contraseña en vez de la propia contraseña cifrada), así como también de precauciones especiales en el intercambio de datos con el navegador.

Los riesgos completos de utilizar cifrado de forma no segura, uso de SSL y protección de datos

escapan al alcance del top 10. Dicho esto para los datos sensibles de debe realizar como minimo lo

siguiente:

I. Cifrar los datos internos sensibles o en trafico de manera de defenderse de estas amenazas.

II. No almacene datos sensibles innecesariamente. Descartelos apenas sea posible.

III. Asegurese de aplicar algoritmos de cifrado fuertes y estándar asi como claves fuertes y

gestiónelas de forma segura.

IV. Deshabilite la opción de autocompletar en los formularios que recolectan datos sensibles (

ej. Usuarios, contraseñas)

Inexistente Control de Acceso a nivel de funcionalidades

Este riesgo básicamente se refiere a un débil control de accesos a las páginas restringidas en el cual

el atacante tratara de accesar a las páginas de administración de la aplicación.

Para solventar este inconveniente se debe contar con roles y segregación de funciones

parametrizables para que su mantenimiento sea factible.

Falsificación de peticiones en Sitios Cruzados (CSRF)

Básicamente este vulnerabilidad explota las peticiones que un cliente real realiza al servidor con el

objetivo de malisiosamente cerrar una sesión o realizar acciones con el usuario autenticad, estos

problemas pueden reseolverse de las siguientes formas:

1. Incluir un captcha en cada solicitud para verificar que realmente es un persona la que realiza

la solicitud.

2. Incluir un tocken único que puede ser inlcuido en la propia URL o un parámetro d ela misma.

3. Incluir tokens secretos en JAVA EE, .NET y aplicaciones PHP.

4. Requerir que el usuario vuelva a autenticase o pruebas de que se trata de un usuario

legítimo.

Uso de componentes con vulnerabilidades conocidas

Algunos componentes son vulnerables pueden ser identificados y explotados por los atacantes, por

medio de su identificación y posterior explotación.

Debería ser fácil distinguir si estamos utilizando un componente que es vulnerable sin embargo los

frameworks y utilidades comerciales o de código abierto no especifican precisamente cuáles son sus

vulnerabilidades o deficiencias de seguridad

Lo mas apropiado es utilizar componentes que no ha codificado. La mayoría de proyectos utilizan

componentes que pueden o no estar actualizados, lo más recomendable es actualizarlos debido que

el fabricante al identificar una debilidad la corregirá en la siguiente versión.

Es indispensable que se cuente con una política de desarrollo en la cual se limite la utilización de

componentes a solo aquellos que sean de total confiabilidad de la empresa.

Redicciones y reenvíos no validos

Este riesgo se refiere específicamente a un redireccionamiento de los usuarios a sitios que no son

precisamente los que se indican en el link original.

Básicamente buscan enviar al usuario a otro sitio donde se puede instalar código malicioso o

engañar a las víctimas para que revelen información sensitiva (contraseñas, usuarios, etc.)

En este caso es imperativo utilizar una lista blanca para validar que los redireccionameintos cumplan

con ella porque en el caso que no cuente con este componente usted es vulnerable

CONCLUSIONES

Personalmente revisar este documento ha sido muy beneficioso para mi labor como

desarrollador, actualmente me encuentro desarrollando una aplicación web lo que me ha llevado a

explorar la seguridad con la que debo contar para implementarla correctamente, en el recorrido por

el documento se pueden revisar tanto riesgos que son detectables y corregibles fácilmente así como

aquellos que requerirán un poco más de investigación y conocimiento por parte del desarrollador

para poder mitigarlos.