PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-15517

Configuring RequestHeaderAutoLogin opens your system up to attackers

    Details

    • Similar Issues:
      Show 3 results 

      Description

      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 test@liferay.com

      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

        Issue Links

          Activity

          Hide
          Jelmer Kuperus added a comment -

          Attached screenshot that shows how to reproduce the issue

          Show
          Jelmer Kuperus added a comment - Attached screenshot that shows how to reproduce the issue
          Hide
          Jelmer Kuperus added a comment -

          Actually the liferay_screen_name header should be set to test, and not not test@liferay.com as stated in the issue. Sorry about that

          Show
          Jelmer Kuperus added a comment - Actually the liferay_screen_name header should be set to test, and not not test@liferay.com as stated in the issue. Sorry about that
          Hide
          Sophia Zhang added a comment -

          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.

          Show
          Sophia Zhang added a comment - 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.
          Hide
          Mika Koivisto added a comment -

          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.

          Show
          Mika Koivisto added a comment - 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.
          Hide
          Jelmer Kuperus added a comment -

          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

          Show
          Jelmer Kuperus added a comment - 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
          Hide
          Mika Koivisto added a comment -

          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.

          Show
          Mika Koivisto added a comment - 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.
          Hide
          Jelmer Kuperus added a comment -

          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.

          Show
          Jelmer Kuperus added a comment - 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.
          Hide
          Jelmer Kuperus added a comment -

          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
          Show
          Jelmer Kuperus added a comment - Additionally, in portal.properties you will find the following recommendation # Set this to true to automatically import users from LDAP if they do not exist in the portal. The property "auto.login.hooks" must contain a referece to the class com.liferay.portal.security.auth.RequestHeaderAutoLogin to enable request header authentication. # request.header.auth.import.from.ldap=false
          Hide
          Mika Koivisto added a comment -

          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

          Show
          Mika Koivisto added a comment - 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

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 7 weeks, 5 days ago

                Development

                  Structure Helper Panel