El usuario no puede navegar a la página web a través de la IU debido a los permisos, pero puede navegar a la página pegando la URL. ¿Cómo me protejo contra esto?

  

¿Debo verificar al usuario para cada página?

Absolutamente. No solo todas las páginas, sino todas las solicitudes a un recurso privilegiado, por ejemplo, solicitudes POST para actualizar datos, eliminar, ver, etc. No solo se trata de ver las páginas, se trata de controlar quién puede hacer qué en su sistema.

Parece que su sistema completo de autenticación y permisos está roto en su implementación actual. Los pasos para remediar esto son demasiado amplios para esta respuesta. Valdría la pena realizar una búsqueda general de este foro y de la red más amplia para encontrar soluciones adecuadas para su marco (JSP, ASP.Net, PHP, etc.). La mayoría de los marcos tienen una funcionalidad lista para usar para resolver este problema.

Un buen comienzo sería esta guía de alto nivel de OWASP: Seguridad operacional: Interfaces administrativas .

La respuesta rápida es sí, ya que se reunieron. Pero no tiene por qué ser el gran trabajo que estás pensando. (Todo lo relacionado con la seguridad puede ser grande, pero esto es solo una parte). Tienes problemas mucho más serios que eso.

Por qué importa

TODO lo que crees será golpeado con intentos de romperlo. Alguien será curioso. Alguien hará algo que nunca esperó y que desafía su pensamiento. Alguien será curioso, malicioso o entrometido.

También debe dar por sentado que su software / aplicación web será probado por las herramientas automatizadas . Los servidores con un portal en línea (de casi cualquier tipo) son descubiertos por los piratas informáticos a los diez minutos de la primera conexión en línea, y comienzan a sondearse por cualquiera de miles de posibles fallas o descuidos de seguridad. Esto significa que sondean qué se está ejecutando exactamente "detrás de la escena", así como para cualquier error detectable que pueda ser explotado (en validación de datos, validación de secuencias de comandos cruzadas, inyección SQL o binaria, pirateo de JavaScript, el back-end en sí mismo, qué las debilidades pueden surgir al forzar a que algo falle, qué datos pueden exponerse ...).

Su (s) servidor (es) web (s) serán investigados de esta manera, constantemente, para cualquier código web posible y lapsos de back-end, por cientos si no miles de herramientas automatizadas. Eso es así como los humanos y los usuarios, no en lugar de.

¿Preferiría que esto estuviera muy lejos en el camino y que los críticos, los medios de comunicación y los usuarios furiosos le llamaran la atención con fuerza, o lo llevaran a la responsabilidad? ¿O prefieres arreglarlo?

Cómo resolverlo

No es un trabajo enorme en un sentido. Usted crea un marco de seguridad y luego cada página lo importa o lo usa. Los conceptos para hacerlo no son difíciles y están bien documentados. Así que el número de páginas no es un gran problema.

La parte difícil del trabajo es que la seguridad es difícil . Su problema real es que, debido al hecho de que estos problemas están ahí y usted hace estas preguntas, no sabe lo suficiente como para tener la esperanza de hacerlo sin ayuda. Seriamente. Tú. Hacer. No.

No sé qué tamaño de equipo tiene, o recursos. Lo necesita, y probablemente no tenga la esperanza de hacerlo sin ayuda externa.

Mi verdadera preocupación aquí

Dicho esto, mi verdadera preocupación no es la aplicación web. Es la mentalidad que sugiere esta pregunta.

Imagina que estoy considerando comprar o usar tu aplicación.

No ayuda, ni tranquiliza al lector, que aparentemente consideres la seguridad como una idea de último momento, una interrupción de tu trabajo o un inconveniente para arreglarlo después (o no lo entiendes lo suficiente como para haberlo tratado hasta ahora) de esa manera), y tal vez los problemas son cosas que son realmente básicas, como codificar correctamente la URL de un botón.

Seguridad es su trabajo, porque a pesar de lo técnicamente maravilloso que sea el producto / servicio y quienes sean sus usuarios, su producto real es confianza y seguridad de que abordará mi Necesita y no me cause un gran desastre.

¿Se supone que debo confiar mi aplicación con mis datos? En este momento, y lamento decir esto, creo que también podría publicarlo en Google+. Sí, es "tan malo" una situación e impresión, y no, esto no lo está exagerando para que tenga efecto.

