Problema de seguridad con pg_hba.conf

Problema de seguridad con pg_hba.conf

Tengo un script PHP en mi servidor que necesita acceso a un usuario de base de datos para funcionar correctamente. La persona que programó ese script PHP dijo que agregara lo siguiente a pg_hba.conf:

host all all 127.0.0.1/32 trust

¿Puede esto causarme algún problema relacionado con la seguridad? Según tengo entendido, lo que hace esa línea es permitir que los scripts alojados localmente se conecten a pgsql sin contraseña. Es esto correcto ?

¿La presencia de esa línea puede provocar que se establezcan conexiones remotas a mi base de datos sin la contraseña de la base de datos?

Respuesta1

, esa es una configuración queEn general, debes evitarlo fuera de casos especiales muy limitados.:

confianza

Permitir la conexión incondicionalmente. Este método permite que cualquier persona que pueda conectarse al servidor de base de datos PostgreSQL inicie sesión como cualquier usuario de PostgreSQL que desee, sin necesidad de una contraseña ni ninguna otra autenticación.

[..]

La autenticación de confianza solo es adecuada para conexiones TCP/IP si confía en todos los usuarios de cada máquina a la que se le permite conectarse al servidor mediante las líneas pg_hba.conf que especifican la confianza. Rara vez es razonable utilizar la confianza para conexiones TCP/IP que no sean las de localhost (127.0.0.1).

Tenga en cuenta que permitir conexiones sin proporcionar ninguna contraseña ya puede ser el caso, ya que muchas distribuciones autentifican de forma predeterminada las conexiones a través de sockets Unix como usuario que se conecta. Normalmente, esto daría como resultado que el www-datausuario del sistema pueda utilizar el www-datausuario de Postgres sin una contraseña. Verifique el resto de su configuración de autenticación para ver si este es el caso.

Recomendación:Proporcione contraseña o autenticación de certificado, hágalonoContinuar con la trustopción.

Tenga en cuenta también que limitar algo únicamente a direcciones de bucle invertido generalmente no es una garantía suficientemente segura contra el acceso externo. Existe una larga historia de acceso a servicios vinculados a loopback a través de otro software que actúa como un proxy no deseado.

información relacionada