Autor
[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>
<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:
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:
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:
<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:
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:
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:
<?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:
<?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:
<?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:
<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
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:
<?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:
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:
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:
<?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:
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:
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:
<?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:
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
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:
<?php
if (isset("no se nada de 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:
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:
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
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:
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 ?
--========--
En línea
