es posible hackear php?

[eduardo160]

Hola quisiera saber si eso es posible el hackear el codigo php?....y bueno se que el codig mysql si se puede hackear...pero yo uso muchas veces como por ejemplo htmlentites() de php o en el mismo mysql el mysql_real_scape()....bueno saquenme de dudas porfavor se puede hackear entonces un codigo php? si es asi? como evitarlo :D gracias

[pateketrueke]

Es posible, casi cualquier lenguaje es hackeable.

O eso creo... en php solo basta con conocer las mismas funciones capaces de ejecutar acciones riesgosas o sensibles.

Por ejemplo, el ejecutar -incluir- código que no conoces es peligroso.

Así como como ejecutar comandos del sistema, por eso existía una directiva en la configuración de php, que ahora mismo no recuerdo.

Actualmente dicha configuración es obsoleta, así que si no conoces los riesgos de ejecutar ciertas acciones con php es posible que necesites profundizar en la lectura del lenguaje, pues corres el riesgo de dejar puertas abiertas en tus aplicaciones.

Otro ejemplo de hack sería el obtener información de tu sitio automatizadamente; o bien, dejar algún tipo de entrada -formulario de upload por ejemplo- sin control, y no me refiero solo al tipo de archivos y eso... sino a la capacidad de tu sistema para recibir cualquier tipo de petición sin control alguno.

En fin, es un tema verdaderamente complejo, y sin duda hay muchos detalle sin descubrir aún.

Y aún ahora sigue vigente una muy buena frase al respecto: "jamás confíes en usuario".

[eduardo160]

si tienes razon eh...eso que dices de jamas confies en usuario es purita verdad por eso..en mi codigo php toda la informacion que debo recibir por el usuario lo paso por muchisisimas cosas...para que no me hackeen la pag...bueno si alguien quiere dar un aporte y o idea para la seguridad en php o mysql...ps que lo diga para que todos sepamos porfavor :D gracias

[cristian_cena]

hola eduardo, aquí comparto unos códigos para evitar inyeccion sql y ataques xss, todo lo que venga por url en paginas php que no usan frameworks.
Estaría faltando ver el tema de RFI (Remote File Inclusion) y ver si no hace falta corregir algo en los archivos de configuración de apache.
Ojalá algún usuario avanzado (como pateketrueke por ejemplo ) nos de su punto de vista o experiencia al respecto así podemos ir mejorando.

Saludos

[Sourcegeek]

Es fácil, te cuesta mucho?
Trata de detectar entradas PHP inesperadas (en formularios, páginas que usen $_GET, cookies, etc) además de HTML y SQL también.

Recuerdo que en mis años de aprendiz, lo clásico (ya saben) un libro de visitas hice. Un amigo que me enseñaba en aquel entonces logró accesar a los datos del FTP inyectando código para abrir una webshell, todo porque nunca escapé (eliminé código malicioso de) una variable a la que le hacía include.

[vendoeninternet]

Supongo que te refieres a hackear con php. Hay varios scripts ya preparados para ello. En mi servidor colaron uno hace tiempo a través de una vulnerabilidad en una web hecha en php de un cliente.

Básicamente, con php, teniendo los suficientes permisos, pueden subir archivos, explorar todos los sitios del servidor a los que se tengan permisos, intentar conseguir contraseñas por fuerza bruta, acceder a sitios de forma remota, hacer spam...

En muchos servidores compartidos se puede tener permisos a los directorios de otros usuarios. La gente que pone tan contenta permisos 777 a sus archivos y son las primeras webs en caer.

Por eso, para que te de den por el 0, a veces no hace falta ni que tengas fallos de programación o en el código php. Solo hay que ser un poco ñoñas.

Incluso el php pueden salir vulnerabilidades pero bueno. Poder se puede y por eso hay que andar con cuidado y tener todo bien actualizado a las últimas versiones.

[cristian_cena]

