Asegurar la aplicación web de código abierto

Su servidor web puede no permitir el acceso a archivos y carpetas. Podría hacer esta configuración en un archivo .htaccess que contenga su hash de contraseña. El almacenamiento de contraseñas de texto simple debe evitarse a toda costa.

Asegúrese de que la autenticación se realiza a través de HTTPS y HTTPS se utiliza durante la vida de la sesión. Si no sigue esta pauta, estará violando OWASP a9 .

¿Crees que este enfoque es seguro?

Por sí solo - NO ! Sin agregar capas adicionales de seguridad por encima de lo que describió, su servidor estaría expuesto a ataques de fuerza bruta que intentan coincidir con la contraseña requerida. No importa cuán larga y aleatoria sea su contraseña, dado el tiempo suficiente para descifrar su esquema de protección . Y la forma en que lo describe, tampoco parece que tomaría mucho tiempo. Sin embargo, podría asegurar su aplicación web un poco más, incluso si utiliza un simple bloqueo de una clave de seguridad que usted describe. Además de lo que Rook ya sugirió, agregaría que también podría implementar estas medidas de seguridad con relativa facilidad:

• asegúrese de mover las secciones de administración de su aplicación web a una ubicación no estándar y nunca publique (enlace a) su ubicación en partes de acceso público de su aplicación web. Sin embargo, no hay seguridad real a través de la oscuridad, con muchos subprocesos en IT.sec que describen por qué no.
• bloquee el acceso a las secciones de administración en la configuración de su servidor web solo a un rango de IP limitado (con la máscara lo más alta posible), o incluso mejor solo a unas pocas direcciones IP específicas desde las cuales desea acceder a las secciones de administración Mantenga esta configuración siempre actualizada y lo más limitada posible en todo momento para la mejor seguridad.
• cualquier secuencia de comandos activa a la que se pueda acceder a través de la sección de administración también se debe mover a una ubicación no estándar. Por ejemplo, digamos que estás usando extensiones TinyMCE en tu CMS. Estos pueden ser explotados de varias maneras y es mejor que mueva los scripts del lado del servidor a ubicaciones no estándar. Realice cambios de código donde sea necesario para admitir nuevas ubicaciones.
• Solo permita explícitamente el acceso a estas secciones a los agentes de usuario que incluso son compatibles con su panel de administración (y similares). Puedes configurarlo en tu servidor web. Puede bloquear una gran cantidad de escáneres de vulnerabilidad web genéricos por ahí, ya que la mayoría de los niños de secuencias de comandos ni siquiera pueden ser arseados para cambiar las cadenas de usuario-agente a algo menos obvio.
• Registre cualquier acceso a estas secciones y deniegue dinámicamente el acceso a las direcciones IP que parecen buscar ubicaciones de panel de administración estándar. Si la automatización no es posible, verifique estos registros separados con frecuencia y bloquee manualmente esas direcciones IP en la configuración de su servidor web.
• Solo comparta información sobre cómo acceder a estas secciones de administración con aquellas que absolutamente necesitan conocerlas y cree diferentes conjuntos de reglas descritas anteriormente para cada una de las personas que necesitan acceder a ella. Si eso significa más de una sola contraseña, verifique con la dirección IP a la que están accediendo, que así sea.
• Asegúrese de que estas contraseñas utilizadas no puedan recuperarse solo con la inspección del código (es decir, nunca las almacene directamente en su código, ofuscado o no). También debería ser obvio no almacenarlos en ubicaciones a las que se pueda acceder a través de su servidor web.

Todas estas reglas deben ser fáciles de implementar y agregarán una capa adicional de seguridad además de una contraseña simple que planea usar para acceder a estas ubicaciones seguras. También le sugiero que utilice una combinación de nombre de usuario y contraseña para agregar complejidad (y, si es posible, algún tipo de CAPTCHA) que hará que sus secciones de administrador sean un poco menos propensas a los ataques de fuerza bruta. Los demás responderán a su pregunta con más sugerencias, estoy seguro, pero estas son las que se me ocurren sin pensar que no tardarían mucho en implementarse. Espero eso ayude. ¡Salud!

Esto está perfectamente bien siempre y cuando tengas una contraseña bastante larga. La única forma de que alguien pueda obtener su contraseña es si comprometen el proceso del servidor, pero si comprometen el proceso del servidor, no necesitan su contraseña porque probablemente solo pueden modificar su comportamiento / eliminar la verificación de la contraseña, etc.

Es posible que desee hacer un hash de la contraseña, pero no necesita molestarse si no reutiliza la contraseña en cualquier lugar.

Note que la mayoría de las sugerencias en las otras respuestas son principalmente FUD / OCD :) Por ejemplo, el filtrado de IP es una pérdida de tiempo, y el registro no es tan importante realmente si tiene una contraseña segura y no tiene todos los tipos de agujeros en su sitio.

Lo único que diría que hiciera si todavía no lo ha hecho es asegurarse de que no tenga ningún problema de inyección (XSS / SQLi / etc) o CSRF / clickjacking. Es posible que desee utilizar HTTPS si cree que es posible que alguien (gobierno, personas en su red inalámbrica, etc.) intercepte / interfiera con su tráfico.

Puede usar una solución 2FA de código abierto (como la nuestra) y mod-ldap en apache. Hice una prueba de concepto para un escáner automatizado de código abierto. Consulte aquí: enlace .