<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A Study In Scarlet Vulnerabilidades comunes en aplicaciones escritas en PHP Shaun Clowes SecureReality <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Traducido al espa¤ol por Di Biase Jos‚ Luis - josx@interorganic.com <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --- < Contenido > -------------------------------------------------- 1. Introducci¢n 2. Caveats y Alcance 3. Variables Globales 4. Archivos Remotos 5. Upload de Archivo 6. Librer¡as 7. Sesiones 8. Array asociativos y otros 9. Funciones que hay que utilizar con cuidado 10. Protegi‚ndose 11. Responsabilidad - Lenaguaje vs Programador 12. Otros "I could imagine his giving a friend a little pinch of the latest vegetable alkaloid, not out of malevolence, you understand, but simply out of a spirit of inquiry in order to have an accurate idea of the effects." - Stamford --- < 1. Introducci¢n > ---------------------------------------------------- Este investigaci¢n fue basada en la charla realizada durante BlackHat briefings en Singapur y Hong Kong en abril del a¤o 2001. Esta charla fue titulada "Breaking In Through the Front Door - The impact of Web Applications and Application Service Provision on Traditional Security Models". Aqu¡ se invirti¢ un gran tiempo comentando acerca de PHP. Para lo que no sepan que es PHP, PHP significa "PHP Hipertext Preprocessor". Es un lenguaje de programaci¢n ( dise¤ado especificamente para Internet ) en el cual PHP se embebe en las paginas web. Cuando un Cliente hace un pedido a una pagina, el servidor web primero pasa la pagina a un interprete de lenguaje que ejecuta el codigo, luego la pagina resultado es enviada al cliente. Obviamente esta aproximaci¢n esta mas relacionada con la naturaleza del paso de una pagina a otra de una aplicaci¢n web que de un lenguaje CGI como C y Perl. PHP ( y otros lenguaje para internet ) tienen la siguientes caracteristicas: + Interpretados + Ejecuci¢n R pida - El interprete esta dentro del servidor web, no fork() o setup overhead. + Muchas Utilidades - Cientos de funciones no triviales incluidas. + Sintaxis simple - no se declaran variables y variable poco tipeadas. Durante el transcurso de este escrito voy a tratar de explicar porque yo siento estas ultimas dos caracteristicas las que hacen a las aplicaciones escritas en PHP f cil de atacar y dificil para defender. Despu‚s voy a terminar con un planteo acerca de la distribucion de culpas cuando se habla de seguridad del software. "You must study him, then ... you'll find him a knotty problem, though. I'll wager he learns more about you than you about him." - Stamford --- < 2. Caveats y Alcance > ----------------------------------------------- Casi todas la observaciones de este escrito se refieren a una instalaci¢n de PHP 4.0.4pl1 por default ( con soprte para Mysql, PostgreSQL, IMAP and OpenSSL ) corriendo bajo APACHE 1.3.19 en Linux. Esto quiere decir que el nivel lo que ocurre puede variar particularmente, ya que muchas veces el comportamiento de para la misma entrada es diferente en distintas versiones. Adem s, los que apoyan PHP tienden a defender el lenguaje basandose en que es totalmente configurable. Yo creo que la gran mayor¡a de usuarios no modifican la configuraci¢n por default. Por esto no siento presi¢n en defender mi posici¢n basada en las opciones de configuraci¢n, ademas inclui una secci¢n sobre como defender las aplicaciones PHP usando esas configuraciones. Algunas personas creen que esta clase de trabajo es Trivial o Obvio particularmente desde el punto de vista que yo no discuto acerca de vulnerabilidades especificas. Para probar que estos riesgos son reales y que hasta los programadores que tratan caen en estos 4 detallados advisories. "I have to be careful ... for I dabble with poisons a good deal." - Sherlock Holmes --- < 3. Variables Globales > ------------------------------------------------ Como mencionamos anteriormente, las variables en PHP no se declaran, son automaticamente creadas la primera vez que se usan. Se les pone el tipo automaticamente basada en contexto que son usadas. Esto es una forma muy conveniente de hacer las cosas desde la perspectiva del programador ( y obviamente es un herramienta escencial en un lenguaje de desarrllo de aplicaciones rapido ). Una vez creadas las variables pueden ser referenciadas desde cualquier parte del programa ( excepto en funciones donde debe ser explicitamente incluida con el 'global' (funci¢n). El resultado de estas caracter¡sticas es que las variables son casi nunca inicializadas por el programador, despu‚s de todo, cuando son creadas est n vac¡as ( ej. ""). Obviamente el Main de una aplicaci¢n web basadas en PHP toma alguna entrada del cliente ( variables de formulario, upload de archivos, cookiw etc), Procesa la entrada y devuelve una salida basada en esa entrada. Para hacerlo lo mas simple posible la entrada casi siempre es proveida en la forma de variables globales. Como en este codigo html:
Esto mostrar un text box y un boton de submit. Cuando el usuario aprieta el bot¢n de submit el script de PHP test.php se ejecuta para procesar la entrada. Cuando se ejecuta la variable $hello contendr el texto que el usuario puso en el text box. Es importante darse cuenta las implicaciones de esto £ltimo, esto quiere decir que un atacante desde remoto puede crear cualquier variable que desee y tenerla declarada como global. Si encambio de usar el form anterior para llamar a test.php, el atacante llama directamente a la url como "http://server/test.php?hello=hi&setup=no", no solo ser $hello="hi" cuando el script se ejecute sino que $setup ser "no" tambi‚n. Un ejemplo dde como esto puede ser realmente un problema real es en un script que fue dise¤ado para autentificar a usuarios antes de mostrarlo informaci¢n importante. Por ejemplo: En una operaci¢n normal el c¢digo se fijar el password para decidir si el usuario debe ser autentificado. Despu‚s se fija si ya fue autentificado y muestra un informaci¢n importante. El problema radica en que el c¢digo incorrectamente asume que la variable $auth estar vac¡a a menos que se llene desde ah¡. Recordando que un atacante puede crear variables como globales, una url como 'http://server/test.php?auth=1' haria que falle la autentificaci¢n del password pero igualmente el script crea que estoy autentificado. Para redondear lo anterior, un script PHP no puede confiar en ninguna variable si no fue expl¡citamente asignada. Cuando uno tiene un gran numero de variables, esto puede ser una tarea muy ardua. Una aproximaci¢n para proteger un script es fijarse que variables no est n en el array HTTP_GET/POST_VARS[] (dependiendo del m‚todo que se use para enviar el formulario GET o POST ). Cuando se configura PHP con track_vars enabled ( como lo es como default ) las variables enviadas por el usuarios estan disponibles en dos lugares, como variables globales y tambi‚n como elementos de un array que mencionamos anteriormenet. Igualmente, es importante darse cuenta de que hay cuatro arrays diferentes para la entrada del usuario, HTTP_GET_VARS para las variables enviadas en la URL de la pericion GET, HTTP_POST_VARS para las variables enviadas de manera POST, HTTP_COOKIW_VARS para las variables enviadas como parte del header de cookies y de una manera limitada el HTTP_POST_FILES ( en las versiones mas recientes de PHP ). Un script seguro tiene que fijarse en los 4 arrays. "No man burdens his mind with small matters unless he has some very good reason for doing so." - John Watson --- < 4. Archivos Remotos > ---------------------------------------------------- Voy a repetir esto con frecuencia durante este escrito, PHP es un lenguaje muy rico, viene con una gran cantidad de funcionalidades y trata de hacerle la vida f cil al programador para programar ( o dise¤ador web como a veces es ). Desde la perspectiva de la seguridad, cuanto mas funcionalidad superflua ofrece un lenguaje y menos intutitivas las posibilidades, se hace m s dificultoso escribir aplicaciones seguras. Un exelente ejemplo de esto es la funcionalidad de Archivos Remotos de PHP. El codigo siguiente de PHP se utiliza para abrir un archivo: \n"); ?> El c¢digo abre un archivo especificado en la variable $filename para leerlo. Si falla muestra un mensaje de error. Obviamente esto puede llegar a ser un problema de seguridad si el usuario puede poner lo que quiera en $filename y por ejemplo mostrar /etc/passwd, pero de otra forma poco intuitiva se puede leer datos de otro sitio web/ftp. La funcionalidad de archivos remotos sirve justamente para que con casi cualquier funci¢n de manejo de archivos de PHP puede manejar transparentemente archivos remotos por HTTP and FTP. Si $filename tendria: (por ejemplo) http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir PHP har¡a una petici¢n HTTP al server "destino", en este caso tratando de explotar la falla unicode. Esto es mas interesante con relaci¢n a otras 4 funciones que tiene incluida la funcionalidad de archivos remotos (*** excepto en Window ***), include(), require(), include_once() y require_once(). Estas funciones toman un archivo lo leen, y lo parsean como c¢digo php. Son usadas la mayor¡a de las veces para usar librer¡as (o bibliotecas), donde hay c¢digo php y se la incluye cuando se la necesita. Ahora mira el siguiente c¢digo: Aparentemente $libdir es una variable de configuraci¢n que ya hemos asignado anteriormente en el c¢digo, que contiene el directorio en donde est n los archivos de las librer¡as. Si el atacante puede hacer que la variable no la asigne el script (lo que es una tarea no tan dificultosa) y en vez de hacer submit puede modificar en comienzo del path. Esto no sirve para nada por que solo tienen acceso a el archivo languages.php en el directorio que ellos elijan ( ataques del tipo poison null como en perl no funcionan con PHP) pero si pueden grabar un archivo llamado languages.php en cualquier directorio conteniendo por ejemplo: despu‚s asignan $libdir a http:/// cuando php encuentra la sentencia include php hace la petici¢n HTTP al evilhost, extrae el c¢digo del atacante y lo ejecuta, d ndonos de esa manera un listado del /etc en el browser. Te t‚nes que dar cuenta que el cliente quiz s no este ni corriendo php por que se ejecuta el servidor remoto. "There are no crimes and no criminals in these days" - Sherlock Holmes --- < 5. Upload de archivos > -------------------------------------------------- Como si PHP no tuviera lo suficiente como para hacernos la vida mas f cil al atacante el lenguaje da soporte autom tico a RFC 1867 basado en el upload de archivos. Mira el form siguiente:
Este form permite al browser seleccionar un archivo del disco local y cuando se hace el submit el archivo se env¡a al server remoto. Esto es una funcionalidad de mucha utilidad pero la respuesta de PHP es muy peligrosa. Cuando PHP recibe la petici¢n, antes de empezar a parsear el script que se llamo autom ticamente recibe el archivo del usuario remoto, despu‚s cheque que no sea el archivo superior a la variable $MAX_FILE_SIZE (10kb n este caso) y el m ximo permitido desde el archivo de la configuraci¢n de PHP, si pasa estos test el archivo es grabado en el disco en un directorio temporal. Por favor lee lo anterior de nuevo no te hace sospechar algo, un usuario remoto puede enviar archivos que el quiera y antes de que el script decida si lo deja o no, el archivo se graba al disco. Voy a ignorar cualquier fuente de ataques que pueden o no posibles usando esta utilidad. En primer lugar consideremos un script alguien dise¤o para recibir un archivo. Como hemos descripto el archivo es recibido y grabado al disco local ( en la ubicaci¢n que se especifica en la configuraci¢n, casi siempre es /tmp ) con un nombre aleatorio ( ej. "phpxXuoXG" ). El script PHO necesita informaci¢n con respecto al archivo que subimos para procesarlo. Esto se hace de 2 maneras una en las primeras versiones php3, y otra es descripta en nuestro Advisory con respecto a lo que voy a contar ahora. De mas esta decir que el problema esta todav¡a en existencia, la mayor¡a de scripts se continua usando el viejo m‚todo. PHP da valor a 4 variables locales para describir a un archivo de upload, por ejemplo (nombres del form anterior): $hello = nombre del archivo en la maquina local (ej. "/tmp/phpxXuoXG") $hello_size = tama¤o en bytes del archivo (ej. 1024) $hello_name = El nombre original del archivo (ej"c:\\temp\\hello.txt") $hello_type = Mime type del archivo subido (ej. "text/plain") El script despu‚s procede a trabajar con el archivo v¡a la variable $hello. El problema es que no transparente que $hello no necesite ser una variable a la que PHP le haya dado valor y que el atacante simplemente le haya puesto lo que el desea. Mira el ejemplo: http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=text/ plain&hello_name=hello.txt El resultado de lo anterior es ( claro que tambi‚n se podr¡a haber hecho por POST ( hasta cookies )): $hello = "/etc/passwd" $hello_size = 10240 $hello_type = "text/plain" $hello_name = "hello.txt" Esta entrada exactamente da las variables que el script espera para darle valor, pero en vez de trabajar con el archivo remoto trabaja con /etc/passwd ( casi siempre resultando de esto exponiendo el contenido del mismo ). Este ataque puede ser usado para exponer el contenido de cualquier archivo ( en particular archivos de configuraci¢n ) Las versiones de PHP m s nuevas traen distintos m‚todos para determinar los archivos remotos ( se hace v¡a HTTP_POST_FILES[] array ). Tambi‚n trae funciones para no tener este problema, por ejemplo una funci¢n para determinar si un archivo en particular es uno de los archivos que se hizo el upload. Estos m‚todos tratan de solucionar el problema pero la mayor¡a script que andan dando vuelta todav¡a utilizan en viejo m‚todo y son vulnerables a esta clase de ataque. Como una alternativa de ataque asistido haciendo upload de archivos esta el siguiente c¢digo: Si el ataque puede controlar $theme pueden obviamente usar esto para leer cualquier archivo en sistema remoto (excepto que dentro de los tags PHP ej. " --------------------------------------------- Mencione antes el include() u require(), y tambi‚n dije que generalmente se usan con el concepto de librer¡as. Lo que se hace generalmente es ponerlas en archivos diferentes y usarlas cuando se las necesita mediante include(). Include y require toman un archivo especifico lo leen y lo parsean su contenido como c¢digo php. Inicialmente cuando se empieza a desarrollar y distribuir las aplicaciones PHP se hace una distinci¢n entre la aplicaci¢n principal y las librer¡as d ndole nombres con la extensi¢n .inc por ejemplo. Esto es un error ya que com£nmente estos archivos no son parseados como PHP por lo tanto al hacer una petici¢n desde el browser el c¢digo fuente es mostrado. Por eso el interprete de PHP (cuando se usa como un modulo del apache) determina que tipo de extensi¢n de archivos debe interpretar y el administrador usualmente utiliza '.php', '.php3', 'php4'. Esto es realmente es peligroso ya que en esos archivos pueden estar los usuarios de base de datos, etc. La soluci¢n mas simple es simplemente darle a cada archivo una extensi¢n que sea parseada por el interprete de PHP. Esto te previene de que env¡es el c¢digo fuente de archivos que contengan c¢digo PHP. Ac vamos a mostrar un ejemplo de los problemas de contexto al utilizar la funci¢n include de lo cual hab¡amos hablado antes: En main.php: In libdir/loadlanguage.php: Cuando libdir/loadlanguage.php es llamado en el entorno de main.php es perfectamente seguro. Pero porque libdir/loadlanguage tiene extensi¢n .php ( no tiene por que tener esa extensi¢n funciona con cualquiera ) puede ser pedido y ejecutado por un atacante remoto. Cuando esta fuera del contexto de main.php es atacante puede asignar $libdir y $userLang con lo que el quiera. "You know a conjuror gets no credit when once he has explained his trick and if I show you too much of my method of working, you will come to the conclusion that I am a very ordinary individual after all" - Sherlock Holmes --- < 7. Archivos de Sesi¢n > -------------------------------------------------- - En versiones de PHP ( 4 y posteriores ) se provee soporte para sesiones. Sirven para poder grabar informaci¢n y mantenerla pagina a pagina en un a aplicaci¢n PHP. Por ejemplo cuando un usuario se loguea en el website se puede grabar en una sesi¢n. Cuando el consulta la informaci¢n del sitio la informaci¢n va a estar disponible para otras paginas PHP. Lo que pasa cuando se inicia una sesi¢n ( es com£nmente poner en e archivo de configuraci¢n que se inicie autom ticamente con la primera petici¢n ) un identificador de sesi¢n aleatorio se crea, la sesi¢n queda mientras que el browser env¡e el identificador con la petici¢n. Esto mismo es m s f cil lograrlo con una cookie pero puede tambi‚n hacerse poniendo una variable de sesi¢n (identificador) en cada formulario en la cada p gina. La sesi¢n es una variable de almacenamiento, una aplicaci¢n PHP puede elegir registrar una variables en particular con la sesi¢n, su valor es luego almacenado en un archivo de sesi¢n al final y cargado en las variables al comienzo de cada script PHP. Un ejemplo es el que sigue: Cualquier script PHP despu‚s tiene accesibles la variable $sesion_auth a la que se le asigno "shaun", si se modifica recibir el valor modificado. Esto obviamente en una utilidad muy buena en un entorno sin estados como lo es la web pero la precauci¢n al usarlo tambi‚n es necesaria. Un problema es aegurarse que las variables vienen de la sesi¢n. Por ejemplo, con el c¢digo de arriba, si un script siguiente hace esto: Este c¢digo asume que si $session_auth esta asignada, debe haber venido de la sesi¢n y del entrada remota. Si un atacante especifica $session_auth desde la entrada con un formulario el puede acceder a el sitio. Hay que darse cuenta de que el atacante debe usar este ataque antes de que la variable sea registrada en la sesi¢n, ya que una vez en la sesi¢n borrara cualquier entrada por formulario. La informaci¢n de la sesi¢n se graba en un archivo ( en una ubicaci¢n configurable, casi siempre /tmp ). Se la llama 'sess_' el puede encontrar tambi‚n el directorio que casi siempre es /tmp. Por £ltimo un problema al que no le encontr‚ la forma de uso es que el atacante puede especificar el id de sesi¢n que desea ( ej. 'hola') y tener un archivo de sesi¢n grabado con ese id (por ejemplo '/tmp/sess_hola'). El id puede solo contener caracteres alfanum‚ricos y esto puede ser muy £til en alguna situaciones. "It is a mistake to confound strangeness with mystery" - Sherlock Holmes --- < 8. Arrays Asociativos y otros > ----------------------------- Un breve descripci¢n de estos temas PHP es un lenguaje en el cual las variables tiene diferentes valores dependiendo del contexto en el que se eval£en. Por ejemplo, la variable $hello puede contener una cadena vac¡a y cuando se la eval£a como un numero tiene el valor 0. Esto £ltimo hace que el script llegue a estados en donde no se extra¤os ( este es un factor importante en el exploit de phpMyAdmin en SRADV00008 ). Si a la variable $hello se le asigna "000" no es igual a "0" pero la funci¢n empty() devuelve verdadero. En PHP los arrays son asociativos, lo que significa que el ¡ndice de array es una cadena y a la cual se le puede asignar caracteres. No es evaluado num‚ricamente, esto quiere decir que la entrada del array $hello["000"] no es lo mismo que la entrada $hello[0]; Las aplicaciones necesitan ser cuidadosas a la hora de validar la entrada del usuario para no estar en un estado inconsistente. Ej. No validar si algo es igual a 0 y despu‚s validar usando empy() en otro lugar. "We want something more than mere preaching now" - Mr. Gregson --- < 9. Funciones que hay que utilizar con cuidado > -------------------------- Cuando uno busca errores en las aplicaciones PHP (teniendo el c¢digo fuente) es muy £til tener una lista de funciones utilizadas mal frecuentemente. Si un usuario remoto puede cambiar los par metros de estas funciones la explotaci¢n a menudo es posible. Los siguiente es un lista poco exhaustiva: Ejecuci¢n de C¢digo PHP: require() y include() - Ambas leen una archivo especificado e interpretan el contenido como c¢digo PHP. eval() - Interpreta la cadena de caracteres enviada como c¢digo PHP. preg_replace() - Cuando se usa con el modificador /e interpreta el string de reemplazo como c¢digo PHP Ejecucici¢n de comandos: exec() - Ejecuta un comando especificado y devuelve la £ltima l¡nea de la salida del programa. passthru() - Ejecuta un comando y devuelve toda la salida de programa `` (backticks) - Ejecuta un comando y devuelve la salida en un array system() - Casi igual a passthru() pero no maneja informaci¢n binaria popen() - Ejecuta un comando y conecta su salida a la entrada de un descriptor de archivo. Archivos: fopen() - Abre un archivo y lo asocia a un descriptor de archivo readfile() - Lee un archivo y muestra el contenido en la salida (browser) file() - Lee el archivo entero en u array "There is mystery about this which stimulates the imagination; where there is no imagination there is no horror" - Sherlock Holmes --- < 10. Protegiendose > -------------------------------------------------- Todos los ataques que describ¡ funcionan perfectamente en la instalaci¢n por defecto de PHP4. De todas formas he mencionado en numerosas ocasiones que a PHP se lo puede configurar muchas formas y muchos de estos ataques se puede eliminar usando esas opciones de configuraci¢n. Igualmente siempre hay que pagar un precio por la seguridad, entonces clasifique la configuraci¢n de acuerdo a los menos problem tico: * = sin problemas ** = vagamente problem tico *** = problema serio **** = Tortura china Obviamente mi calificaci¢n es subjetiva. Una cosa m s, si usas todas las opciones tendr s una instalaci¢n de PHP muy segura, hasta c¢digo de otras personas ser confiable, lo malo es que la mayor¡a no va a funcionar :) **** - Poner register_globals off Esta opci¢n hace que PHP deje de crear variables globales desde la entrada de usuario. Esto quiere decir que si el usuario env¡a un formulario con la variable 'hello' PHP no asigna $hello, solamente HTTP_GET/POST_VARS['hello']. Esta es la mejor opci¢n para cambiar para la seguridad de PHP. Lo malo es que hace la programaci¢n PHP menos conveniente. *** - Poner safe_mode on Me gustar¡a decir exactamente que hace pero no esta documentado completamente. Introduce una larga variedad de restricciones incluyendo: - La ventaja de restringir que comando se pueden ejecutar (por exec() etc) - La ventaja de restringir las funciones que pueden usarse - Restringe el acceso al archivo basado en los permisos de due¤o. - No permite subir archivos Esta es una opci¢n muy buena para los ambientes ISP (para los cuales se ha dise¤ado) pero puede tambi‚n ser muy bueno para mejorar la seguridad de los ambiente PHP. ** - Poner open_basedir Esta opci¢n no permite ninguna operaci¢n con archivos fuera de los directorios especificados. Esto puede efectivamente evitar ataques con archivos remotos o acceso a archivos locales con include(). ** - Poner display_errors off, log_errors on Esto hace que no se muestren los mensajes de error que devuelven las paginas web. Efectivamente limita la exploraci¢n de atacante. Hace el debugging frustrante. * - Poner allow_url_fopen off No permite la funcionalidad de archivos remotos. Pocos sitios necesitan esta funcionalidad. Debe haber otras opciones que se me escapan, por favor consulten la documentaci¢n de PHP. "Our ideas must be as broad as nature if we are to interpret nature" - Sherlock Holmes --- < 11. Responsabilidad - Lenguaje Vs Programador >--------------------- Me di cuenta que es muy dif¡cil escribir una aplicaci¢n PHP segura ( en la configuraci¢n por defecto ), aunque trates. No es que PHP sea un mal lenguaje, es muy £til y asombrosamente f cil de programar y tiene m s funcionalidad que otros lenguajes que conozco. De todas formas PHP tiene ‚nfasis en lo r pido en el desarrollo y lo siguiente: - Los dise¤adores Web y otros que no codifican terminan escribiendo aplicaciones en PHP. Ellos no entienden las implicaciones de seguridad. Si tu web site ha sido penetrado provee una entrada a la 3er capa, y siempre es un cosa mala, hasta si el acceso es como nobody. - El comportamiento del c¢digo se vuelve impredecible. Cuando se utilizan funciones como include() y se permite por ejemplo funcionalidades de llamada archivos remotos quien sabe como puede terminar eso, se puede volver una pesadilla. Muchas gente culpa a los programadores por el c¢digo que escriben, yo personalmente pienso que si el lenguaje hace dif¡cil al programador escribir buen c¢digo el lenguaje debe tener cierta culpabilidad. No esta bien solo decir que el programador deber¡a saber o conocer m s. "I have all the facts in my journal, and the public shall know them" - John Watson --- < 12. Otros> ----------------------------------------------------------- Esta solamente es una secci¢n para otros contenidos. Cuando pense que nadir esta interesado en la seguridad de PHP, puse algunos post/advisories/papers on-line: - Rain Forest Puppy RFP 2101 - "RFPlutonium to fuel your PHP-Nuke" http://www.wiretrip.net/rfp/p/doc.asp?id=60&iface=2 - JoÆo Gouveia Varios posts en Bugtraq, m¡ralos, pero como una selecci¢n: http://www.securityfocus.com/templates/archive.pike?list=1&mid=165519 http://www.securityfocus.com/templates/archive.pike?list=1&mid=147104 - Jouko Pynnonen http://www.securityfocus.com/templates/archive.pike?list=1&mid=169045 Hay muchos otros perdona que no los mencione. SecureReality ha hecho varios advisories acerca de aplicaciones PHP que muestran los problemas que anteriormente mencione. - SRADV00001 - Arbitrary File Disclosure through PHP File Upload http://www.securereality.com.au/sradv00001.html - SRADV00003 - Arbitrary File Disclosure through IMP http://www.securereality.com.au/sradv00003.html - SRADV00006 - Remote command execution vulnerabilities in phpGroupWare http://www.securereality.com.au/sradv00006.html - SRADV00008 - Remote command execution vulnerabilities in phpMyAdmin and phpPgAdmin http://www.securereality.com.au/sradv00008.txt - SRADV00009 - Remote command execution vulnerabilities in phpSecurePages http://www.securereality.com.au/sradv00009.txt - SRADV00010 - Remote command execution vulnerabilities in SquirrelMail http://www.securereality.com.au/sradv00010.txt - SRADV00011 - Remote command execution vulnerabilities in WebCalendar http://www.securereality.com.au/sradv00011.txt Los £ltimo cuatro los presente durante mi charla en BlackHat Briefings en Singapur y Asia en el 2001. Audio/Video de la charla estar disponible en http://www.blackhat.com. Para cualquiera interesado en seguridad le recomiendo que vaya y mire los briefings. "I must thank you for it all. I might not have gone but for you, and so have missed the finest study I ever came across: a study in scarlet eh?" - Sherlock Holmes Notas del traductor: Todas las frases de John Watson , Sherlock Holmes, etc no han sido traducidas para que conserven el idioma original. Los c¢digos fuentes en su mayor¡a tampoco fueron modificados para conservar lo que el autor quizo exponer. Muchas palabras de las de inform tica espec¡ficamente fueron tomadas literalmente ya que en Argentina se utilizan sin traducci¢n. Cualquier otra duda, comentario o problema contactense conmigo: josx@interorganic.com