security - una - propiedad intelectual pagina web

¿Cuáles son las mejores prácticas para proteger la sección de administración de un sitio web? (11)

Me gustaría saber qué personas consideran las mejores prácticas para proteger las secciones administrativas de sitios web, específicamente desde un punto de vista de autenticación / acceso.

Por supuesto, hay cosas obvias, como usar SSL y registrar todo el acceso, pero me pregunto dónde arriba de estos pasos básicos la gente considera que se debe establecer la barra.

Por ejemplo:

¿Simplemente confía en el mismo mecanismo de autenticación que usa para usuarios normales? Si no, ¿qué?
¿Estás ejecutando la sección de administración en el mismo ''dominio de aplicación''?
¿Qué pasos tomas para que la sección de administrador no sea descubierta? (o rechazas todo el asunto de la ''oscuridad'')

Hasta ahora, las sugerencias de los contestadores incluyen:

Introducir una pausa artificial en el servidor en cada comprobación de contraseña de administrador para evitar ataques de fuerza bruta [Developer Art]
Utilice páginas de inicio de sesión separadas para los usuarios y el administrador utilizando la misma tabla de base de datos (para detener el acceso de XSRF y de robo de sesión a las áreas de administración) [Thief Master]
Considere también agregar autenticación nativa del servidor web al área de administración (por ejemplo, a través de .htaccess) [Thief Master]
Considere bloquear la IP de los usuarios después de varios intentos fallidos de inicio de sesión de administrador [Thief Master]
Agregue captcha después de intentos fallidos de inicio de sesión de administrador [Thief Master]
Proporcione mecanismos igualmente sólidos (utilizando las técnicas anteriores) tanto para los usuarios como para los administradores (p. Ej., No trate especialmente a los administradores) [Lo''oris]
Considere la autenticación de segundo nivel (por ejemplo, certificados de clientes, tarjetas inteligentes, espacio de tarjetas, etc.) [JoeGeeky]
Solo permita el acceso desde dominios / IP de confianza, agregue cheques a la canalización HTTP básica (a través de, por ejemplo, HttpModules) si es posible. [JoeGeeky]
[ASP.NET] Bloquea IPrincipal y Principal (hazlos inmutables y no enumerables) [JoeGeeky]
Elevar los derechos de federación: por ejemplo, enviar correos electrónicos a otros administradores cuando se actualicen los derechos de cualquier administrador. [JoeGeeky]
Considere derechos detallados para los administradores, por ejemplo, en lugar de derechos basados en roles, defina derechos para acciones indiciduales por administrador [JoeGeeky]
Restrinja la creación de administradores; por ejemplo, los administradores no pueden cambiar ni crear otras cuentas de administrador. Utilice un cliente ''superadmin'' bloqueado para esto. [JoeGeeky]
Considere los certificados SSL del lado del cliente, o los teclados tipo RSA (tokens electrónicos) [Daniel Papasian]
Si usa cookies para Autenticación, use cookies separadas para las páginas de administrador y las páginas normales, por ejemplo, poniendo la sección de administrador en un dominio diferente. [Daniel Papasian]
Si es práctico, considere mantener el sitio de administración en una subred privada, fuera del internet público. [John Hartsock]
Vuelva a emitir los tickets de autenticación / sesión cuando se mueva entre contextos de administración / uso normal del sitio web [Richard JP Le Guen]

Agregue un campo de contraseña y una pregunta de seguridad que el administrador sepa, por ejemplo, cuál fue su primer nombre de novia, o aleatorice las preguntas cada vez que visite el panel de administración.

Quizás siempre podría poner la sección de administración en un directorio grande, por ejemplo

http://domain.com/sub/sub/sub/sub/sub/index.php

Pero eso no es realmente bueno, ja.

Quizás podría incluir una cadena de consulta en la página de inicio, como:

http://domain.com/index.php?display=true

Cuando lo haga, aparecerá el campo de nombre de usuario y contraseña.

Aquí hay algunas otras cosas a considerar:

