Mas fácil:

<?php
$var[1]= 'hola';
$var[2] = 'adios';
$var[3] = 'algo mas';
echo $var[rand(1,count($var))];
?>

No puede ser  pueden mover este post al subforo de "nivel web" por favor? XDDDD

A estas alturas no es muy de extrañarse fallas en la web de karpesky, se caen los aviones y no se puede caer uno.. multiples inyecciones sql en microsoft y en msn.com inclusive hasta hoy en dia, fallas en la web de la nasa.. cuantas veces fueron desfaceados? joomla, smf, vbulleta, y por que los de karpesky no pueden tener sus agujeros? claramente serán arreglados (supongo o talves solo en parte como casi todos lo hacen) pero cuando se ve que se encuentran fallas una, dos , tres, diez, muchas veces entonces ya como que valen madre XD pero naa no creo que la seguridad de sus productos se refleje por una falla de seguridad en su sitio web a menos que esto fuese repetitivo porque en ese caso uno tendría una visión diferente de la mentalidad de los desarrolladores que contratan.

echo '<a href="'.$web'.'?'.'var='.'$cadena[0]'" target="_blank">$cadena[0]</a>';
No puedes abrir o cerra con una comilla despues de una variable si no le pones un punto para unir..


Pongamoslo con geshi:

Tu código:

echo '<a href="'.$web'.'?'.'var='.'$cadena[0]'" target="_blank">$cadena[0]</a>';

Mi código:

echo '<a href="'.$web.'?var='.$cadena[0].'" target="_blank">'.$cadena[0].'</a>';

Así es pero por lo general una buena programación te hace filtrar las variables antes de ser utilizadas removiendo los slashses y después de eso continúa todo el script y evitas tener que filtrar los datos con esa función cada ves que metas valores en funciones o algo.

<?php
// Realizar un set_magic_quotes_runtime(0) con allstripslashses por WHK
 
// Uso:
$_POST = allstripslashses($_POST);
$_GET = allstripslashses($_GET);
$_COOKIE = allstripslashses($_COOKIE);
$_SERVER = allstripslashses($_SERVER);
$_REQUEST = allstripslashses($_REQUEST);
$palabra = allstripslashses("cmd /c echo \'%homedrive%\\ = c:\\\' ");
 
// Imprime resultados
echo htmlspecialchars($palabra, ENT_QUOTES);
echo '<br />Arrays totales:<br />';
print_r($_POST);
print_r($_GET);
print_r($_COOKIE);
print_r($_SERVER);
print_r($_REQUEST);
 
// Función
function allstripslashses($data){
 if(is_array($data)){
  foreach($data as $variable => $valor){
   $retorno[stripslashes($variable)] = stripslashes($valor);
  }
  return $retorno;
 }else{
  return stripslashes($data);
 }
}
 
?>

Es casi lo mismo que utilizar set_magic_quotes_runtime(0) solo que en algunos servidores no puedes utilizar esta función así que apelas a un poco de ingenio para crear el mismo resultado.

Cuando quieras hacer una query ahora en mysql puedes hacerla directamente con mysql_real_escape_string($string).

Exacto.

Supongamos un esenario.. tengo un sitio web www.vztest.com y foro.vztest.com ahora suponiendo que www sea tu portal y el subdominio "foro" sea tu foro yo como atacante voy a mirar tu portal y veo que tiene un sistema gestor de descargas o algo que te permita tener acceso a ciertos archivos del servidor, en el caso de que quieras ver el archivo de configuración del foro donde tiene definodas las contraseñas de acceso a la base de datos primeramente tendrías que tener la ruta exacta de ese foro, supongamos que la ruta sea "public_html/forete" y el portal sea "public_html/" entonces primero debemos saber hacia donde está apuntando el gestor de descargas o lo que sea y tratamos de que forzadamente el servidor nos debuelva un error y con eso ya tenemos las rutas y apuntamos las descargas arbitrarias hacia los archivos objetivos. Ahora por ejemplo puede servir cuando dice "/home/www/sitios/vztest/public_html/main.php" para tener en cuenta de que dentro de ese servidor hay mas sitios alojados, etc etc. a veces puede decir "/opt/lampp/htdocs/index.php" y con eso ya puedes ver que está utilizando Xampp y puedes intentar acceder a algún sistema administrativo como www.vztest.com/xampp/ etc etc. Opciones son muchas, mientras mas información le des a un atacante será peor para tu sitio web.

Lo mas probable es que si alguien pudo entrar en un servidor con file disclosure es porque pudo ver un directorio que publicamente no se podia ver, por ejemplo "configuraciones/db.php" y ya con eso te vas a www.vztest.com/configuraciones y si no tiene un index en blanco o que haga una redirección se podrán ver todos los archivos y con eso mas un sistema web mal programado e inseguro lo mas probable es que haya podido realizar acciones de administración o descargar los famosos .php.inc que al final el php no los ejecuta pero si se descargan entregando tus códigos al atacante para que este los estudie y pueda hacer un ataque mas elaborado.

No puedo decir esas cosas acá  pero si puedo decir que tenia mucho mas que eso.

Disclosure en inglés significa "divulgación" asi que puedes deducir que cuando se trata de un file disclosure quiere decir que de alguna manera ocurrió una falla en el sistema web que te permite ver la ubicación real del archivo y como se llama, cuando puedes ver directorios del servidor se llama path disclosure, por ejemplo cuando un php te lanza un error te dice:
Esto sig nifica que talves tu amigo pudo localizar un archivo alojado en algun directorio administrativo o que se yo.
En asp también hay formas de hacer que el script lanze errores mostrando la ruta del archivo.

He localizado una falla en Joomde tipo CSRF (Cross Site Rquest Forgery) que permite a un atacante la posibilidad de eliminar el directorio completo de imagenes lo cual sería fatál como para un sitio de noticias donde prescindisa de sus imagenes para poder dar su información. Esta falla no permite al atacante la posibilidad de subir un archivo ni eliminar los que estén fuera del directorio "/images".

La falla se localiza en el módulo de Administracion llamado "Media Manager" donde su petición GET para solicitar la eliminación de un directorio o archivo no incluye ningún Token o sistema de seguridad válido para impedir este tipo de ataques.

Prueba de concepto:
http://ejemplo.com/administrator/index.php?option=com_media&task=file.delete&tmpl=component&folder=directorio&rm[]=Imagen.jpg

El punto es que la falla se localiza en el archivo administrator/com_media/controllers/file.php en la linea 136 donde se omite el token de seguridad:





Un atacante necesitaría que el un usuario del sistema Joomla tenga derechos de Administración y caiga en algún tipo de engaño como una imagen falsa que redireccione hacia el borradoinicialmente del index.html que impidía ver los archivos, una ves eliminado el mismo script podría tener la capacidad de listar todos los archivos a eliminar con un segundo ataque puesto por ejemplo dos veces en una misma firma dentro de algún foro o publicación parcial del mismo sistema como editor.

Nota:
Los archivos que pueden ser eliminados no necesariamente deben ser imagenes ya que el sistema solo permite la subida de imagenes pero la eliminación de cualquier tipo de archivo.
Para poder repararlo solamente debes agregar el token de seguridad tal como aparece en la función de subida.

Fuentes:
http://foro.elhacker.net/nivel_web/bug_en_joomla_159_eliminacion_del_directorio_de_imagenes_por_completo-t244742.0.html
http://www.jccharry.com/blog/2009/02/09/whk_vulnerabilidad-de-tipo-csrf-en-joomla-159.html
http://forum.joomla.org/viewtopic.php?f=300&t=371705