Configuring RequestHeaderAutoLogin opens your system up to attackers

• Type: Bug
• Status: Closed
• Resolution: Won't Fix
• Affects Version/s: 6.0.5 GA
• Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
• Component/s: Accessibility, Security Vulnerability
• Labels: None

Problem
=======

If you configure RequestHeaderAutoLogin in portal-ext.properties like this :

auto.login.hooks=com.liferay.portal.security.auth.RequestHeaderAutoLogin

It open's up your system to attackers

RequestHeaderAutoLogin checks if the LIFERAY_SCREEN_NAME header is set on the request. When it sets, it finds the user that corresponds to the specified screen name and logs you in as that user. No questions asked. It does not check any credentials

Because headers can be set on the client side, this is a huge security risk.

Steps to reproduce
===============

• Configure the RequestHeaderAutoLogin in portlet-ext.properties
• Download the poster plugin for firefox and craft a request that points to http://localhost:8080/web/guest and has the liferay_screen_name header set to [e-mail]

You will be logged in as the admin user

Possible solution
==============

This hook should be changed to include a white list of ip's / hosts for which it allows access in this way

[Jelmer Kuperus (Inactive)]

Attached screenshot that shows how to reproduce the issue

[Jelmer Kuperus (Inactive)]

Actually the liferay_screen_name header should be set to test, and not not [e-mail] as stated in the issue. Sorry about that

[Sophia Zhang]

I could reproduce it on 60x-74098.
After I set the proper poster plugin settings,I clicked Get,then I got the the reporter's Response.
Then I login as http://localhost:8080.
I found that I didn't have to sign in.This is insecure.

[Mika Koivisto]

It is working exactly as designed. This auto login hook is meat to be used with another security product such as Tivoli Access Manager. The third party product will filter out the header when faked by the user making the request. SiteMinderAutoLogin is similar but geared specially for SiteMinder. SiteMinder will provider SM_USER header when the user is authenticated and if the user does not have a proper siteminder session it will strip it.

[Jelmer Kuperus (Inactive)]

Mika, if a WSRP portlet requires a the user to be authenticated, you need to configure this hook as well. So it's use is not exclusive to products like Tivoli Access Manager. It is documented on the wiki by Ruth Coca (a Liferay employee) at http://www.liferay.com/community/wiki/-/wiki/Main/WSRP

If you would follow those instructions today you would be in trouble.

If you could limit the requests to ones originating from the WSRP consumer it would be relatively safe

[Mika Koivisto]

True Ruth is a Liferay consultant but Wiki is community documentation and not official. The official documentation is available http://www.liferay.com/documentation. I'll ask Ruth to update that page to inform of the security implications.

[Jelmer Kuperus (Inactive)]

Mika, still i think that many of the users that are using WSRP (especially those using sso) have a need to pass along the security credentials from the consumer to the producer. As far as I know configuring the RequestHeaderAutoLogin hook is the only way to achieve this. By refusing to address this issue you effectively leave users with only an insecure option to address one of the most common usecases.

[Jelmer Kuperus (Inactive)]

Additionally, in portal.properties you will find the following recommendation

#

1. Set this to true to automatically import users from LDAP if they do not
2. exist in the portal. The property "auto.login.hooks" must contain a
3. referece to the class
4. com.liferay.portal.security.auth.RequestHeaderAutoLogin to enable request
5. header authentication.
   #
   request.header.auth.import.from.ldap=false

[Mika Koivisto]

Thanks for your feedback Jelmer. I've created a new improvement to add additional security checks for it when used with WSRP. The issue is LPS-15591