@vendoeninternet, ¿podrías aclararme que relación tienen los permisos 777,etc con un script php?
Es decir, el administrador debe tener permisos 777, pero como hago para que solo el administrador (o usuario logueado) los tenga teniendo en cuenta que este tiene acceso a un panel de control a partir de que creamos una sesion para el.

En resumen si no existe la sesion no podrá entrar al panel y si la sesion fué creada entonces debemos darle todos los permisos. Lo que me hace suponer que la única cuestión sensible es la sesion más allá de los permisos que demos a los directorios.

@sourcegeek, ¿tienes a bien comentarme como trabajas con las variables e includes?, ya que según lo poco que sé no hay manera de que alguien pueda añadir valor a una variable salvo que esta venga por get o post. Sobre los includes tampoco entiendo como viene la mano, es decir, si coloco un include pues que riesgo existe si para que un tercero se haga con ese código debería hackear el servidor y no el sitio web.

@pateketrueke, ¿me enseñas que cuestiones tienes en cuenta cuando configuras php.ini? trabajando con php5

Desde ya muchas gracias por sus respuestas.

[pateketrueke]

cristian_cena, aquí:
http://www.forosdelweb.com/f142/form...hp-ini-589310/

[Triby]

cristian_cena, el riesgo de asignar permisos 777 (total para lectura, escritura y ejecucion) en servidores compartidos es que, dependiendo de la configuracion del servidor, se podria realizar una busqueda de directorios con esos permisos para guardar ahi codigos que el atacante ejecutaria despues y el poder obtenido seria practicamente ilimitado.

Respecto a la experiencia de Sourcegeek, solo falta aclarar que nunca debes hacer include directamente a una variable que pueda ser manipulada por el usuario, siempre hay que validar. Logicamente debes hacerlo para todo, ya sea guardar informacion en archivos de texto o en bases de datos, mostrar en pantalla, etc., siempre se deben validar y/o sanear todas las entradas.

[Sourcegeek]

@sourcegeek, ¿tienes a bien comentarme como trabajabas con las variables e includes?, ya que según lo poco que sé no hay manera de que alguien pueda añadir valor a una variable salvo que esta venga por get o post. Sobre los includes tampoco entiendo como viene la mano, es decir, si coloco un include pues que riesgo existe si para que un tercero se haga con ese código debería hackear el servidor y no el sitio web.

En mis tiempos de noob, hice algo como esto:

Código PHP:

  $panel = $_GET['id'];
include($panel); 
   

[emprear]

Quiero hacer una observación personal:

No todos podemos montar nuestro propio servidor a la hora de publicar una web.
La configuración del server y de php está limitada en muchos casos tan solo al administrador del sistema.

Creo que cualquier indicación para asegurar nuestro php, debería estar limitada a nuestras posibilidades como usuarios de un servicio de hosting, y no como administradores de uno.

Saludos

[Triby]

emprear, la mayoria de los que visitamos estos foros nos dedicamos a hacer webs y ahora la diferencia de costo entre un buen host reseller y un VPS es minima, por lo que es conveniente ver ambos aspectos.

Ya se comento que lo mejor es poder tener acceso a la configuracion de PHP, ya sea editando php.ini o usando ini_set() en nuestros scripts. En caso de que esto no se pueda, creeme que en ocasiones hay que crear codigos "raros y/o complejos" para lograr el objetivo, por ejemplo, desactivar el efecto de register_globals = on, donde se tienen que crear funciones o ciclos para recorrer los datos en riesgo $_GET, $_POST, $_SESSION, etc. y eliminar las variables que se crean automaticamente.

[pateketrueke]

emprear, la mayoría de servicios de hosting gratuitos cuentan con la configuración preestablecida para evitar cierto tipo de funciones, así como con una configuración limitada al respecto de acceso a ciertas funcionalidades.

El riesgo comienza cuando tenemos amplias posibilidades, y no hacemos caso de las sugerencias.

Edito: caray, creo que andamos sincronizados Triby

