Monday, March 31, 2014

Cross Site Request Forgery (CSRF) Prevention in Liferay

Introduction:

Cross Site Request Forgery (CSRF) is one of the web vulnerability in web applications.
CSRF is an attack which forces the end user to execute unwanted actions on web applications as this result unwontedly some of sensitive data will be updated by mal data.

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

More information Please go through following link


Prevention:

To prevent CSRF attack need to generate Synchronizer Token Pattern and we need to associate all actions with this token.

In each URL we will add this token and before execute any form action or some link action then the server will check the token , if the token is valid then it will be execute the action.

Liferay Implementation:

Liferay also implemented mechanism to prevent CSRF attack. In liferay all URLs will generate with one of the request parameter called p_auth.

p_auth is portal authentication token to prevent CSRF attack. By default all liferay URLs p_auth request parameters is included.

Concept:

For each Portlet and each request URL contains p_auth parameter and its values is random alphanumeric string consist of some pattern.

As soon as URL is generated then token will be stored in Session and token will be in request parameter as p_auth. when we perform any action then there is some AuthToken java class which is responsible to check the token. If the token is valid then action will be executed otherwise it will be prevent.

Example URL which Contains CSRF token or p_auth


http://eportal.aswatson.net/web/guest/home?
p_auth=8prVcgJC&p_p_auth=PitE9LxF&
p_p_id=signinaction_WAR_SiginInportlet&p_p_lifecycle=1&
p_p_state=pop_up&p_p_mode=view&controlPanelCategory=
portlet_signinaction_WAR_SiginInportlet&
_signinaction_WAR_SiginInportlet_cmd=update


Note:

This token validity for particular time after that token will be expired.

Manage Portal Authentication Token

Liferay by default all URLs and all action will be associated with p_auth parameter to prevent CSRF.

Some time we may not need this for every time so how we need to handle will see in the following article.

Enable Portal Authentication Token using following property in portal.properties file


auth.token.check.enabled=true


Note:

By default it enabled if you want change then we will use portal-ext.properties file to override.

Liferay implemented Token Authentication java class which is responsible to validate and generate token. We can also implement our own java class to handle CSRF token

The following is property to handle Token Implementation Class


# Set the authentication token class. This class must implement
# com.liferay.portal.security.auth.AuthToken. This class is used to prevent
# CSRF attacks. See http://issues.liferay.com/browse/LPS-8399 for more information.

auth.token.impl=com.liferay.portal.security.auth.SessionAuthToken


Note:

SessionAuthToken is default implementation class and we can also implement our own class and that should implement the AuthToken interface. We need to add our implementation class in the above list.

Well we understand how to enable Portal Authentication Token (p_auth) to prevent CSRF.
Some time we may not need this for every portlet and every URL. The following are different ways and different scenarios we will disable Portal Authentication Token.

Ignoring actions from token authentication check:

We can ignore some actions to avoid authentication check.

The following is property and we need to specify list of struts actions which don’t need authentication check.

   
# Input a list of comma delimited struts actions that will not be checked
    # for an authentication token.
    #
auth.token.ignore.actions=\
/asset/rss,/asset_publisher/edit_article_discussion,\
/asset_publisher/edit_entry_discussion,\
/asset_publisher/edit_file_entry_discussion,\
/asset_publisher/edit_page_discussion,/blogs/edit_entry,\
/blogs/edit_entry_discussion,\
/blogs/rss,/blogs/trackback,/blogs_aggregator/edit_entry,\
/blogs_aggregator/edit_entry_discussion,/blogs_aggregator/rss,\
/calendar/edit_event_discussion,/document_library/edit_file_entry,\
/document_library/edit_file_entry_discussion,\
/document_library_display/edit_file_entry,\
/document_library_display/edit_file_entry_discussion,\
/journal/edit_article_discussion,\
/journal/rss,/journal_content/edit_article_discussion,\
/image_gallery_display/edit_file_entry,\
/image_gallery_display/edit_image,/login/login,\
/message_boards/edit_discussion,\
/message_boards/edit_message,/message_boards/rss,/my_sites/view,\
/page_comments/edit_page_discussion,/shopping/edit_order_discussion,\
/software_catalog/edit_product_entry_discussion,/wiki/edit_page,\
/wiki/edit_page_attachment,/wiki/edit_page_discussion,\
/wiki/get_page_attachment,\
/wiki/rss,/wiki_admin/edit_page_attachment,\
/wiki_display/edit_page_attachment,\
/wiki_display/edit_page_discussion


Note:

By default many struts action are included in list if you want add new action or change something then we will use portal-ext.properties file to override.

Ignoring portlets from authentication token check

We can also ignore/avoid portlets from Portal Authentication Check.
The following portal property we will use to handle and we need to add portlet ids with comma delimiter.


# Set a list of comma delimited portlet ids that will not be checked for an
# authentication token.

auth.token.ignore.portlets=82,87, userpreferences_WAR_Stocksportlet


Ignore for Individual Portlet

We can also ignore/avoid portal authentication check by using portlet.xml file.

We need to add following init parameter tag in portlet.xml file