Una opción a considerar, especialmente si administra las computadoras del administrador o son técnicamente competentes, es usar algo basado en certificados SSL para la autenticación del cliente. Los teclados RSA y otras cosas también se pueden usar para mayor seguridad.
Si está utilizando cookies, quizás para un token de autenticación / sesión, probablemente quiera asegurarse de que las cookies solo se envíen a las páginas de administración. Esto ayuda a mitigar los riesgos planteados en su sitio al robar cookies, ya sea mediante el compromiso de capa 1/2 o XSS. Esto se puede hacer fácilmente teniendo la porción de administración en un nombre de host o dominio diferente, así como establecer el indicador de seguridad con la cookie.
Restringir por IP también puede ser inteligente, y si tiene usuarios en Internet, puede hacerlo, si existe una VPN de confianza a la que puedan unirse.

Depende mucho del tipo de datos que desee proteger (requisitos legales y demás).

Muchas sugerencias se refieren a la autenticación. Creo que debería considerar usar la autenticación OpenId / Facebook como inicio de sesión. (Probablemente gastarán más recursos en seguridad de autenticación que usted)
Guarde los cambios y actualice los valores en la base de datos. De esta forma, puede deshacer los cambios del usuario X o entre la fecha X e Y.

La forma estricta es tener dos "fincas" diferentes completas, incluidas bases de datos, servidores y todo, y mover los datos de una granja a la otra. La mayoría de los sistemas modernos a gran escala usan este enfoque (Vignette, SharePoint, etc.). Normalmente se refiere a tener diferentes etapas "etapa de edición" -> "etapa de vista previa" -> "etapa de entrega". Este método le permite tratar el contenido / configuración de la misma manera que trata el código (dev-> qa-> prod).

Si eres menos paranoico, puedes tener una única base de datos, pero solo tienes tu sección de administrador disponible en los servidores de "edición". Quiero decir, solo tengo los scripts / archivos de edición colocados en el servidor de edición.

Naturalmente, la etapa de edición solo debería estar disponible en una intranet local y / o usando una VPN.

Esto puede parecer un poco exagerado y puede no ser la solución más fácil para todos los casos de uso, pero definitivamente es la forma más robusta de hacer las cosas.

Tenga en cuenta que cosas como "tener contraseñas de administrador potentes" son agradables, pero aún así deje su administrador abierto para todo tipo de ataques inteligentes.

No noté que alguien mencionara el almacenamiento / validación de la contraseña de administrador. Por favor, por favor no almacene el PW en texto plano, y preferiblemente ni siquiera algo que pueda revertirse: use algo así como un hash MD5 salted para que, al menos, si alguien recupera la "contraseña" almacenada, no tenga algo terriblemente útil, a menos que también tengan su esquema de sal.

Si el sitio web requiere un inicio de sesión tanto para las actividades habituales como para los administradores, por ejemplo, un foro, usaría inicios de sesión separados que usan la misma base de datos de usuarios. Esto garantiza que XSRF y el robo de sesión no permitirán al atacante acceder a las áreas administrativas.

Además, si la sección de administración está en un subdirectorio separado, protegerla con la autenticación del servidor web (.htaccess en Apache, por ejemplo) podría ser una buena idea, entonces alguien necesita tanto esa contraseña como la contraseña del usuario.

Obscurecer la ruta del administrador casi no genera ninguna ganancia de seguridad: si alguien conoce datos de inicio de sesión válidos, es probable que también pueda descubrir la ruta de la herramienta de administración, ya sea que la phishing o keylogged o la obtuvo a través de ingeniería social (que probablemente revelaría el camino, también).

Una protección de fuerza bruta como bloquear la IP del usuario después de 3 inicios de sesión fallidos o que requiera un CAPTCHA después de un inicio de sesión fallido (no para el primer inicio de sesión, ya que es extremadamente molesto para usuarios legítimos) también podría ser útil.

Si solo utiliza un solo inicio de sesión para los usuarios que tienen tanto privilegios de usuario normal como privilegios de administrador, vuelva a generar su identificador de sesión (ya sea en una cookie o un parámetro GET o lo que sea ...) cuando haya un cambio en el nivel de privilegio ... al menos.

Entonces, si me conecto, hago un montón de cosas normales sobre el usuario y luego visito una página de administrador, regenerar mi ID de sesión. Si luego me desplazo desde una página de administración a una página normal de usuario, vuelva a generar mi ID.

Tener una buena contraseña de administrador.