Lo siento.

Ahora, si tu aplicación es buena, haz que participe otra persona.

Debe verificar el nivel de permiso de usuario para todas las solicitudes (GET, POST, PUT, DELETE). Navegar a una página, como en su caso, es una solicitud GET. Un usuario no debería poder publicar una solicitud sin permiso también.

Ahora, si necesita agregar el código en cada página de su aplicación depende de la estructura de su aplicación. Por ejemplo, algunos marcos (Laravel, Express.JS) le permiten agrupar rutas y aplicar un filtro a cada solicitud de esa ruta, y aquí es donde se colocan los controles. Para las aplicaciones en PHP simple, necesitaría tener el código en cada página, puede usar la declaración "incluir" para minimizar la repetición de todo el bloque de su código.

Se ha dicho antes, pero sí, debe verificar sus credenciales de usuario en cada página. Si su sitio utiliza PHP, por ejemplo, la forma más sencilla de hacerlo es guardar el usuario que ha iniciado sesión y su nivel de privilegio en las variables de sesión, luego realizar una verificación de estas variables de inicio al comienzo del código. Estos se borran al cerrar la sesión (si creó la lógica de cierre de sesión para borrar estas variables) o el tiempo de espera de la sesión (se puede definir el tiempo de espera, pero creo que el valor predeterminado es de 5 minutos de inactividad), por lo que un usuario no autorizado no debería poder acceder una página. Otras tecnologías tendrán un manejo similar.

Realmente no pretendo sonar condescendiente cuando digo esto, así que espero que no lo veas bajo esa luz, pero esto es una especie de información de pan y mantequilla. Si de alguna manera no aprendió esto o no lo encontró en sus estudios personales, le sugiero que tome nota de esto y lea un poco más a fondo sobre este tema en particular, porque es muy importante. Estarás haciendo esto una y otra vez para cualquier aplicación similar del tipo.

Tome nota de que hay varias formas de hacer esto de una manera simple y eficiente, y una sugerencia personal de mi parte para usted sería practicar la codificación en su propia lógica para que pueda comprender completamente cómo funciona, antes de intentar usar un marco. Pruébelo con varios métodos de acceso, y una vez que esté satisfecho, puede ver cómo los distintos marcos realizan el manejo de las sesiones de usuario.

EDIT : escribo esto en un comentario a continuación, pero en realidad es un buen recurso para OP también: enlace

El usuario no debe poder navegar a la página independientemente de si escribe la dirección o hace clic en el enlace.

Una solución genérica para su problema es utilizar un enfoque de control de acceso basado en roles (RBAC). Cree diferentes grupos y asigne usuarios de privilegios iguales al grupo correspondiente. Del mismo modo, agrupar páginas web y otros recursos dentro de diferentes carpetas; cada propiedad de un grupo específico. Usé chgrp (cambio de grupo) para lograr esto en un sistema que ejecuta Linux integrado con un servidor web ligero. Lo mismo se puede lograr en el servidor web Apache colocando un archivo .htaccess y negando el acceso como se menciona en Desbordamiento de pila .

Para los elementos de la interfaz de usuario, tendrá que crear diferentes páginas (u ocultar elementos mediante la verificación de grupo). Deberá identificar al usuario (iniciar sesión y determinar su grupo correspondiente) y luego mostrar las páginas web según los privilegios del usuario.

Solo una sugerencia rápida sobre la implementación, ya que tenía algunas dudas acerca de cientos de páginas. Por ejemplo, en ASP.NET MVC, podría crear un filtro global o una página "base" de la que todos los demás podrían heredar.

Luego, el código, que está ubicado en el centro, puede verificar el contexto / sesión del usuario y compararlo con una lista de derechos / permisos / o pertenencia a grupos para la página actual (tal vez una estructura de datos en cada página o una búsqueda de base de datos basada en nombre de la página, etc.).

Otras respuestas han sido muy generales, así que agregaré esto porque se mencionaron JSP , por lo que creo que Puedo asumir que estás trabajando en Java.

Como tal, lo más probable es que puedas usar Filtros tener código ejecutado cada vez que se realiza una solicitud a la aplicación. Si usa un marco de seguridad como Spring puede configurar las URL a las que se puede acceder y quién puede acceder a ellas.