JSF SSL Hazzard
In my application it is required that only certain pages need to be secured using SSL so i configured it
security-constraint>
<display-name>Security Settings</display-name>
<web-resource-collection>
<web-resource-name>SSL Pages</web-resource-name>
<description/>
<url-pattern>/*.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<description>CONFIDENTIAL requires SSL</description>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
and added filter
http://blogs.oracle.com/jluehe/entry/how_to_downshift_from_https
but only one hazard is there.i am using it with richFaces. once it goes to HTTPS its not changing the page i mean if i perform post action it doesnt actually happens. but if i do it from the 开发者_如何学运维local bmachine's browser it works perfectly from remote browser it stucks with HTTPS its not changing after that
here is my web.xml's snap
<filter>
<filter-name>MyFilter</filter-name>
<filter-class>MyFilter</filter-class>
<init-param>
<param-name>httpPort</param-name>
<param-value>8080</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>MyFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected resource</web-resource-name>
<url-pattern>somePattern</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
and some other filters of richfaces.problem is strange.if i try to access the web app from local's machine's browser it works fine but in remote machine's browser once it get into HTTP , all the forms of that page aswell as href stops working.(JSF,facelet is used.)
In my application it is required that only certain pages need to be secured using SSL so i configured it
Information submitted by the user isn't the only thing you have to worry about. In short what you are trying to accomplish is a vulnerability.
The only time this is safe is if the user is no longer authenticated to your application. By doing this you will be sending your SESSION ID in clear text. Session id's are used to authenticate browsers, and if an attacker where to obtain this value though XSS or by Sniffing the line then he won't need a username/password.
This is the most commonly misunderstood part of The OWASP Top 10 2010 A3-Broken Authentication and Session Management
精彩评论