JUNIO 2009
Web
Aplication Vulnerabilities Parte 4 de 5
4ta Parte:
Cross Site Scripting - XSS
El éxito de este ataque requiere quela
víctima ejecute una url con código malicioso que a primera vista
parecería ser código legítimo. Cuando se clickea sobre una url
modificada manualmente un atacante puede hacer ejecutar código sobre
el browser de la vítima, por ejemplo algún código java malicioso
puede ser ejecutado en el contexto de un sitio web que se aprovecha
del bug XSS.
Rating: Moderado a
Crítico.
Algunos productos vulnerables:
Microsoft IIS web server, Yahoo Mail, Squirrel Mail, Google
search.
El ataque de Cross Site Scripting se
realiza a través de formularios en los cuales hay interacción
con el usuario, los siguientes son los objetivos más populares:
A continuación un ejemplo de ataque
XSS:
<form action="search.php" method="GET"
/>
Welcome!!
<p>Enter your name: <input type="text" name="name_1" /><br
/>
<input type="submit" value="Go" /></p><br>
</form>
<?php
echo "<p>Your Name <br />";
echo ($_GET[name_1]);
?>
El valor pasado por la variable 'name_1'
no está sanitizado entonces puede ser explotado para ejecutar
código arbitrario.
Otro ejemplo de explotación de este
ataque:
http://victim_site/clean.php?name_1=<script>code</script>
or
http://victim_site/clean.php?name_1=<script>alert(document.cookie);</script>
Contramedidas:
El siguiente código se recomienda
ingresar para resolver estos ataques:
<?php
$html= htmlentities($_GET['name_1'],ENT_QUOTES, 'UTF-8');
echo "<p>Your Name<br />";
echo ($html);
?>
Fuente: SecurityFocus
MAYO 2009
Web
Aplication Vulnerabilities Parte 3 de 5
3er Parte: Vulnerabilidades Format
String
Esta vulnerabilidad se
produce cuando el ingreso de entradas de usuario están sin filtrar,
generalmente son parámetros en código perl o C que realizan
funciones de formato, tales como printf ().
Un usuario
malintencionado puede utilizar el especificador de formato "%s" o "%x",
entre otros, para imprimir los datos de la pila o posiblemente otros
lugares de la memoria. Inclusive, puede escribir datos arbitrarios
en lugares arbitrarios de la memoria utilizando el especificador de
formato %n.
Las vulnerabilidades
Format String se podrían clasificar en tres categorías: denegación
de servicio, lectura y escritura.
Rating: Moderado a
Crítico.
Algunos Productos
Vulnerables:
McAfee AV, Usermin,
Webmin, various Apache modules, winRar, ettercap, entre otros.
-
Los ataques de
denegación de servicio se caracterizan por la utilización de
múltiples instancias del especificador de formato %s, este
especificador se utiliza para leer datos de la pila si se
generan múltiples peticiones hasta que el programa intente leer
datos desde una dirección ilegal se provocará que el programa se
caiga.
-
Los ataques de
lectura utilizan el especificador de formato %x, el cual es
utilizado para imprimir secciones de la memoria para las cuales
el usuario normalmente no tienen acceso.
-
Los ataques de
escritura utilizan especificadores de formato %d, %u o %x
para sobrescribir el puntero de instrucción y forzara la
ejecución de un shell (con permisos del usuario).
Este es un ejemplo del
archivo miniserv.pl (Webmin) que provoca esta vulnerabilidad:
if ($use_syslog && !$validated)
{
syslog("crit",
($nonexist ? "Non-existent" :
$expired ? "Expired" : "Invalid").
" login as $authuser from $acpthost");
}
Contramedida:
Modificar el código
fuente para que la entrada es verificada correctamente
Fuente: SecurityFocus
ABRIL 2009
Web Aplication Vulnerabilities Parte 2 de 5
2da Parte: SQL injection
La inyección de
SQL es un método muy antiguo, pero aún es popular entre los atacantes.
Esta técnica permite a un atacante obtener información crucial de un
servidor Web de la base de datos. Dependiendo de las medidas de
seguridad de la aplicación, el impacto de este ataque puede variar desde
la divulgación de información básica hasta la ejecución remota de código
y total compromiso del sistema.
Rating: Medio y Crítico
Productos Vulnerables:
PHPNuke, MyBB, Mambo CMS, ZenCart, osCommerce
MS SQL tiene la característica de llamadas de procedimiento almacenado
extendido (extended stored procedure), que permite ejecutar comandos a
nivel de sistema a través del servidor de MS SQL - como agregar un
usuario. Además, los mensajes de error mostrados por el servidor de MS
SQL revelan más información que un servidor MySQL. Mientras que MS SQL
Server no es especialmente propenso a ataques de inyección de SQL, hay
medidas de seguridad que deben aplicarse para que sea segura y no
permitir que el servidor SQL dé información crítica del sistema.
Este es un ejemplo de un código que puede ingresar un usuario y es
utilizado directamente como una query de SQL:
<form action="sql.php" method="POST" />
<p>Name: <input type="text" name="name" /><br />
<input type="submit" value="Add Comment" /></p>
</form>
<?php
$query = "SELECT * FROM users WHERE username = '{$_POST['username']}";
$result = mysql_query($query);
?>
Este script funciona normalmente cuando el campo username no contiene
ningún caracter malicioso:
$query = "SELECT * FROM users WHERE username = 'steve'";
Sin embargo una inyección de sql podría resultar de esta forma:
$query = "SELECT * FROM users WHERE username = '' or '1=1'";
Como la condición "or" es siempre verdadera, la función mysql_query va a
retornar los registros de la tabla de datos. Un ejemplo similar sería
usar "AND" y un comando de SQL que generaría un mensaje de error
específico:
Es obvio que este tipo de mensajes de error ayuda a un atacante a
obtener la información que está buscando (nombre de la tabla, de la base
de datos, usuarios, hashes de contraseñas, etc.). Mostrar mensajes de
error personalizados puede ser una buena solución para este problema,
sin embargo, existe otra técnica conocida como ataque de inyección de
SQL a ciegas (Blind SQL Injection), donde el atacante es todavía capaz
de llevar a cabo una inyección de SQL, incluso cuando la solicitud no
revela ningún mensaje de error del servidor de base de datos que
contenga información útil para el atacante.
Contramedidas:
Evite conectar a la base de datos como superusuario o como el
propietario de la base de datos. Utilice siempre usuarios personalizados
para conectar a la base de datos con el mínimo privilegio necesario para
realizar la tarea asignada.
PHP tiene dos funciones para MySQL que sanitizan los imputs del usuario:
addslashes (el más viejo) y mysql_real_escape_string (el método
recomendado). Esta función viene con PHP >= 4.3.0, por lo que debe
comprobar primero si existe esta función y que esté ejecutando la última
versión de PHP 4 o 5.
Fuente: Security Focus
| 