[maycolalvarez]

aparte de la debida configuración a PHP, mi esquema de seguridad es el siguiente:

-filtros XSS
-filtros SQL inyection
-HASH en contraseñas
-tokens CSRF
-filtros en file uploads
-evitar RFI

[cristian_cena]

cito a triby=
cristian_cena, el riesgo de asignar permisos 777 (total para lectura, escritura y ejecucion) en servidores compartidos es que, dependiendo de la configuracion del servidor, se podria realizar una busqueda de directorios con esos permisos para guardar ahi codigos que el atacante ejecutaria despues y el poder obtenido seria practicamente ilimitado.

Hola triby, gracias por responder, en mi caso contrato un servicio de hosting, digamos que hay que confiar en el servicio que se contrata, si restrinjo los permisos entonces ni yo podré hacer cambios esta es mi duda respecto de los permisos. No se si pasa todo por el hosting o yo debo escribir algo en php, la verdad no entiendo bien el tema de permisos de usuarios. O sea, si quito permisos 777 a una carpeta entonces por mas que con php quiera subir una imagen no voy a poder.

pateketrueke, el link sobre la configuracion de php.ini esta excelente, gracias.


cito a triby=
siempre se deben validar y/o sanear todas las entradas.

Gracias, me lo has dejado claro, yo pensaba que había que hacer algo con las variables que no vienen por get ni por post.

maycolalvarez
Gracias por compartir tu modo de trabajo, muy buen aporte.

[abimaelrc]

Bueno añadiendo material para que puedan entender mejor, siguiendo la línea de maycolalvarez
filtros XSS = http://www.acunetix.com/websitesecur...-scripting.htm combinarlo con http://www.forosdelweb.com/3497564-post2.html
filtros SQL Inyection = http://shiflett.org/blog/2006/jan/ad...-escape-string
HASH en contraseña = sha1, md5, crypt
tokens CSRF = http://shiflett.org/articles/cross-s...uest-forgeries
filtros en file uploads = fileinfo
evitar RFI = http://es.wikipedia.org/wiki/Remote_...sion_%28RFI%29

[cristian_cena]

jojo! abimaelrc te pasaste hermano! thanks!

[Gambinoh]

Iniciado por eduardo160

Hola quisiera saber si eso es posible el hackear el codigo php?....y bueno se que el codig mysql si se puede hackear...pero yo uso muchas veces como por ejemplo htmlentites() de php o en el mismo mysql el mysql_real_scape()....bueno saquenme de dudas porfavor se puede hackear entonces un codigo php? si es asi? como evitarlo :D gracias

Supongo que cuando dices que es posible hackear el código MySQL te estás refiriendo a las inyecciones SQL.

PHP permite establecer conexiones FTP, manejar ficheros, etc.

Yo no pondría la mano en el fuego...

ftp_exec($conexion, "comando")

PD: Que opinen los expertos :P

[vendoeninternet]

Iniciado por cristian_cena

@vendoeninternet, ¿podrías aclararme que relación tienen los permisos 777,etc con un script php?
Es decir, el administrador debe tener permisos 777, pero como hago para que solo el administrador (o usuario logueado) los tenga teniendo en cuenta que este tiene acceso a un panel de control a partir de que creamos una sesion para el.

El administrador no necesita tener permisos 777. El triple siete es para dar permisos a cualquiera de lectura, escritura y ejecución.

Php no puede leer archivos ni carpetas si no se tiene permisos. Si estás en un hosting y hablamos de haking, hay diferentes usuarios y 777 es para que, cualquier usuario del servidor pueda leer tus archivos, explorar lo que hay dentro y podrían sacar tus contraseñas si las tienen en archivos con permisos 777.

Los servidores suelen proteger el acceso a archivos y directorios entre usuarios pero no todos los paneles lo hacen así y las protecciones también pueden tener vulnerabilidades, por eso digo que es peligroso. Que con un script php de otro usuario en el servidor podrían leer y sacar tus contraseñas utilizando un script php que es lo más común aunque también lo pueden hacer con perl...

