¿Es una forma segura de declarar parámetros de DB en htaccess en lugar de en un archivo PHP?

Este es un enfoque razonable. El beneficio de este enfoque es que evita almacenar su contraseña en el código fuente. Esto es bueno: no debe incluir contraseñas de código en su código fuente .

(Por supuesto, con esta sugerencia, la contraseña de la base de datos no se almacena en el archivo .htaccess ; en cambio, se almacena en un archivo de configuración separado. Pero la diferencia no tiene importancia).

Importante: asegúrese de que sql.cnf no esté almacenado dentro de su raíz web. Si está almacenado en la raíz de su web, tal vez cualquiera que conozca el camino correcto podrá solicitarlo simplemente enviando una solicitud GET.

• Existe un riesgo adicional con el almacenamiento de contraseñas en un archivo sql.cnf dentro de su webroot, que es un poco oscuro pero se puede evitar fácilmente colocando el archivo fuera de su raíz web. Considere: si está editando sql.cnf usando un editor de texto, y su conexión se cae mientras lo está editando, su editor guardará automáticamente una copia del archivo sql.cnf en algún archivo de copia de seguridad: por ejemplo, sql.cnf~ (en el mismo directorio). Ahora el archivo de copia de seguridad tiene una extensión diferente, por lo que si alguien intenta recuperar ese archivo, el servidor Apache estará encantado de entregar una copia del archivo en texto sin formato, revelando la contraseña de la base de datos. Consulte el 1% de los sitios potenciados por CMS exponen sus contraseñas de la base de datos para obtener más información.

Para más información sobre el principio general:

• ¿Debe un sitio web de código cerrado mantener una clave secreta en su fuente?

• dónde almacenar una clave para el cifrado

• ¿Cómo manejan los artefactos de código abierto los proyectos de código abierto?

La recomendación se basa en el hecho de que los archivos PHP serán legibles para todo el mundo, pero los archivos .htaccess / httpd.conf no lo harán. El autor señala acertadamente que el uso del cifrado para ocultar estos valores no ayuda, ya que eso significa que la clave de cifrado debe ser accesible para el código PHP. Pero almacenar los valores en el entorno solo evita algunos problemas que también pueden evitarse por otros medios. Los valores en un archivo httpd.conf serán legibles por cualquier código PHP ejecutado en el servidor. Moverlos a una definición de vhost reduce la visibilidad. Puede mantenerlos como código PHP dentro de la raíz del documento simplemente anteponiendo el nombre del archivo con '.ht'.

Ciertamente, es una buena práctica mantener los tokens independientemente del grueso del código. Desde

• tendrán una vida útil diferente a la del código (es decir, es posible que deban cambiarse independientemente del código y viceversa)
• no debe exponerse a través de las funciones de administración de código, como el sistema de control de versiones
• debe variar según el lugar en el que se implementa el código (es decir, diferentes tokens para test / stage / live)

Sin embargo, usar la configuración del servidor web es solo una forma de lograrlo: hay otros enfoques válidos.

Independientemente de la ruta que tome, la seguridad de la solución provendrá de todos los aspectos: permisos / accesibilidad del archivo, restricciones en la conexión a la base de datos, controles de acceso en la base de datos.     

Hay algunas advertencias con esto, primero uno esperaría que la ruta: /home/ilia/sql.cnf no se encuentre dentro del webroot de su sitio web, o un atacante podría simplemente visitar la url enlace para ver las credenciales de su base de datos.

Además, uno esperaría que su sitio web no incluyera varios errores de divulgación de información o una página de phpinfo ya que phpinfo volcará la matriz $ _SERVER y, por lo tanto, divulgará sus credenciales de base de datos a cualquier visitante de esta página.

Además, la suposición de que sería más difícil para un atacante obtener la información si se almacena en un archivo PHP en comparación con las variables de entorno es basura. Su ejemplo establece las variables de entorno para cada solicitud de página. Eso significa que un ataque transversal a un directorio que puede no tener permisos para leer su archivo sql.conf probablemente todavía tenga permiso para leer / prof / self / environ y obtener las credenciales de esa manera.

Me aseguraría de que su servidor de base de datos esté vinculado a la interfaz de bucle de retorno, que sus credenciales de base de datos tengan los privilegios más bajos posibles y que su aplicación web y el software del servidor estén parcheados de manera oportuna y solo almacenen las credenciales en el archivo php.