[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
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
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
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
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
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
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
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
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
Para ver si es vulnerable podemos ejecutar el siguiente link con el siguiente codigo
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()
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
Como ven , si queremos saber si la pagina es vulnerable a RFI podemos hacer asi
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
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
Para saber si es vulnerable podemos cargar la variable car con un ' de la siguiente manera
Y si nos devuelve algo asi
Es porque es vulnerable xDDD
Para protegernos de esta vulnerabilidad seria de la misma forma que RFI
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.
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
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
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
Que feo programo xDDD
Entonces el error que nos devuelve seria este
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
Entonces si ponemos la ruta que queremos en la variable "down" estamos hecho.
Un ejemplo de uso seria este
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
Como ven , es un caso muy raro y especial en cierto sentido xDDD
Entonces si ejecutamos este link
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 ?
--========--
[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 [Seleccionar]
<title>LABS SQL INYECTION</title>
<STYLE type="text/css">
body {
background-color: #000000;
color:orange;
font-family:
Courier New;
cursor:crosshair;
font-size: small;
}
</style>
<center><h1><font color=green>LABS SQL INYECTION</font></h1><br><br><br>
<?php
$host = 'localhost';
$user = 'root';
$datos = 'users';
$conexion = mysql_connect($host, $user);
mysql_select_db($datos,$conexion);
if (isset($_GET['id'])) {
$id = $_GET['id'];
}
if(empty($id)){
$id = "1";
}
$sql = mysql_query("SELECT * FROM `hackers` WHERE id=".$id) or die (mysql_error());
$resultado = mysql_fetch_row($sql);
echo "<h3><b>id: </font>".$resultado[0]."<br>";
echo "user: </font>".$resultado[1]."<br>";
echo "pass: </font>".$resultado[2]."</b></h3><br>";
mysql_close($conexion);
?>
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 [Seleccionar]
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 [Seleccionar]
if (!is_numeric($_GET['id'])) {
echo "no me jodas !!!<br>";
exit(1);
}
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 [Seleccionar]
<title>LABS SQL INYECTION</title>
<STYLE type="text/css">
body {
background-color: #000000;
color:orange;
font-family:
Courier New;
cursor:crosshair;
font-size: small;
}
</style>
<center><h1><font color=green>LABS SQL INYECTION</font></h1><br><br><br>
<?php
$host = 'localhost';
$user = 'root';
$datos = 'hackman';
$conexion = mysql_connect($host, $user,"123");
mysql_select_db($datos,$conexion);
if (isset($_GET['id'])) {
$id = $_GET['id'];
}
if(empty($id)){
$id = "1";
}
$sql = @mysql_query("SELECT * FROM `hackers` WHERE id=".$id);
$resultado = @mysql_fetch_row($sql);
echo "<h3><b>id: </font>".$resultado[0]."<br>";
echo "user: </font>".$resultado[1]."<br>";
echo "pass: </font>".$resultado[2]."</b></h3><br>";
mysql_close($conexion);
?>
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 [Seleccionar]
http://127.0.0.1/sql.php?id=1+and+1=1
Código [Seleccionar]
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 [Seleccionar]
if (!is_numeric($_GET['id'])) {
echo "no me jodas !!!<br>";
exit(1);
}
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 [Seleccionar]
<?php
echo "
<form action='' method=POST>
<input type=text name=mensaje>
<input type=submit value=Mostrar>
</form>
";
if (isset($_POST['mensaje'])) {
echo $_POST['mensaje'];
}
?>
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 [Seleccionar]
<?php
echo "
<form action='' method=POST>
<input type=text name=mensaje>
<input type=submit value=Mostrar>
</form>
";
if (isset($_POST['mensaje'])) {
echo htmlentites($_POST['mensaje']);
}
?>
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 [Seleccionar]
<?php
echo "
<form action='' method=GET>
<input type=text name=msg>
<input type=submit value=Mostrar>
</form>
";
if (isset($_GET['msg'])) {
echo $_GET['msg'];
}
?>
Para ver si es vulnerable podemos ejecutar el siguiente link con el siguiente codigo
Código [Seleccionar]
<script>alert("hola");</script>
Código [Seleccionar]
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 [Seleccionar]
<?php
echo "
<form action='' method=GET>
<input type=text name=msg>
<input type=submit value=Mostrar>
</form>
";
if (isset($_GET['msg'])) {
echo htmlspecialchars($_GET['msg']);
}
?>
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 [Seleccionar]
<?php
if (isset($_GET['car'])) {
include($_GET['car']);
}
?>
Como ven , si queremos saber si la pagina es vulnerable a RFI podemos hacer asi
Código [Seleccionar]
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 [Seleccionar]
if (isset($_GET['car'])) {
if ($_GET['car'] == "veo") {
include("veo.php");
}
elseif($_GET['car'] == "noveo") {
include("noveo.php");
}
else {
echo "no intentes cosas raras xDDD";
}
}
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 [Seleccionar]
<?php
if (isset($_GET['car'])) {
include($_GET['car']);
}
?>
Para saber si es vulnerable podemos cargar la variable car con un ' de la siguiente manera
Código [Seleccionar]
http://127.0.0.1/lfi.php?car='
Y si nos devuelve algo asi
Código [Seleccionar]
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 [Seleccionar]
if (isset($_GET['car'])) {
if ($_GET['car'] == "veo") {
include("veo.php");
}
elseif($_GET['car'] == "noveo") {
include("noveo.php");
}
else {
echo "no intentes cosas raras xDDD";
}
}
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 [Seleccionar]
<?php
echo "
<form action='' method=POST
<input type=text name=cmd>
<input type=submit value=mandar>
</form>
";
if (isset($_POST['cmd'])) {
system("ping ".$_POST['cmd']);
}
?>
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 [Seleccionar]
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 [Seleccionar]
<?php
echo "
<form action='' method=POST
<input type=text name=cmd>
<input type=submit value=mandar>
</form>
";
if (isset($_POST['cmd'])) {
$cmd = $_POST['cmd'];
$cmd = str_replace("&&", "", $cmd);
$cmd = str_replace(";", "", $cmd);
$cmd = str_replace("-", "", $cmd);
$cmd = str_replace("?", "", $cmd);
$cmd = str_replace("||", "", $cmd);
$cmd = str_replace("|", "", $cmd);
$cmd = stripslashes($cmd);
system("ping ".$cmd);
}
?>
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 [Seleccionar]
<?php
if (isset("no se nada de php")) {
}
?>
Que feo programo xDDD
Entonces el error que nos devuelve seria este
Código [Seleccionar]
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 [Seleccionar]
if (isset($_GET['down'])) {
header("Content-Type: application/octet-stream");
header("Content-Disposition: attachment; filename=".basename($_GET['down']));
readfile($_GET['down']);
}
Entonces si ponemos la ruta que queremos en la variable "down" estamos hecho.
Un ejemplo de uso seria este
Código [Seleccionar]
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 [Seleccionar]
<?php
if (isset($_GET['te'])) {
eval($_GET['te']);
}
?>
Como ven , es un caso muy raro y especial en cierto sentido xDDD
Entonces si ejecutamos este link
Código [Seleccionar]
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 ?
--========--