Cómo asegurar un servidor backend

Si entiendo correctamente, tu CMS sirve a dos tipos de usuarios, que supuestamente tienen diferentes privilegios:

1. Usuarios que no pertenecen a la aplicación (por ejemplo, usuarios que acceden al CMS directamente desde su navegador). Acceso de lectura y escritura.
2. Usuarios de aplicaciones móviles. Sólo acceso de lectura.

De acuerdo con el diseño de su sistema, es posible que un usuario de la aplicación descubra la combinación de usuario / contraseña que usa su aplicación (porque está codificada en la aplicación) para iniciar sesión en el CMS. Entonces, la cosa única que evita que el usuario de la aplicación manipule los datos del CMS es el hecho de que él / ella está usando la aplicación.

Su preocupación inmediata debe ser la separación de roles en su CMS. Si está utilizando sesiones en JSP, esto debería ser fácil (tal vez agregue otra columna en su tabla de usuarios que represente el rol del usuario y tenga un control de rol en cada .jsp).

Con respecto al punto de inicio de sesión de tu CMS, ocultarlo puede engañar a algunos robots, pero esto no es suficiente. Podría usar iptables para detener los ataques de fuerza bruta o podría implementar un demonio de algún tipo que supervise los registros de Tomcat y prohíba los comportamientos sospechosos (un ejemplo mío utilizado para prohibir los bruteforcers SSH: enlace ).

Además, siempre use HTTPS cuando trate con información confidencial, como las credenciales de autenticación.

Primero, use SSL (https). Esto evitará que un intruso escuche las credenciales de los usuarios.

ver ¿Cuáles son los pros y los contras de SSL (https) en todo el sitio? , Seguridad adicional HSTS a través de HTTPS , Orientación para implementadores de sitios que solo utilizan HTTPS (lado del servidor) .

Si está incrustando una contraseña en el código de la aplicación móvil que el usuario descarga, es un poco extraño y no parece una buena práctica. Eso equivale a poner esa contraseña en su sitio web para que todos la vean: cualquiera puede descargar la aplicación y mirar los bytes para encontrar la contraseña. Nada de lo almacenado en un programa binario debe ser tratado como secreto.

Si el usuario ingresa su contraseña en la aplicación, está bien almacenarla en el almacenamiento privado de la aplicación y reutilizarla en cada conexión. O bien, está bien generar una clave privada en el primer lanzamiento de la aplicación, enviar de forma segura el certificado de cliente correspondiente al servidor (a través de una conexión SSL autenticada por la contraseña del usuario) y luego usar SSL con certificados de cliente para autenticar el móvil cliente al servidor en todas las conexiones posteriores (por lo que el usuario no necesita escribir su contraseña nuevamente).

Si el contenido en el CMS está destinado a que el público lo vea, debe eliminar la contraseña para ver el contenido, ya que es un poco inútil. Si la aplicación móvil está disponible para el público, y cualquiera que tenga la aplicación móvil puede leer el contenido en el CMS, ha decidido que el contenido del CMS está destinado a que el público lo vea.

Puede generar una "clave de API" para cada usuario que usarán para recuperar datos, de modo que si se la roban / comprometen, no se puede usar para acceder al CMS y también se puede restablecer desde allí.

Además, debe responder con un error (por ejemplo, 401 no autorizado o 403 prohibido) a los inicios de sesión no válidos en lugar de redirigirlos al punto final de inicio de sesión.

Si desea agregar una capa de seguridad opcional al CMS, le sugiero que agregue alguna autenticación multifactorial (por ejemplo, Autentificador de Google ).

Aparte de estos, debe proteger sus servidores contra los ataques de fuerza bruta (bloquear una dirección después de una solicitud repetida o fallida, o tal vez agregar un CAPTCHA al formulario de inicio de sesión), varias inyecciones (verifique el código cuidadosamente, especialmente las consultas SQL ) y sniffing (cifrar el tráfico entre la aplicación móvil y el servicio web, y el uso de SSL en el servidor CMS). Y, obviamente, mantenga las bibliotecas y el software de terceros al día.

El entorno siempre importa, porque las capas de seguridad suben del nivel físico al de la aplicación.

Java tiene su propia seguridad, por lo que es diferente, por ejemplo, PHP, Python o Ruby. Java está compilando el código fuente y su lenguaje estático. Los modificadores de acceso OO tienen sentido al separar los derechos de partes del código, y se considera seguro ya que no se puede hacer la inyección de código en Java como lo hace con PHP, la mayoría de las veces.

Básicamente, lo que debe hacer para dicha aplicación:

• Primero, debe dividir sus aplicaciones en diferentes contextos aislados utilizando Tomcat. Con PHP o IIS haces esto con diferentes usuarios del sistema. En Tomcat, acaba de configurar la aplicación por separado. También puede aislarlos a través de la virtualización, por ejemplo, dos tomcats y dos ips.
• Cada aplicación debe usar un inicio de sesión diferente para la base de datos, y solo tiene los permisos necesarios, por ejemplo, el frontend y el backend pueden tener diferentes niveles, por lo que la inyección SQL en el frontend no interrumpirá el sistema completo. Si todos ellos usan el mismo DB. Puedes usar Vistas para hacerlo.
• Se asegura de usar HTTPS para cada inicio de sesión y para la sesión de usuario backend
• Puedes instalar Apache con ModSecurity delante de él con mod_proxy
• Asegúrese de que su sesión sea segura, por ejemplo. es un token criptográficamente seguro

Y sobre todo:

• Los usuarios de frontend y backend deben mantenerse en tablas separadas y su acceso debe estar limitado a frontend o backend. Por lo tanto, cuando se rompe el frotend, no es posible modificar la base de datos, excepto unas pocas columnas inocentes.
• Las contraseñas deben estar marcadas con sal como mínimo.
• Recuperación de contraseña razonable.

También:

• Intente asegurar la máquina con SELinux
• Cree un buen cortafuegos IPTABLES resistente: esto y más arriba evitan que se enrute la máquina

También, si tienes mucha audiencia:

• Aísle el inicio de sesión, el registro y la recuperación de contraseñas (y los informes) en otro tomcat con acceso exclusivo de escritura a las tablas de los usuarios, pero esto podría ser una aplicación separada de Tomcat sin problemas. Solo asegúrese de que cada contexto de ejecución en Tomcat no pueda leer los archivos de configuración / contraseñas de la base de datos entre sí.

Esto es lo que he decidido como resultado de esta discusión.

1. Todo está por HTTPS, por supuesto.
2. Separaré los roles para los usuarios de CMS y aplicaciones móviles, de modo que el inicio de sesión / contraseña de la aplicación sea inútil en el CMS.
3. Fortaleceré el servicio de inicio de sesión implementando medidas contra los ataques de fuerza bruta / diccionario.
4. Parece que no hay "mejores prácticas" en cuanto a cómo evitar que demasiados atacantes toquen la puerta de inicio de sesión del CMS, ya sea dividiendo el CMS y WS en diferentes servidores / dominios / ... o simplemente "ocultar" "la URL de inicio de sesión, o ambas, o lo que sea, realmente no importa mucho.