tomando información del formulario web y canalizando hacia el mensaje de contraseña de bash

0

He querido crear una aplicación web simple que me permita ver ciertos archivos de texto que he cifrado con GnuPG que residen en mi servidor web a través de cualquier navegador de forma remota.

Me he dado cuenta de que la mejor manera de hacerlo es configurar un sistema de inicio de sesión con usuario y contraseña (aparte de eso para descifrar mi clave privada).

Una vez que haya iniciado sesión, el servidor intentará descifrar el archivo cifrado y solicitar mi contraseña de clave privada. Entonces puedo pedir al navegador que pase la clave privada. Luego enviaría el archivo descifrado de nuevo en texto sin formato (sobre TLS)

Aunque solo estaría usando esta configuración, estoy pensando que la única forma de enviar mi contraseña al programa GnuPG es que mi servidor tome la cadena y la use en la solicitud de contraseña de GnuPG. ¿Hay alguna implicación de seguridad que deba tener en cuenta al canalizar la entrada en un formulario web en bash cuando gpg solicita una contraseña (o cualquier problema de seguridad con este diseño completo)?

La sesión completa se cifraría con TLS. Probablemente también deshabilitaría el gpg-agent, no que hubiera usuarios concurrentes en mi servidor privado. El objetivo final es que yo pueda acceder a mis contraseñas desde el pase ZX2C4 desde cualquier navegador.

    
pregunta rrego 10.02.2016 - 00:53
fuente

1 respuesta

1

En primer lugar, hay muchas posibilidades de que, independientemente de lo que estés intentando construir, alguien más lo haya hecho. Eso no significa que lo crearon correcto , pero probablemente existe una solución.

En segundo lugar, independientemente del marco web que vayas a usar, existe una buena posibilidad de que exista una biblioteca GPG para él, por lo que puedes invocar las funciones gpg directamente en el código en lugar de desechar la línea de comandos.

En tercer lugar, la línea de comando gpg tiene una opción --batch que está diseñada específicamente para uso no interactivo cuando tienes un programa que ejecuta el ejecutable en lugar de un usuario en una terminal.

Y finalmente, el peligro principal al pasar la entrada del usuario a los programas de la línea de comandos es la interpretación del shell. Si ejecuta la aplicación directamente (por ejemplo, utilizando execve o execle o cualquiera de las syscalls exec) donde las opciones se pasan como una lista y no como una única cadena delimitada por espacios, entonces no se necesita un tratamiento especial de escape de parámetros, ya que los parámetros son No siendo leido e interpretado por un shell. Como regla general, la interpretación de shell es mala a menos que sepa lo contrario y debe evitarse.

    
respondido por el tylerl 10.02.2016 - 06:55
fuente

Lea otras preguntas en las etiquetas