Bien en el post anterior preguntaba por como "asegurar" una variable para despues hacerle echo.
Ahora les pregunto, cuales son los errores mas comunes que deberia identificar en script como en el module search del phpnuke (se que es el mas comun a tener errores).
Esto es por que quiero testear un nuevo CMS que esta por salir. Ademas de que estoy empezando a hacer algunas aplicaciones en php y no me gustaria que me hackeen, para evitar que me hackeen deberia intentar hackearme yo primero no?
En fin, este post es para que lo respondan los expertos, como atom64... y demas entendidos de la materia.
Saludos, Eugenio
Hay algunas cosas relativamente simples de detectar que tendrías que cuidar:
1) Path disclosure: que ningún script del cms muestre la ruta completa desde la raíz del server a tu archivo
2) warnings: que ningún script del CMS te tire alertas, como las de sintaxis de mysql o las de php, que habitualmente terminan dando información útil al atacante para hacerte mierda la db.
3) SQL injection: que el atacante no pueda agregar pedazos de sentencias SQL en el medio de ningún query que el CMS haga
4) Validación de cadenas: Para forzar un path disclosure o una warning que les pueda ser útiles, a veces se pueden introducir cadenas como comentarios de php : /* */ y // que si el cms no limpia adecuadamente pueden llegar a dolerte mucho.
5) Comentarios peligrosos en el html. Ni hablar. Si dejás por ejemplo tu nombre de usuario y contraseña de mysql comentados en el código fuente
Y bueno, cualquier variedad de XSS que puedas encontrar dando vueltas.
6) Versión del CMS. En lo posible tratá de remover de todos lados la VERSIÓN del CMS. El nombre no, pero sí la versión. Esto suele hacer perder mucho tiempo al que intente joderte, buscando exploits que funcionen para tu versión, la que él desconoce.
7) Upload de archivos: Que el cms parsee BIEN los archivos que se suben, es decir, que si subís un shell script con extensión de foto por ejemplo, no te lo ejecute. Que sólo te permita subir archivos inofensivos -gif jpg png mp3- y que verifique que lo son realmente.
Te conviene usar un soft de auditoría como Acunetix, que aunque no son lo MEJOR, te aligeran un poco el trabajo.
Hmm, creo que polarBear ya abarcó casi todas las fallas más comunes, pero bueno... para que veas más como pueden ir las cosas:
no es tan importante si tu servidor está protegido, pero hay que tener un poco de control sobre el asunto.
| Quote: |
| warnings: que ningún script del CMS te tire alertas, como las de sintaxis de mysql o las de php, que habitualmente terminan dando información útil al atacante para hacerte mierda la db. |
las alertas no tienes por qué deshabilitarlas, son importantes para así detectar errores, lo que puedes hacer es simplemente utilizar otra salida para los errores, en lugar de mostrarlos en pantalla, que se guarden en un archivo ( o en el archivo de errores del servidor), que los envíe por e-mail, etc. Para más información sobre este tema dirígete a http://mx.php.net/errorfunc ahí encontrarás información útil.
| Quote: |
| 3) SQL injection: que el atacante no pueda agregar pedazos de sentencias SQL en el medio de ningún query que el CMS haga |
así es. Te recomiendo que cuando uses MySQL uses la función mysql_real_escape_string(). Además de pasar por una función que verifique los valores con todos los valores que vas a insertar en la base de datos. Me ha tocado ver con algunos sitios que por ejemplo guardan el valor del user-agent tal cual, sin escapar lo valores, ya que, creen que como es un valor enviado por el explorador no hay razón por la cual preocuparse, pero eso es un punto MUY importante, ya que cualquier persona puede conectarse a un sitio enviando cualquier UA, así pudiendo producir la inyección mediante el UA.
| Quote: |
| 4) Validación de cadenas: Para forzar un path disclosure o una warning que les pueda ser útiles, a veces se pueden introducir cadenas como comentarios de php : /* */ y // que si el cms no limpia adecuadamente pueden llegar a dolerte mucho. |
escapando las cadenas es suficiente, pero esto me recuerda en decir que cuando hagas salidas utilizes las funciones urlencode() para codificar los datos de variables (cuando el usuario haga 'click'), así como htmlentities() para salidas que no sean tags. Además de que nunca uses urldecode en parámetros enviados por el browser del usuario (como en $_GET y $_POST) ya que PHP ( o creo que el servidor, ahorita no me acuerdo) decodifica automáticamente esos valores al llegar, entonces, si usas urldecode() podrías obtener resultados inesperados
| Quote: |
| 5) Comentarios peligrosos en el html. Ni hablar. Si dejás por ejemplo tu nombre de usuario y contraseña de mysql comentados en el código fuente |
difícil que alguien lo haga, pero... podría sucede, jajaja
| Quote: |
| 6) Versión del CMS. En lo posible tratá de remover de todos lados la VERSIÓN del CMS. El nombre no, pero sí la versión. Esto suele hacer perder mucho tiempo al que intente joderte, buscando exploits que funcionen para tu versión, la que él desconoce. |
O simplemente si la versión es 2.0.19 entonces mostrar 2.0.X
| Quote: |
| 7) Upload de archivos: Que el cms parsee BIEN los archivos que se suben, es decir, que si subís un shell script con extensión de foto por ejemplo, no te lo ejecute. Que sólo te permita subir archivos inofensivos -gif jpg png mp3- y que verifique que lo son realmente. |
cuando un sistema de uploads recibe un archivo debe de verificar que la extensión concuerda con el tipo de archivo, esto se hace al analizar las 'marcas' de los archivos. Existe un programa que te permite identificar qué cosa es un archivo analizando el archivo en sí, y no tomando en cuenta la extensión del mismo.
Entonces haciendo un resúmen y añadiendo otros comentarios... cuando compares dos valores (uno 'original' y otro enviado por el usuario) que deben de ser números, utiliza is_numeric() en el valor enviado por el usuario primero, ya que sino.. el usuario podría introducir un valor que contiene números y texto y como PHP convierte automáticamente el tipo de las variables al hacer comparaciones, provocaría que el usuario podría introducir un valor que no sea numérico y así afectar el resultado. Debes de tomar la ofensiva cuando recibes datos del usuario, aún cuando sea un usuario 'de alto acceso' debes de mantener las reglas firmes, ya que si por algún otro error un usuario logra escalar de nivel, entonces estarías comprometiendo todo el sistema.
Espero que te sirva de ayuda, si algo no te quedó claro pregúntame ( mediante un post), y te invito a que leas algunos de los 'papers' de mi sitio ( están en inglés, así como el sitio) que incluyen información y cosas útiles. Lo creas o no, un proveedor de internet bastante grande de acá tenía hace menos de un año los datos del login de soporte técnico comentados en el head de la página de autenticación. Pobrísimo lo de esa gente.
Sobre las warnings, no hay por qué deshabilitarlas, pero siempre hay que tratar de asegurarse de que no tira ninguna antes de mostrarlo al público, porque si no le estás dejando una puerta abierta al usuario.
| polarBear wrote: |
| Lo creas o no, un proveedor de internet bastante grande de acá tenía hace menos de un año los datos del login de soporte técnico comentados en el head de la página de autenticación. Pobrísimo lo de esa gente. |
no se por qué... pero creo que este tipo de cosas siempre ocurre con empresas algo grandes, que no contratan buenoss programadores.
| polarBear wrote: |
| Sobre las warnings, no hay por qué deshabilitarlas, pero siempre hay que tratar de asegurarse de que no tira ninguna antes de mostrarlo al público, porque si no le estás dejando una puerta abierta al usuario. |
También hay que tomar en cuenta de que los errores no son todo... pero si es importante ocultarlos cuando se utiliza el sistema en un servidor público ( en producción), pero seguir recuperándolos mediante algún archivo.lo crean o no por un path disclousere me baje una base de datos con todos los usuarios y contraseñas de un sitio del gobierno, se podia entrar en el mail de cualquier diputado/politico.
estaban en un archivo XML, lo encontre de casualidad, principalmente entre por que tenian una galeria en una "sub" web, no era la principal, revisando por las carpetas en el directorio principal (public_html) encontre la base en xml, sin ningun tiupo de proteccion y encriptacion, intente avisarle al administrador pero al parecer el servidor de mail no preotegia a los usuarios del spam y su correo estaba saturado...
en fin, saludos
Eugenio