Php no necesita los permisos públicos para trabajar. Simplemente, no pongas 777 en ningún archivo. Con 750 suele ser suficiente y si es un archivo de contraseñas incluso menos.

Saludos

[Gambinoh]

Iniciado por vendoeninternet

El administrador no necesita tener permisos 777. El triple siete es para dar permisos a cualquiera de lectura, escritura y ejecución.

Php no puede leer archivos ni carpetas si no se tiene permisos. Si estás en un hosting y hablamos de haking, hay diferentes usuarios y 777 es para que, cualquier usuario del servidor pueda leer tus archivos, explorar lo que hay dentro y podrían sacar tus contraseñas si las tienen en archivos con permisos 777.

Los servidores suelen proteger el acceso a archivos y directorios entre usuarios pero no todos los paneles lo hacen así y las protecciones también pueden tener vulnerabilidades, por eso digo que es peligroso. Que con un script php de otro usuario en el servidor podrían leer y sacar tus contraseñas utilizando un script php que es lo más común aunque también lo pueden hacer con perl...

Php no necesita los permisos públicos para trabajar. Simplemente, no pongas 777 en ningún archivo. Con 750 suele ser suficiente y si es un archivo de contraseñas incluso menos.

Saludos

¿Te gustan los conejos? jaja, que coincidencia.

Aprovecho para darle las gracias a abimaelrc por su post.

[Triby]

cristian_cena, por lo general, las directivas de seguridad de los servidores no permiten que PHP tenga acceso a directorios que no corresponden al sitio en cuestion, pero, los ataques (la mayoria de las veces) ocurren cuando se tiene acceso al servidor directamente, como administrador (y, a veces, como super usuario "sudo") y por medio de la consola (SSH) se realiza la busqueda de directorios con permisos totales para inyectar codigos (uploaders, XSS, etc.).

Entonces, el riesgo mas grave no deriva de los permisos totales (0777) sino de que alguien pueda obtener acceso a esos directorios y, tienes razon, algunas configuraciones no permiten siquiera subir imagenes si los privilegios son inferiores (0750 o 0755) y requieren acceso total; lo unico que nos queda es esperar que las contraseñas admin y sudo no sean tan faciles de obtener y el servidor este bien protegido contra ataques de fuerza bruta.

pateketrueke, efectivamente, andabamos pensando casi en lo mismo.

Abimael, excelente aporte con esos enlaces, ya tenemos bastante informacion para analizar; gracias!!!

vendoeninternet, en la respuesta a las inquietudes de cristian_cena se aclara un poco mas el riesgo de esos permisos, que a veces se convierten en "un mal necesario".

[kryzpo23]

Amigos, y no bastara con usar la arquitectura MVC y patron DAOya sea manualmente con ayuda de algun framework?

[Flashback]

Todos los lenguajes tienen bug, pero mejor no meterese en esos asuntos.

[maycolalvarez]

Iniciado por kryzpo23

Amigos, y no bastara con usar la arquitectura MVC y patron DAOya sea manualmente con ayuda de algun framework?

el patrón MVC responde a la necesidad de separar la lógica del negocio de la vista y el controlador HTTP, no implica seguridad, el hecho de que los frameworks MVC implementen filtros XSS y CSRF no quiere decir que te protejan de todo

DAO a lo sumo podrá filtrar SQL Inyections, más nada

Iniciado por Flashback

Todos los lenguajes tienen bug, pero mejor no meterese en esos asuntos.

Imagina que tu negocio dependa de ello, ¿sabes las consecuencias de hacerse "la vista gorda" frente a este tipo de ataques?, además los lenguajes no son los unicos que tienen bug's, una mala configuración del servidor es peor y letal.

[Flashback]

Disculpa he entendido mal, creia que se refería a ser el que haga estos ataques.