¿Protegiendo la inyección de código a través de chattr en archivos php?

Question

¿Protegiendo la inyección de código a través de chattr en archivos php?

#1 de wireghoul (2 votos)
#2 de wireghoul (2 votos)

4

Recientemente, un sitio web que alojé (un sitio de wordpress) para un amigo fue hackeado y todas las páginas de php habían agregado código en la parte inferior en forma de echo base64_encode(...); . Por lo tanto, hubo anuncios no deseados en la misma página.

El servidor web es apache2 ejecutando suphp.

Me imagino que un chattr +i recursivo en todos los archivos php que no necesitan ser modificados / cargados por un sitio web protegería contra tal ataque. ¿Tengo derecho a creer esto y habría alguna buena razón para no hacer esto?

apache permissions php injection

pregunta BlakBat 13.01.2015 - 12:19

fuente

2 respuestas

Lea otras preguntas en las etiquetas apache permissions php injection

¿Es la contraseña + segundo factor más seguro que la autenticación de clave pública ahora? (SSH) ¿Debe LastPass usar el identificador público de YubiKey como clave secreta?

score 2 · Answer 1

La única razón por la que puedo pensar es que hace que la aplicación de las actualizaciones sea dolorosa. Sin embargo, si el servidor no está ejecutando suphp y aplica el permiso de archivo correcto, el usuario de apache no debería poder sobrescribir estos archivos. He visto ataques como este utilizando credenciales ftp robadas, así que asegúrate de cambiarlas también.

score 2 · Answer 2

A riesgo de secuestrar esto en una perorata sobre por qué no deberías ejecutar suphp ...

Dado que el usuario suphp es el propietario del archivo, el código malicioso que se ejecuta en el contexto de apache tiene el derecho de modificar todos los archivos que son propiedad de este usuario.

Ejecutar suphp es efectivamente lo mismo que un chmod 777 recursivo en su webroot si su sitio web tiene una vulnerabilidad. Si bien puede ofrecer beneficios mínimos en entornos de múltiples usuarios, nunca he encontrado que la compensación valga la pena.