¿Riesgo de seguridad al almacenar información de inicio de sesión SQL en código PHP?

Question

Lector por primera vez, primer póster (woo!)

Así que he estado implementando mis scripts de inicio de sesión para un sitio web informal. No es probable que se vea comprometido, pero para estar seguros, me gustaría preguntar si existe un riesgo de seguridad al tener mi inicio de sesión de la base de datos MySQL en texto plano en el código php.

Por lo que yo sé, el código en sí mismo es analizado por Apache, por lo que el usuario final no lo ve (solo el resultado), lo que significa que debería ser seguro mantenerlo ... pero me gustaría como una segunda opinión

Resumen: Acceso a la base de datos a través de mysql_connect, mysql_select_db, mysql_query. La información de inicio de sesión está almacenada en variables locales definidas en cada iteración del script, y (creo) descartada una vez que finaliza el script.

¿Vulnerabilidad de seguridad?

Answer 1

También podría considerar mover la combinación de nombre de usuario/contraseña a un archivo de configuración separado que viva fuera de la raíz web. Asegúrese de que ese lugar no sea accesible directamente desde el lado del servidor web.

De esta forma, si por alguna razón el servidor web decide no ejecutar más archivos PHP, no perderá la información de la cuenta en el servidor de la base de datos.

Como una ventaja adicional, si utiliza cualquier cosa que haga una copia del archivo .php (editores, SVN o lo que sea) en la raíz web, no se arriesga a que nadie se mueva por la ejecución de .php.

Answer 2

Cualquier persona que pueda iniciar sesión con privilegios de administrador en ese servidor web (o posiblemente algunos más pequeños también) podrá ver su contraseña, pero entonces, es prácticamente imposible defenderse contra el superusuario (donde sea que pueda) mantén tu contraseña, podrían piratear y encontrarla). Además de este riesgo, deberías estar a salvo.

Editar: las copias de seguridad del servidor también se pueden usar (si no están encriptadas, o por alguien que las puede descifrar) para recuperar su contraseña si está libre en su script .php. Este posible ataque podría quizás mitigarse (con grandes inconvenientes/costos) manteniendo la contraseña en un lugar diferente y seguro, y solo enviándola (de forma segura) en circunstancias altamente restrictivas. ¿Es este el tipo de ataque que temes?

Answer 3

Es un procedimiento muy estándar para las aplicaciones web que hablan con una base de datos.

Recomiendo quitar permisos de lectura del archivo para usuarios que no sean el servidor web y usted mismo: si tiene otros usuarios en su caja que puedan espiar el archivo, podrán acceder a su servidor mysql.

Además, debe ajustar el permiso ejecutable en el directorio superior ya que evitará que los usuarios no autorizados incluso lo ingresen.

Endurezca el host permitido de su usuario mysql, de modo que solo puedan conectarse a los cuadros que necesita.

Por supuesto, si su caja está en peligro y un atacante gana acceso de root, hay poco que lo protegerá.

Answer 4

Puede agregar un nivel de seguridad adicional colocando todos sus archivos php (excepto index.php por supuesto) en un directorio separado y protegerlos con un archivo .htaccess. Esto cubre casos en los que el analizador php no se invoca y apache devuelve los archivos en texto claro. Una cosa más que podría ser útil: <?php defined('some_id_here') or die(); ?>. Puede poner esto en la parte superior de cada archivo php excepto el índice.php (donde define some_id_here) por lo que no hay acceso directo a sus archivos de base de datos.

Answer 5

No tener la mayor parte del código dentro de la webroot, donde es posible, aunque poco probable, es solo la primera línea de defensa que se puede tomar.

Su base de datos también debe ser segura incluso si el usuario y la contraseña de la base de datos se publicaron, por el simple hecho de permitir solo que un pequeño número de máquinas fuente se conecte a la base de datos.

defensa en profundidad

<?php // simplest /index.php, as the only .PHP file in the public-accessible webroot 
require '../bootstrap.php'; 

Answer 6

No sé cómo se conecta a su base de datos MySQL, pero si se utiliza PDO existe la posibilidad de que el constructor de PDO se produce una excepción. ¡Si no detecta esta excepción, Zend Engine mostrará una traza inversa por defecto y revelará los detalles de su conexión!

Es normal almacenar los datos de conexión dentro de un archivo/variable php o, en ese caso, usar PDO, en el DSN (Nombre de la fuente de datos). Incluso te sugiero que lo pongas dentro de un archivo php, porque se analizará y no se enviará directamente a la web ...

Un paso más hacia la seguridad es poner los datos de inicio de sesión fuera de www-root o proteger con un archivo .htaccess (esto haría imposible acceder al archivo a través del servidor web).

Sin embargo, en mi servidor es imposible conectar no desde localhost. Así que no me importa si alguien lee mis datos de inicio de sesión (no es el caso, por supuesto).