You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Michael Gustav Simon <mg...@gmail.com> on 2006/03/06 15:41:35 UTC
Security Issue
Hi J2-Users,
to integrate J2 as a "SingleSignOn"-Client, I analyze the login process in
detail.
I think that the redirect to the login.jsp from the LoginJSPViewValveImpl in
the LoginPipeline is not secure.
The username and password will be send to the client in plain text!
The javascript in the body tag will post the data to the servlet container
with the javascript call onload.
...
<body onLoad='document.forms["login"].submit();'>
...
What is about the browser cache?
mg
Re: Security Issue
Posted by Aaron Evans <aa...@gmail.com>.
Randy is correct that the redirect to the page with the onload is no less
secure than the initial form post.
I too was a little concerned about this at first, but after thinking about
it, less so. And I am very familiar with the reason why they chose to do
it this way.
With tomcat realm authentication, you can't really navigate directly to the
actual login page. You must first attempt to access a protected resource
and get bounced to the login page. If you don't go about it this way, you
get a weird error. It is a real pain in the butt and a tomcat bug if you
ask me, but whatever.
In any event, this is the work around. What happens is that the login
portlet isn't the actual login page. Instead, when you use the login
portlet, it posts to a protected resource. You then get bounced to the
actual login page, which is the blank page which does the post to
j_security_check on the onload event.
aaron
On 3/6/06, Randy Watler <wa...@wispertel.net> wrote:
>
> Michael,
>
> Thanks for taking the time to check the security systems of J2. The more
> eyes the better!
>
> However, I believe that these concerns are not as significant as one
> might think at first glance.
>
> 1. If you are using J2 as a SSO solution, you should be using HTTPS/SSL
> for the portal and all content aggregated by the portal. This will
> upgrade the connections under most normal conditions to ensure user
> credentials are not "in the clear". The redirects in J2 are no more or
> less secure than the initial post in login portlet. The redirects and
> form entry techniques are designed to implement the standard JAAS
> container authentication model and are widely used.
>
> 2. AFAIK, the redirect pages are specifically NOT cached or included in
> the browser history. Browsers are explicitly instructed not to cache to
> any portal requests. This should ensure that after a session is closed,
> no memory of the portal session should persist.
>
> Please let us know if you see any behavior to the contrary. AFAIK, J2
> uses no technique that is not employed commonly on secure websites. It
> is designed to be a solid SSO solution... this is certainly a common
> portal use case!
>
> Let us know if you see any other suspect behavior,
>
> Randy
>
> Michael Gustav Simon wrote:
> > Hi J2-Users,
> > to integrate J2 as a "SingleSignOn"-Client, I analyze the login process
> in
> > detail.
> > I think that the redirect to the login.jsp from the
> LoginJSPViewValveImpl in
> > the LoginPipeline is not secure.
> > The username and password will be send to the client in plain text!
> > The javascript in the body tag will post the data to the servlet
> container
> > with the javascript call onload.
> > ...
> > <body onLoad='document.forms["login"].submit();'>
> > ...
> > What is about the browser cache?
> >
> > mg
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: Security Issue
Posted by Randy Watler <wa...@wispertel.net>.
Michael,
Thanks for taking the time to check the security systems of J2. The more
eyes the better!
However, I believe that these concerns are not as significant as one
might think at first glance.
1. If you are using J2 as a SSO solution, you should be using HTTPS/SSL
for the portal and all content aggregated by the portal. This will
upgrade the connections under most normal conditions to ensure user
credentials are not "in the clear". The redirects in J2 are no more or
less secure than the initial post in login portlet. The redirects and
form entry techniques are designed to implement the standard JAAS
container authentication model and are widely used.
2. AFAIK, the redirect pages are specifically NOT cached or included in
the browser history. Browsers are explicitly instructed not to cache to
any portal requests. This should ensure that after a session is closed,
no memory of the portal session should persist.
Please let us know if you see any behavior to the contrary. AFAIK, J2
uses no technique that is not employed commonly on secure websites. It
is designed to be a solid SSO solution... this is certainly a common
portal use case!
Let us know if you see any other suspect behavior,
Randy
Michael Gustav Simon wrote:
> Hi J2-Users,
> to integrate J2 as a "SingleSignOn"-Client, I analyze the login process in
> detail.
> I think that the redirect to the login.jsp from the LoginJSPViewValveImpl in
> the LoginPipeline is not secure.
> The username and password will be send to the client in plain text!
> The javascript in the body tag will post the data to the servlet container
> with the javascript call onload.
> ...
> <body onLoad='document.forms["login"].submit();'>
> ...
> What is about the browser cache?
>
> mg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org