¿Es una contraseña de texto sin formato en un script CGI un agujero de seguridad?

Question

He leído que las cosas pueden ir mal con su servidor web, lo que puede llevar a la visualización de scripts PHP como archivos de texto plano en un navegador web; en consecuencia, he movido la mayoría de mis scripts PHP a un directorio fuera de la raíz web. Ahora me he estado preguntando si lo mismo podría pasar con los scripts CGI en mi cgi-bin.

Mi principal preocupación es una secuencia de comandos que contiene un nombre de usuario y una contraseña para mi base de datos MySQL. Si se trata de un posible agujero de seguridad (al menos en lo que respecta al contenido de la base de datos), ¿hay alguna manera de colocar datos confidenciales en una ubicación diferente y obtenerlos desde allí (como guardarlos en un archivo en un directorio diferente y leerlos)? desde ese archivo, por ejemplo)? Mis scripts están escritos en Perl por cierto.

Answer 1

He leído que las cosas pueden ir mal con su servidor web, lo que puede llevar a la visualización de scripts PHP como archivos de texto plano en un navegador web; en consecuencia, he movido la mayoría de mis scripts PHP a un directorio fuera de la raíz web. Ahora me he estado preguntando si lo mismo podría pasar con los scripts CGI en mi cgi-bin.

Sí. Si algo sale mal y hace que se sirvan los programas en lugar de ejecutarse, se expondrá todo su contenido. Es exactamente el mismo problema que con PHP (excepto que, dada la forma en que los directorios cgi-bin usualmente están configurados (es decir, alias a un directorio fuera de raíz web), es un poco más difícil que ocurran los problemas).

Mi principal preocupación es una secuencia de comandos que contiene un nombre de usuario y una contraseña para mi base de datos MySQL. Si se trata de un posible agujero de seguridad (al menos en lo que respecta al contenido de la base de datos), ¿hay alguna manera de colocar datos confidenciales en una ubicación diferente y obtenerlos desde allí (como guardarlos en un archivo en un directorio diferente y leerlos)? desde ese archivo, por ejemplo)?

Sí. Exactamente eso, solo asegúrese de que el directorio esté fuera de la raíz web.

Para mayor seguridad, asegúrese de que la base de datos solo acepte las credenciales para las conexiones del conjunto mínimo de hosts que necesitan acceder a ella. p.ej. si la base de datos está en el mismo servidor que el servidor web, solo deje que las credenciales funcionen para localhost. Causar que la base de datos solo escuche en la interfaz de red localhost también sería una buena idea en ese caso.

Mis scripts están escritos en Perl btw.

Me gustaría utilizar uno de los módulos Config::* para esto.

Answer 2

Definitivamente es un problema de seguridad. Debe almacenar la contraseña encriptada en un archivo separado y asegurarse de que solo su aplicación tenga acceso a ella.

Answer 3

Si usa el directorio configurado como cgi-bin, no hay forma de que se muestre el archivo excepto el error con la configuración de Apache. Si usa programas Perl fuera de los directorios de cgi-bin, pero dentro de la raíz del sitio, puede suceder.

Además, puede configurar DB para que acepte conexiones solo desde el socket local, por lo que conocer la contraseña del DB sería inútil.

Answer 4

Definitivamente no es una buena idea codificar una contraseña en un script si puede evitarla. Afortunadamente, tanto Postgres como MySQL soportan cargar credenciales de DB desde un archivo. Para Postgres utilizas ~/.pgpass y para MySQL creo que es ~/.my.cnf. En cualquier caso, debe ajustar los permisos para que solo el usuario que ejecuta el script tenga permiso para leer el archivo. La ventaja de este enfoque es que no tiene que escribir el código para leer el archivo; la biblioteca del cliente de DB lo hace automáticamente.

Answer 5

Una de las preocupaciones que vale la pena mencionar es específica del alojamiento compartido.

Si está en un host compartido con otros usuarios, puede ser imposible ocultar la contraseña de ellos. Esto depende de los detalles de configuración para el sistema operativo y el servidor web.

Por ejemplo, es común tener una configuración de Apache en Linux en el que la única manera para que un usuario que ofrece un sitio web para que los archivos leer o escribir al servidor web de usuario es hacerlos lectura/escritura a todos usuarios .

Puede confiar en que ninguno de estos usuarios abusará de esto, pero si uno de estos sitios web tiene una vulnerabilidad que permite a los intrusos ver el sistema de archivos completo, el intruso puede aprovecharlo en todos los demás sitios web.

Existen contramedidas contra esto, pero complican las cosas para los usuarios, por lo que muchos proveedores de servicios de Internet no las implementan.

Answer 6

si ya recibió mejores respuestas de lo que puedo dar, sino como una nota:

Es muy mala forma de almacenar las contraseñas en texto plano, y punto.

Del mismo modo, es muy malo sobrescribir o eliminar archivos sin pedir permiso. Si lo hace, morderá usted o su cliente en el trasero con el tiempo.