<init-param>
 <name>check-auth-token</name>
 <value>false</value>
</init-param>


Portlet Authentication Token (p_p_auth)

In Liferay we have feature called we can add portlet dynamically to any page. Generally we will add portlet in page some time we may need to add portlet to page dynamically.

Example scenarios load portlet in Pop Up. Load some portlet in Div in page and share portlet in some other places.

When we get such scenarios we will use add-default-resource tag in liferay-portlet.xml file.
When we make above tag true then we load portlet in any page dynamically and we can share portlet in other places.

In such scenarios to prevent some vulnerability we will use Portlet Authentication Token (p_p_auth) in request parameter.

Portlet Authentication Take (p_p_auth) is as alpha numeric string which generate randomly to Portlet URLs for which portlet enabled add-default-resource.

Enable add-default-resource we need to add following tag in liferay-portlet.xml file


<portlet>
                        <portlet-name>PortletY</portlet-name>
                        <icon>/icon.png</icon>
                        <instanceable>false</instanceable>
                        <header-portlet-css>/css/main.css</header-portlet-css>
                        <footer-portlet-javascript>/js/main.js
                        </footer-portlet-javascript>
                        <css-class-wrapper>portlety-portlet</css-class-wrapper>
                        <add-default-resource>true</add-default-resource>
                       <system>true</system>
</portlet>


Enable Portlet Authentication Token(p_p_auth)

To enable Portlet Authentication Token (p_p_auth) we need use following portal property.


portlet.add.default.resource.check.enabled=true


Note:

By default it enabled in portal if you want change then we will use portal-ext.properties file to override.

Ignore/Bypass/Avoid Portlet Authentication Check for Portlets:

The following property will bypass portlet from Portlet Authentication Check


# Set a list of comma delimited list of portlet ids that will bypass the
# security check set in the property
 # "portlet.add.default.resource.check.enabled".
 portlet.add.default.resource.check.whitelist=3,56_INSTANCE_0000,58,82,\
86,87,88,103,113,145,164,166,170,177


Note:

By default many portlet are included in the list if you want add new portlet or change something then we will use portal-ext.properties file to override.

Ignore/Bypass/Avoid Portlet Authentication Check for Actions:


# Input a list of comma delimited struts actions that will bypass the
# security check set in the property
# "portlet.add.default.resource.check.enabled".

    portlet.add.default.resource.check.whitelist.actions=\
        /journal/rss,\
        /language/view


Note:

If we want override existed portal properties we will use portal-ext.properties file or we will use Liferay Hook Plugin.

Important Points


p_auth      :  Portal authentication token for CSRF protection

p_p_auth : Portlet authentication token for add-default-resource protection



Author

Friday, March 28, 2014

Liferay Building Blocks

Introduction:

Liferay is huge web portal consists of many things which make ready to use web application in real time. In the theoretical way liferay consist of following building blocks which will run the entire liferay portal.
  1. Site
  2. Organization
  3. Users Group
  4. Roles and Teams
  5. Users
  6. Permissions

Site:

Liferay have concept called site, in general site is like website which consist of pages, web content , users  and some dynamic functionality, we can say sites are used to organize pages, content, application data.

In general business scenario we will display our information through website in the internet  and we will use some html or some other web application technology to achieve it ,similar way liferay have site feature so that we can create site and we can show our content to end users.

To make this liferay have different artifacts like pages, web content and some dynamic applications called portlet, all together will make website or site.

For each site we have different stake holders or end users to access the site, in the same way liferay have users and we can assign users to particular site so that they will surf around the web site.

In the site we will have site pages and each page have certain layout and each page consist of some static content and dynamic content.

In liferay we will use Web content management system to design content for site and we will use portlet application to meet dynamic functionality. We will learn more about WCM and Portlets in the future articles. In site any one can be members like users, organizations and user groups.

Sites have parent child relation so that the content will be sharable to child sites its bases on some configuration and these are handled by  portal properties.

 In the site we can categorize into following ways

Open:

 Users can become members of the site at any time any use can register and join in this website.

Restricted:

Users can request site membership but site administrators must approve requests in order for users to become members. Requests can be made from the My Sites portlet.

Private:

 Users are not allowed to join the site or request site membership. Private sites don’t appear in the My Sites portlet. Site administrators can still manually select users and assign them as site members.

Site has following capabilities
  • Membership management
  • Content Management
  • Document Management
  • Blogs
  • Wikis
  • Role management
  • Permission Management
  • Site data Export/Import
  • Coloration tools like Calendar

Organization:

Organization is similar to site but it can used to only group the people and manage them.
In organization also we can have pages, web contents and users. In the organization users only can be members.

In the organization we can create users and assign users to specific organization by admin.
We have roles so that roles will decide the user’s accessibility over the organization like when he/she accesses some data or some applications.

When we use organization ,we will use organization roles , apart from this we can also create teams with in organization and we can assign users to teams.

Teams also have some permission so that it will decide user’s accessibility over organization.
In the organization we have Parent and Child relation and we have two types of organization regular and Location based organization.

We will see more about Liferay Organization in the future articles.

Users Group

