¿Es posible que un pirata informático descargue un archivo php sin ejecutarlo primero?

Para leer el código PHP, necesita una vulnerabilidad de recorrido del directorio . file_get_contents() u otras funciones del sistema de archivos que son explotables .

SQL Injection bajo mysql se puede usar para leer el código fuente. Por ejemplo:

select load_file("/var/www/index.php")

Para combatir esto, asegúrese de que file_privs esté deshabilitado para la cuenta de usuario MySQL utilizada por PHP. Si display_errors = on en su configuración de php, entonces un atacante puede obtener la ruta a su raíz web y usar la inyección de SQL o el cruce de directorios para leer el código fuente.

Usar FTP significa que el código fuente se transmite en texto sin formato. Use SFTP , y asegúrese de tener una contraseña segura, o mejor aún, configure una clave RSA.

Tenga cuidado con los archivos de copia de seguridad, a veces los editores crearán los archivos index.php~ o index.php.orig que pueden descubrirse utilizando navegación forzada .

Además de las vulnerabilidades del lado del servidor de todas las variedades, las contraseñas de FTP filtradas también son una preocupación importante. Existe una clase de infecciones del lado del cliente que recopilan las contraseñas FTP guardadas de programas como CuteFTP, FileZilla y DreamWeaver, que envían las credenciales de inicio de sesión a un atacante. Esto es muy común . Personalmente he visto cientos, tal vez miles de casos en los que esto ha sucedido. Y, por lo general, la persona que sin saberlo filtró las contraseñas es alguien que ya no necesita tenerlas de todos modos.

Y si te estás preguntando si un atacante realmente buscará en tus archivos de configuración en busca de contraseñas, la respuesta es inequívoca " sí ". Normalmente, es una de las primeras cosas que hará un atacante, a los pocos minutos de comprometer una nueva máquina.

Hay dos formas posibles de que un atacante pueda leer este archivo como texto, en lugar de ejecutarlo.

1. Si su servidor web está mal configurado, es posible que no se ejecute el php. Obviamente, necesita tener instalado y ejecutando php en el lado del servidor, así como tener un servidor web que admita esto. Si, por alguna razón, algo sale mal con la instalación de php, teóricamente es posible descargar el archivo php "raw". Esto, sin embargo, es poco probable.

2. Si existe una vulnerabilidad de LFI (inclusión de archivos locales) en este script (o en cualquier otra página dinámica del sitio), es posible mostrar un archivo que se encuentra en el servidor web. Consulte la página de Wikipedia en las vulnerabilidades de inclusión de archivos para ver cómo se vería.

Como nota aparte, vale la pena señalar que para usar los archivos PHP, deben ser accesibles desde un navegador. No hay forma de "ocultar" la página, a menos que haya otra secuencia de comandos que la ejecute en otro lugar.

Las contraseñas FTP filtradas son todas muy comunes y son una de las formas más comunes en que se eliminan los archivos de origen, el malware instalado en los sitios web de los desarrolladores es muy común y recientemente se dieron cuenta de los ataques de phishing lanzados contra ellos en un intento de piratas informáticos. ganar propiedad intelectual.

Una de las formas no tan comunes y de las que soy consciente solo es conocida por una cierta cantidad de personas, pero si desarrolla su sitio web en el servidor web de Linux donde se aloja el sitio web, es posible que tenga un problema. ya que algunos programas de edición almacenarán copias de seguridad de los archivos editados ocultos en la vista de los desarrolladores, por ejemplo,

  

Login.php ~

Se puede acceder a este archivo porque no lo ejecuta el servidor web ingresando

Esto revelaría el origen del archivo login.php de copia de seguridad para evitar esto. Deberá desarrollar su código de sitio y subirlo al servidor o asegurarse de que no haya archivos de copia de seguridad almacenados en un directorio que El público tiene acceso a.

Fuente: 2600 revista

¿Qué sucede si un atacante pudo acceder

  

databaseConnection.php ~

Entonces tu realmente arriba s *** creek

Como otros respondieron, esto no debería ser posible. Sin embargo, no puede decir que no hay absolutamente ninguna manera de que un atacante lea su código fuente PHP.

Por ejemplo, puede haber una vulnerabilidad que permita a un atacante ver archivos en el servidor web, incluido el código PHP en bruto. O un atacante puede descubrir su contraseña de FTP, que también se puede hacer de muchas maneras, incluyendo ataques de hombre en el medio y ingeniería social . Hay muchas posibilidades. A continuación, enumeré algunas vulnerabilidades que podrían permitirlo, pero la conclusión es que solo tener archivos PHP en la carpeta public_html no debería ser un riesgo por sí mismo.

Un archivo download.php que toma un parámetro GET / POST con el nombre del archivo a descargar, y no filtra las entradas del usuario correctamente, podría hacer posible descargar el código en bruto de un archivo en el sitio, mediante el acceso a una dirección como esta: enlace . Consulte esto .

Otro ejemplo: si hay una vulnerabilidad que permite a un atacante ejecutar el código en su servidor, como Inclusión de archivos locales / remotos , Vulnerabilidades de carga de archivos , y otras, también puede ser posible para él. para ejecutar código que le permita leer su código fuente PHP.

Mientras las cosas se configuren correctamente en el servidor, los archivos PHP deben registrarse como scripts y el servidor web debe hacer que PHP los interprete cuando se soliciten y solo mostrar los resultados de esa interpretación.

Dicho esto, cualquier número de problemas puede resultar en la exposición de archivos. Algunos de estos problemas también pueden exponer datos independientemente de si están en una carpeta pública o no. Siempre es importante asegurarse de que su servidor esté configurado correctamente para permitir solo las solicitudes que necesita. Esto reduce el área de superficie disponible para atacar y ayuda a evitar posibles problemas relacionados con errores que podrían resultar en una infracción.

¿Es una buena idea tener un archivo de configuración en una carpeta pública? Mientras el servidor esté configurado para no entregar el archivo sin procesarlo, probablemente no sea mucho menos seguro que cualquier otro punto en el sistema. Existe una pequeña posibilidad de que se utilice un error en el servidor web para evitar la ejecución por parte del motor de secuencias de comandos, pero los ataques más probables son ataques que provendrían de alguna otra dirección, como SQL, FTP o algún código de inyección, donde estar en una carpeta privada estaría igualmente expuesto.

Dicho esto, la otra cara de la pregunta es por qué no se coloca en otro lugar. La opción más segura sería colocar en un lugar donde solo el usuario que ejecute la instancia de PHP del sitio web pueda acceder y denegar el acceso al archivo desde cualquier otro mecanismo (como el usuario de FTP o cualquier otro usuario que se use públicamente). Sin embargo, es bastante difícil de configurar y administrar, por lo que se debe tomar una decisión si la seguridad adicional es necesaria o no.

Es un lanzamiento lo que es mejor. Es mucho trabajo adicional administrar todas las rutas, permisos y usuarios para mantener ese nivel de seguridad. Por otro lado, siempre que el servidor se mantenga parcheado y configurado correctamente, solo debe ser vulnerable a los ataques de día cero que atacan a un nivel muy bajo y pueden ser seguros contra casi todos los ataques comunes, incluso con el archivo de configuración en la carpeta pública.