Título: [Guia] Vulnerabilidades a nivel web Publicado por: BigBear en 7 Octubre 2011, 01:28 am [Guia] Vulnerabilidades a nivel web
[Titulo] : Vulnerabilidades a nivel web [Autor] : Doddy Hackman [Temario] --===================================-- 0x01 : Introduccion 0x02 : SQLI 0x03 : Blind SQLI 0x04 : HTML Injection 0x05 : XSS 0x06 : RFI 0x07 : LFI 0x08 : Remote code Execution 0x09 : Full Path Discloure 0x10 : Full Source Discloure 0x11 : PHP Injections --===================================-- 0x01 : Introduccion Hola a todos. Eh empezado a hacer esta simple guia donde detallo de forma minima las vulnerabilidades mas comunes a nivel web , en cada vulnerabilidad solo explicare como se produce y como arreglarlo , pero no voy a ampliar demasiado en tecnias de cada una Cualquier error en la guia deben decirmelo para aprender de mis errores 0x02 : SQLI Las injecciones SQL son una de las vulnerabilidades mas usadas debido a que es una de las faciles de explotar cuando estas son encontradas. La injecciones SQL se producen cuando se incluye en una sentencia SQL una variable que no esta filtrada , entonces mediante la variable mal filtrada vamos a poder codigo que nos puedan ayudar a sacar columnas , extraer tablas y columnas , datos y todo eso......... Un ejemplo de este tipo de vulnerabilidad Código: <title>LABS SQL INYECTION</title> Como ven , la funcion mysql_query() usa un sentencia que posee la variable $id , como la variable $id no esta filtrada o protegida , se puede insertar codigo de la siguiente manera Código: http://127.0.0.1/sql.php?id= ¿AQUI? A partir del id podemos poner el codigo para ver si es vulnerable o no porque id es la variable mal filtrada Para saber si es vulnerable podemos poner un ' en el contenido de id Si el resultado de la pagina es algo como mysql error bla bla Es porque es vulnerable Una forma de protegerse de este ataque es verificar que $id sea un numero y no codigo raro para modificar la sentencia SQL Código:
Como vemos usamos is_numeric para la verificacion , pero usamos este para verificar que si $id no es un numero , este nos avise y nos diga no me jodas !!! 0x03 : Blind SQLI Las Blind SQLI vienen de la misma vulnerabilidad que las SQLI , pero en este caso el admin usa @ en las funciones para la conexion con la DB o error_reporting en 0 para que no tire errores. Un grave error pues asi esta provocando las conocidas Blind SQLI Un ejemplo de pagina vulnerable seria este Código: <title>LABS SQL INYECTION</title> como ven usamos @ para evitar errores las funciones mysql_query() y mysql_fetch_row() Entonces para comprobar que si la pagina es vulnerable a Blind SQLI podemos poner asi en la parte de id Código: http://127.0.0.1/sql.php?id=1+and+1=1 Código: http://127.0.0.1/sql.php?id=1+and+1=0 Si en el primer link devuelve un resultado positivo y en el segundo negativo (no muestra nada) Una forma de arreglar esta vulnerabilidad seria la misma que la de SQLI Código:
0x04 : HTML Injection Las HTML Injection son conocidas como las vulnerabilidades mas idiotas y faciles de hacer , pero , ¿los que dicen eso saben como se produce y como se arregla ? ,de ese estoy seguro que no . Esta vulnerabilidad se produce normalmente en los libros de visitas cuando se deja un comentario y se lo muestra en pantalla Un ejemplo seria este Código:
Si queremos probar si la pagina padece de esta vulnerabilidad solo tendriamos que poner algo de codigo html Si ponemos "<h1>hola</h1>" y se muestra como tal es porque es vulnerable La forma de protegerse es facil solo filtras las variables para protegerse Para hacer esto podemos usar htmlentities() o htmlspecialchars() , usen la que quieran pues las dos protegen Código:
0x05 : XSS Bueno , XSS es una vulnerabilidad conocida y util a la hora de robar cookies , la vulnerabilidad se produce cuando se muestra una variable mal filtrada Código:
Para ver si es vulnerable podemos ejecutar el siguiente link con el siguiente codigo Código: <script>alert("hola");</script> Código: http://127.0.0.1/xss.php?msg=<script>alert("hola");</script> Como ven la variable msg es enviada por metodo GET , la variable no es protegida y es mostrada tal cual Una forma de reparar es usar como htmlentities() o htmlspecialchars() Código: <?php 0x06 : RFI Bueno , el viejo RFI , esta vulnerablidad es muy conocida , se trata de un mal uso de la funcion include() y una mala configuracion de la variable allow_url_include estando On en php.ini Un ejemplo seria este Código: <?php Como ven , si queremos saber si la pagina es vulnerable a RFI podemos hacer asi Código: http://127.0.0.1/rfi.php?car=http://www.google.com.ar Y si la pagina muestra la pagina de google es porque la pagina es vulnerable a RFI Una forma de protegerse RFi seria usando un control en la variable "car" de la siguiente forma Código:
0x07 : LFI Bueno , el conocido LFI ,es parecido a RFI , pero este solo ejecuta archivos a nivel local y no remoto como RFI Un ejemplo de pagina vulnerable seria asi Código: <?php Para saber si es vulnerable podemos cargar la variable car con un ' de la siguiente manera Código: http://127.0.0.1/lfi.php?car=' Y si nos devuelve algo asi Código: Warning: include(') [function.include]: failed to open stream: No such file or directory in C:\xampp\htdocs\666.php on line 4 Es porque es vulnerable xDDD Para protegernos de esta vulnerabilidad seria de la misma forma que RFI Código:
0x08 : Remote code Execution Esta vulnerabilidad no es muy conocida , se trata de poder ejecutar comandos en la maquina atacada sin necesidad de crear una shell. Entonces un ejemplo de pagina vulnerable seria esta. Código: <?php Como ven la pagina hace un comando ping con system() a la ip marcada por ustedes Entonces que pasa si ponemos una ip cualquiera Pues nada solo hace un ping a la ip que pusieron Entonces si ponemos esto Código: ip && ver El servidor nos devolveria el resultado de el comando ping con un extra xDDD Pues si estamos viendo la version del SO Entonces la explicacion es simple solo ponemos && para agregar un comando siempre cuando la ip que pusieron anteriormente era real y el ping se mostro correctamente Entonces si queremos arreglar esta vulnerabilidad tenemos que reemplazar toda cosa rara en la variable de "cmd" Quedando el codigo de la siguiente manera Código: <?php 0x09 : Full Path Discloure Esta vulnerabilidad se produce cuando se produce un error , tanto como un error en el resultado de la funcion que estamos usando como la sintasis usada en la misma Un ejemplo seria este Código: <?php Que feo programo xDDD Entonces el error que nos devuelve seria este Código: Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in C:\xampp\htdocs\666.php on line 2 Como vemos nos devuelve el directorio actual donde se ejecuta el archivo php , esto es lo que se llama full path discloure Esta vulnerabilidad tambien aparece en SQL y LFI , cuando poniamos la comilla ' el resultado de include() y mysql_query() En el caso del segundo era una full path discloure ademas de estar indicando que la pagina realmente era vulnerable a SQL En el caso del primero tambien se debia al mal uso de la funcion include() devolviendonos un error con un full path discloure 0x10 : Full Source Discloure Bueno , esta vulnerabilidad nos permite descargar archivos de un servidor web debido a que no filtra las variables Un ejemplo seria este Código:
Entonces si ponemos la ruta que queremos en la variable "down" estamos hecho. Un ejemplo de uso seria este Código: http://127.0.0.1/down.php?down=c:/secretos.txt Y con eso descargariamos el archivo secreto si es que existe xDDD Entonces una forma de evitar esta vulnerabilidad seria usando una DB , que contenga una tabla con los links de descarga , entonces una vez que se detecte la variable down se verificaria que fuera un numero de lo contrario chau xDDD 0x11 : PHP Injections Bueno , la php injections suelen suceder cuando usa la funcion eval(). La funcion eval() nos permite ejecutar codigo php Un ejemplo de esta vulnerabildad seria este Código: <?php Como ven , es un caso muy raro y especial en cierto sentido xDDD Entonces si ejecutamos este link Código: http://127.0.0.1/php?te=echo "hola mundo"; Si vemos en la pantalla , este link nos devuelve hola mundo , creo que es obvio que es vulnerable Una forma de protegerse seria no usar eval() --========-- ¿ The End ? --========-- |