Users Group is another specific use in general business scenarios. We will use users groups to group specific interested peoples.

Here users may belong to any site or organization but he can be member for any user group.
Example we have Big IT Company across globe and each area we may have location wise organizations. But people may have interest in particular area like Photography so here all interested people can join in Photography User Group but users may be belongs to any organization which may be reside in any area.

Roles and Teams

Roles are grouping of users that share a particular function within the portal, according to a particular scope. Roles can be granted permissions to various functions within portlet applications.

Roles are associated to user so that it will decide what kind of access user has in the site/organization/user group.

Roles are available to sites/organization/user group based on role type.

We have following Role Types:
  1. Portal Role/Regular Role
  2. Site Role
  3. Organization Role

Portal Role/Regular Role

Liferay is providing Portal Role/Regular Role for portal level. It’s not specific to anything like Organization, Site or User Group. This role can be assigned to any user who belongs to any one of Organization, Community or User Group.

Liferay Provided Following Regular Roles by Default

Administrator:

Administrators are super users who can do anything.

Guest:

Unauthenticated users always have this role.

Owner:

This is an implied role with respect to the objects users create.

Power User:

Power Users have their own personal site.

User:

Authenticated users should be assigned this role.

The following diagram shows meaning of regular role


We can associate regular to any used who belongs to Organization/Site/User Group

Scenario:



Assume there is one regular role called RR1
There two organizations OrganizationA and OrganizationB
We have user called User1
We assign RR1 to User1
RR1 have edit permission PortletA
User1 € OrganizationA is having role RR1 if login to OrganizationA he will get Edit Permission on PortletA.
User1 € OrganizationB is having role RR1 if login to OrganizationB he will get Edit Permission on PortletA.

Note:

Here if we assign regular role to the user if the user belongs to multiple organization or sites he/she will be getting same permissions on the resources which are in different organizations or communities.

When we work with regular roles we should very cautious while using in organization, communities or user groups.

Site Role:

Site Role is one of the types in liferay which is only associated to Site users. This role only we can associate to site users.
When we create site role we can use this site role to any used who belongs to any site liferay.



Liferay Provided Following Site Roles by Default

Site Administrator:

Site Administrators are super users of their site but cannot make other users into Site Administrators

Site Member:

All users who belong to a site have this role within that site.

Site Owner:

Site Owners are super users of their site and can assign site roles to users.

Organization Role:

Similar to site role organization role is used for organization users. This role can be associated to any user who belongs to any organization in portal.

The following diagram shows meaning of Organization Role



Liferay Provided Following Organization Roles by Default

Organization Administrator:

Organization Administrators are super users of their organization but cannot make other users into Organization Administrators.

Organization Owner:

Organization Owners are super users of their organization and can assign organization roles to users.

Organization User:

All users who belong to an organization have this role within that organization.

Scenario:

We have tow organization type roles OTR1 and OTR2
For OTR1 EDIT ACTION on PortletA
For OTR2 VIEW ACTION on PortletA
We have user called User1
We have two Organizations OrganizationA and OrganizationB
For User1 we have assigned OTR1 in OrganizationA
For same user User1 we have assigned OTR2 in OrganizationB
When he login into OrganizationA he has EDIT permission on PortletA.
When he login into OrganizationB he has VIEW permission on PortletA
Here organization roles work in the premises of organization associated with respective roles.

The following diagram depicts the entire concept.



Note:

Teams are similar to role but teams will work with in organization/site unlike role.
If we create any team in site/organization then it will be available to with in organization/site, so that we can associate teams to the users who are belongs to specific site/organization.

If we create any role we can use role to all organization/sites based on role type but when create team the team will be used within organization/site where we created.

Users

Users are the stake holders to the portal.In liferay we have many users who are associated with different roles and they are belongs to sites/organization/user group.

If any user  wants to get access over any site/organization foremost thing is user should be member of Site/Organization. In liferay each user may associate with one more roles similarly user may belongs to one or more sites/organization/user groups.

Each role has set of permission so that user will get specific set of access over the site/organization/with application/page.

Based on role and its associated permissions will make the user will get access over site/organization.

Permissions:

Permission is set of actions which will act on object/resource. In liferay each and every object we can  call it as Resource and each resource have set of actions. These actions are controlled by permissions.

In liferay each permission/action will be associated with role and role will be associated with user. Finally permission will be controlled the access of user over the site/ organization

The following is Under Standing Diagram about Permission System


We have deferent kind of permission in liferay
  1. Page level permission
  2. Portlet level permission
  3. Individual Resource level permission

Page level permission:

Page level permission will be decided whether page should be visible to particular role user or not. Based on permission action page will be visible to user

Portlet level permission:

Portlet Level permission will decide whether portlet should be visible to particular role user or not.

Individual Resource level permission

Individual resources like image, document or functionality with in portlet or application.
Example in Announcement portlet we have add announcement. Update and delete announcement.

We will assign delete, add and Update permission to only Admin Role users all other users can only view announcement.

If we have some document we will give particular role user can only download. Such kind of things we will call it as Individual Recourse Permissions.

Author

Popular Posts

Recent Posts

Recent Posts Widget