->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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. ""
Seria interceptado y probablemente dejar¡a de funcionar). Mientras esto es un
problema la meta del atacante es poder ejecutar comandos en el server remoto y
pueden hacerlo creando en el disco local un formulario en donde el campo archivo
sea "theme" y usar este formulario para enviar un archivo php que previamente
preparamos. PHP va a grabar el archivo y asigna la variable $theme. La funci¢n
file_exists() se fija y despu‚s de c¢digo se ejecuta.
Teniendo posibilidad de ejecutar archivos php en el server remoto se pretender
obtener un aumento de privilegios, para lo cual necesitaremos alguna
herramientas que no tenemos en el server. La posibilidad de Hacer upload de
archivos hacer de nuevo esto no ser un problema, podes simplemente hacer uploads
de las herramientas de ataque y grabarlas, despu‚s hay que usar chmod() y
despu‚s ejecutar el archivo. Por ejemplo, podes hacer upload de un exploit root
( pasar el firewall y pasar el IDS) y ejecutarlo.
"It was easier to know it than to explain why I knew it. If you were asked
to prove that two and two made four, you might find some difficulty, and yet
you are quite sure of the fact" - Sherlock Holmes
--- < 6. Librer¡as o Bibliotecas > ---------------------------------------------
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