ogin.jps" contiene los siguientes dos hipervínculos:
enlace SSL
Enlace no SSL
Luego, el primer enlace utiliza el mismo protocolo de transporte que "https://192.168.100.100/ok /login.jsp"
HTTPS, el segundo enlace utiliza el protocolo HTTP identificado por sí mismo.
La ventaja de utilizar hipervínculos estáticos es que son fáciles de implementar y no requieren desarrollo adicional. Sin embargo, no es fácil de mantener y administrar porque en una aplicación web a la que se accede completamente mediante el protocolo HTTP, cada recurso se almacena en un directorio raíz específico de la aplicación.
En cada subdirectorio, el Las rutas de enlace de los recursos utilizan rutas relativas. Esto se hace para facilitar la migración y la gestión de aplicaciones. Pero si algunos recursos de la aplicación usan el protocolo HTTPS, el enlace referenciado debe usar la ruta completa
, por lo que cuando la aplicación se migra o necesita cambiar cualquier parte involucrada en la URL como: nombre de dominio, directorio, nombre de archivo, etc., el mantenedor necesita modificar cada hipervínculo y la carga de trabajo se puede imaginar. Además, si los clientes ingresan manualmente los recursos del protocolo HTTPS en la barra de direcciones del navegador
entonces todos los datos sensibles y confidenciales no estarán protegidos durante la transmisión y pueden ser fácilmente pirateados
¡Interceptación y manipulación del cliente!
Método 2 Restricciones de acceso a recursos
Para proteger datos confidenciales en aplicaciones web, evitar el acceso ilegal a recursos y garantizar la seguridad de la transmisión, Java Serv
deja que el La especificación 2.2 define el elemento Security-Constraint, que se utiliza para especificar las restricciones de seguridad de uno o más conjuntos de recursos web. El elemento User-Data-Constraint es una subclase de seguridad del elemento de restricción; p>
que especifica cómo se protegen los datos transferidos entre el cliente y el contenedor. El elemento de restricción de datos del usuario también incluye el elemento Transporte-Garantía, que estipula que la comunicación entre el cliente y el servidor debe ser uno de los siguientes tres modos: Uno: Ninguno, Integral, Confidencial. Ninguno indica que el recurso web especificado no requiere ninguna garantía de transmisión; Integral indica que los datos transmitidos entre el cliente y el servidor no serán manipulados durante el proceso de transmisión. Confidencial indica que los datos se cifran durante la transmisión. En la mayoría de los casos, Integral o Confidencial se implementa mediante SSL.
Aquí tomamos WebLogic Server 6.1 de BEA como ejemplo para presentar su método de implementación. WebLogic es un servidor J2 EE con excelente rendimiento.
Puede administrar recursos web, incluidos EJB, JSP,. Control de acceso a la configuración de la aplicación servlet
Términos. Supongamos que una aplicación está construida en el directorio /mywebAPP en Weblogic Server, y algunos de los Servlets y JSP requieren transmisión SSL. Luego puede colocarlos todos en el directorio /mywebAPP/sslsource/. luego compila
Edita el archivo /secureAPP/Web-INF/web.xml. Al configurar web.xml, puedes controlar el acceso a los usuarios web
.
Cuando un usuario web intenta acceder a recursos en el directorio /sslsource a través de HTTP, Weblogic Server buscará la definición de restricción de acceso en we
b.xml y devolverá el mensaje siguiente: Necesita conexión SSL para acceder a este recurso. La combinación de restricciones de acceso a recursos e hipervínculos estáticos no solo hereda la simplicidad y facilidad de uso del método de hipervínculo estático
, sino que también protege eficazmente los datos confidenciales de los recursos. Sin embargo, habrá un problema: si un cliente web utiliza el protocolo HT
TP para acceder a recursos de red que requieren SSL, aparecerá un mensaje emergente: Necesita conexión SSL para
acceder a este recurso, es posible que la mayoría de las personas no sepan que se debe utilizar HTTPS para acceder a esta página web. La consecuencia
es que los usuarios dejarán de acceder a la página web, algo que los proveedores de servicios de aplicaciones web no quieren. para ver.
Método tres redirección de enlaces
Si observamos el acceso interactivo actual a los datos de recursos de sitios web comerciales, los datos que requieren cifrado y transmisión estrictos solo representan una pequeña parte.
Además, es decir, los programas de servicio que necesitan utilizar SSL en una aplicación web específica sólo representan una pequeña parte del total. Luego, podemos considerar soluciones desde la perspectiva del desarrollo de aplicaciones y procesar aquellas partes de JSP, Servlets o EJB que necesitan usar el protocolo HTTPS, de modo que el programa en sí pueda determinar primero al realizar una solicitud. si el protocolo utilizado por la solicitud cumple con los requisitos de este programa, es decir, si la solicitud entrante utiliza el protocolo HTTPS. De lo contrario, redirija el protocolo de acceso a HTTPS
. confundidos acerca de qué hacer cuando ven mensajes de error
al usar el protocolo HTTP para acceder a recursos web que requieren el uso del protocolo HTTPS. Estos procesos son transparentes para los clientes web.
La idea de implementación es: primero crear una clase, cuyo método pueda guiar automáticamente las solicitudes de acceso de los clientes web para que utilicen el protocolo HTTP
PS, y cada Servlet o Servlet que requiera SSL para Los JSP lo llaman al comienzo del programa para la redirección del protocolo y finalmente realizan el procesamiento de la aplicación de datos.
J2EE proporciona dos mecanismos de redirección de enlaces. El primer mecanismo es el método forward()
en la interfaz RequestDispatcher. Las aplicaciones web que utilizan el mecanismo MVC (Modelo-Vista-Controlador) suelen utilizar este método para transferir solicitudes de Servlet
a JSP. Sin embargo, este tipo de redirección sólo puede realizarse entre el mismo tipo de protocolos y no puede redirigirse a protocolos diferentes.
El segundo mecanismo es utilizar el método sendRedirect() en la interfaz HTTPServletReponse, que puede utilizar cualquier protocolo
para redirigir a cualquier URL, por ejemplo:
BeSslResponse .sendRedirect(“https://192.168.100.100/order”);
Además, también necesitamos usar dos métodos en la API de Servlet de Java: getS en la interfaz ServletRequest
cheme(), que se utiliza para obtener el protocolo de transmisión utilizado por la solicitud de acceso; getRequestUrl() en la clase HTTPUtils, que se utiliza
para obtener la URL de la solicitud de acceso. Tenga en cuenta que este método está en Servlet 2.3 y se ha movido a la interfaz HTTPServletReq
uest.
Los siguientes son los pasos básicos para implementar la redirección de protocolo:
1. Obtener el protocolo utilizado por la solicitud de acceso
2. la solicitud de acceso El protocolo requerido por el Servlet significa que se ha utilizado el protocolo HTTPS y no se requiere procesamiento;
3. Si no cumple con los requisitos, use el protocolo requerido por el Servlet (HTTPS). ) Redirigir a la misma URL.
Por ejemplo, un usuario web utiliza el protocolo HTTP para acceder al recurso BeSslServlet que requiere el uso del protocolo HTTPS. Escriba "UR
L: http://192.168.100.100. /BeSslServlet" y ejecute Cuando BeSslServlet, primero use Proces
sSslServlet. ProcessSsl() redirige a https://192.168.100.100/BeSslServlet y luego los datos se transmiten entre BeSslServlet y el navegador del cliente a través del protocolo HTTPS.
La introducción anterior es solo el ejemplo más simple, para tener una comprensión preliminar de este método de redirección. Si realmente desea implementarlo en una aplicación web, también debe considerar las siguientes cuestiones:
● En las aplicaciones web, el método GET o Post se utiliza a menudo para acceder a la URL solicitada y generará alguna consulta. strings.
Estas cadenas no se pueden obtener cuando se usa getRequesUrl() y se perderán después de la redirección, por lo que deben redirigirse
Agréguelas a la nueva URL antes. Podemos usar request.getQueryString() para obtener la cadena de consulta de G
ET. Para los parámetros de solicitud de Post, se pueden convertir en cadenas de consulta para su procesamiento.
● Algunas solicitudes de aplicaciones web utilizarán objetos como atributos. Estos atributos deben guardarse en la
sesión antes de la redirección para usarse después de la redirección.
● La mayoría de los navegadores considerarán el acceso a diferentes puertos en el mismo host como acceso a diferentes hosts y separarán
sesiones diferentes para conservarlas después de la redirección para utilizar la sesión original. , el nombre de dominio de Cookie
del servidor de aplicaciones debe configurarse en consecuencia.
Los problemas anteriores se pueden resolver en programación.
Al implementar la redirección de protocolo en el propio programa, los recursos que requieren una protección estricta se pueden separar lógicamente de otros datos ordinarios, de modo que los recursos que requieren el uso de SSL y los que no utilizan los recursos que necesitan utilizar SSL para evitar desperdiciar los recursos del sistema del sitio web.