No es "123456" sino una secuencia de letras, dígitos y caracteres especiales lo suficientemente largos, digamos, 15-20 caracteres. Como "ksd83,''|4d#rrpp0%27&lq(go43$sd{3>" .

Agregue una pausa para cada comprobación de contraseña para evitar el ataque de fuerza bruta.

Todas estas son buenas respuestas ... Generalmente me gusta agregar un par de capas adicionales para mis secciones administrativas. Aunque utilicé algunas variaciones sobre un tema, generalmente incluyen uno de los siguientes:

Autenticación de segundo nivel : esto podría incluir certificados de clientes (Ej. X509 certs), tarjetas inteligentes, espacio de tarjetas, etc.
Restricciones de dominio / IP : en este caso, solo clientes provenientes de dominios de confianza / verificables; como subredes internas; están permitidos en el área de administración. Los administradores remotos a menudo pasan por puntos de entrada de VPN de confianza para que su sesión sea verificable y, a menudo, también esté protegida con claves RSA. Si está utilizando ASP.NET, puede realizar fácilmente estas comprobaciones en la canalización de HTTP a través de los módulos HTTP, lo que evitará que su aplicación reciba solicitudes alguna vez si no se cumplen los controles de seguridad.
Bloqueado IPrincipal y Autorización basada en Principal : La creación de Principios personalizados es una práctica común, aunque un error común es hacerlos enumerables y / o enumerables. Aunque no es solo un problema de administrador, es más importante ya que es aquí donde es probable que los usuarios tengan derechos elevados. Asegúrate de que sean inmutables y no enumerables. Además, asegúrese de que todas las evaluaciones de Autorización se realicen en base al Director.
Elevación de los derechos de federación : cuando una cuenta recibe una cantidad selecta de derechos, todos los administradores y el oficial de seguridad son notificados inmediatamente por correo electrónico. Esto asegura que si un atacante eleva los derechos lo sabemos de inmediato. Estos derechos generalmente giran en torno a derechos privilegiados, derechos para ver información protegida de privacidad y / o información financiera (por ejemplo, tarjetas de crédito).
Emitir derechos con moderación, incluso a los administradores : finalmente, y esto puede ser un poco más avanzado para algunas tiendas. Los derechos de autorización deben ser lo más discretos posible y deben rodear comportamientos funcionales reales. Los enfoques típicos de Seguridad basada en roles (RBS) tienden a tener una mentalidad grupal . Desde una perspectiva de seguridad, este no es el mejor patrón. En lugar de " Grupos " como " Administrador de usuarios ", intente desglosarlo aún más (por ejemplo, crear usuario, autorizar usuario, elevar / revocar derechos de acceso, etc. ). Esto puede tener un poco más de gastos generales en términos de administración, pero esto le da la flexibilidad de asignar únicamente derechos que realmente necesita el grupo de administración más grande. Si el acceso se ve comprometido, al menos pueden no obtener todos los derechos. Me gusta ajustar esto en los permisos de seguridad de acceso de código (CAS) admitidos por .NET y Java, pero eso está más allá del alcance de esta respuesta. Una cosa más ... en una aplicación, los administradores no pueden administrar cambiar otras cuentas de administrador o hacer que los usuarios sean administradores. Eso solo se puede hacer a través de un cliente bloqueado al que solo dos personas pueden acceder.

Usamos la Windows Authentication para el acceso de administrador. Esta es la forma más práctica de proteger las áreas administrativas mientras se mantiene la autenticación separada de la que se aplica a los usuarios finales generales. El administrador del sistema administra las credenciales de acceso del usuario administrador y aplica las políticas de contraseñas en la cuenta de usuario del dominio.

Rechazo la oscuridad
Usar dos sistemas de autenticación en lugar de uno es exagerar
La pausa artificial entre intentos debe hacerse también para los usuarios
El bloqueo de direcciones IP de intentos fallidos también debe hacerse para los usuarios
Las contraseñas seguras también deberían ser utilizadas por los usuarios
Si consideras que los captchas están bien, adivina qué, también puedes usarlos para los usuarios

Sí, después de escribirlo, me doy cuenta de que esta respuesta podría resumirse como "nada especial para el inicio de sesión de administrador, todas son características de seguridad que deberían usarse para cualquier inicio de sesión".