Liferay Security

[Maulin Rathod, geändert vor 15 Jahren.]

Hi,

We are using Liferay version 5.1.2.

I can see that many request has parameters in querystring. We are concerned about security what if someone changes data in url (using some tool like firebug, IE developer toolbar).
Any idea how liferay handles such scenarios? Our application needs to pass through strict security audit. Is liferay following some security measures?


Regards,

Maulin

[vinod goyal, geändert vor 15 Jahren.]

Hi ,

We perform a testing on Liferay 5.0.1 and found the various security issues. These issues are as follows:

1. CROSS SITE SCRIPTING

Exp. Various scripts are executed in the URL/FORM parameter when the page reloads.

Impact: XSS vulnerability allows malicious user to execute scripts to capture user identity information or to inject HTML Code into the vulnerable application.

2. INJECTION FLAWS

Exp. The response contained a new header, inserted by the successful HTTP Response Splitting attack

Impact: When user input is embedded as-is in HTTP response headers, it may be possible for an attacker to terminate the "current" response (by injecting the necessary HTTP response headers), and then to add his/her own additional complete HTTP response. The attacker can then orchestrate the traffic in such a way that when an additional request is sent it appears to generate the additional response.

3. BROKEN AUTHENTICATION AND SESSION MANAGEMENT

Exp. A http parameter was found to hold a URL value and cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.

Impact: It may be possible to persuade a naive user to supply sensitive information such as username, password etc

4. Authentication Brute Force Attack

Exp. application does not limit the number of false login requests in the Authentication page

Impact: The attacker may eventually discover the password for a particular user account by (brute forcing) sending a large number of possible passwords

5. INFORMATION LEAKAGE AND IMPROPER ERROR HANDLING [

5.1 Insecure HTTP Methods Enabled (Count-1)

Exp. Insecure HTTP methods like GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS are enabled.

Impact: The OPTIONS HTTP method provides a malicious user with the most direct and effective way to figure out which HTTP methods are supported by the web server. The PUT & DELETE methods enable an attacker to remotely add web pages or delete files, thus enabling website defacement. The TRACE method allows any malicious user, to trace the content that is received at the other end of the request, to make use of it to perform specific attacks on the application.

5.2 Application Exceptions Revealed

Exp. It is possible to gather error information in application

Impact: Information obtained from the errors displayed may be used by the attacker to perform specific application attacks directly on the web application.

5.3 Web server Banner Information revealed

Exp. web server banner revealed sensitive server related information as follows : "Server: Apache/2.2.3 (Red Hat) Liferay-Portal: Liferay
Portal 5.1.2 (Calvin / Build 5102 / October 3, 2008)"

Impact: Server specific information revealed by web server might facilitate the attacker to perform version specific attacks on the UBMI application server.

6. INSECURE COMMUNICATIONS

Exp. Failure to encrypt sensitive communications - Sensitive information such as password was sent unencrypted to the server and/or back to the user.

Impact: Any information sent to the server can be used for malicious purposes.

7. FAILURE TO RESTRICT URL ACCESS

Exp. Link for uploading images to the server is not restricted

Impact: It is possible for any user to upload images to the UBMI server without authentication.

8. Forceful Browsing

Exp. It is possible for any unauthorized user to view the admin page by forcibly browsing to the page

Impact: If successfully exploited, this would lead an unauthorized user to perform admin functions.

Please update if you have come across similar issues and If Liferay has any fix for any of these.

Regards,

Vinod

[Victor Zorin, geändert vor 15 Jahren.]

Vinod, that's a good very compilation.

While Liferay has not been designed for banking apps, we still have to be aware about it.

Most of those vulnerabilities can be covered by liferay integrators, but certainly it would be better to have proper settings within the default configuration.

Unfortunately, there are additional vulnerabilities that can allow discovery of system internals, may cause serious slowness and massive failures within the system if applied by malicious unauthenticated user.

Jorge, as liferay portal has moved into corporate environments and this trend has significantly accelerated this year (at least in Australia), may be it is a good time to review all security aspects again.

[Maulin Rathod, geändert vor 14 Jahren.]

Hi Vinod/Victor,

Are you using any tool for security scan?

We are using liferay 5.1.2. All above mentioned securies issues are still there or it is resolved in liferay 5.1.2? Any Idea?

[Victor Zorin, geändert vor 14 Jahren.]

Are you using any tool for security scan?

Note that I posted before is based on analytical assessment.

is resolved in liferay 5.1.2

Level of security hardening is always driven by customer environment requirements. For social sites out-of-box will do the job. For stricter environments, an entire set of unused services and portlets must be removed, all configuration files are to be changed.

General opinion: number of out-of-box portlets and services is just too large to have a final say. So producing a well-secured system is always going to be a custom job. Development of portlets with security conscience is an additional piece of art to master.

[Auditya manikanta Vadrevu, geändert vor 14 Jahren.]

hi victor,

how to solve the clear text password issue in the request. ?

An attacker can steal the clear text password of an application user.

I have enabled burp proxy and switched on the intercept while signing in to portal. It showed clear text username and password. How to encrypt the password in the request. Is there any property i must enable or manually we must write the program . I have tried with liferay site itself, even it is showing clear text password. how to overcome this any idea ..?


Thanks in advance,
V.Auditya

[Olaf Kock, geändert vor 14 Jahren.]

The only reasonable solution against intercepted passwords in the request is https. There is no solution without https. Even if somebody implemented public key encryption in javascript, you could intercept the javascript and replace it with bogus encryption if no https was involved.

It's a problem if liferay stores a password in clear text in the database. I've not seen that to be the case.

Additionally you could implement some kind of one-time passwords, so that they are at least not reproducible. There could be a third party tool available... (OpenSSO? Your LDAP?)

Or: Somebody prove me wrong...

[Auditya manikanta Vadrevu, geändert vor 14 Jahren.]

hi Olaf Kock ,

there is a property to ensure users login with https. i have enabled it.

company.security.auth.requires.https=true

I have restarted and again tried to intercept while logging in to portal. (iam using LDAP and CAS for authentication)

Same Result : I have got clear text username and password in burp proxy.

[Alex Rud, geändert vor 14 Jahren.]

In additions to the previously mentioned issues, an check for sql injection should be performed. Hibernate protects against this sort of thing but if there's any kind of custom sql string assembly it could be a problem.

[Kaon . Z, geändert vor 14 Jahren.]

vinod goyal:

Hi ,

We perform a testing on Liferay 5.0.1 and found the various security issues. These issues are as follows:

1. CROSS SITE SCRIPTING

Exp. Various scripts are executed in the URL/FORM parameter when the page reloads.

Impact: XSS vulnerability allows malicious user to execute scripts to capture user identity information or to inject HTML Code into the vulnerable application.

2. INJECTION FLAWS

Exp. The response contained a new header, inserted by the successful HTTP Response Splitting attack

Impact: When user input is embedded as-is in HTTP response headers, it may be possible for an attacker to terminate the "current" response (by injecting the necessary HTTP response headers), and then to add his/her own additional complete HTTP response. The attacker can then orchestrate the traffic in such a way that when an additional request is sent it appears to generate the additional response.

3. BROKEN AUTHENTICATION AND SESSION MANAGEMENT

Exp. A http parameter was found to hold a URL value and cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.

Impact: It may be possible to persuade a naive user to supply sensitive information such as username, password etc

4. Authentication Brute Force Attack

Exp. application does not limit the number of false login requests in the Authentication page

Impact: The attacker may eventually discover the password for a particular user account by (brute forcing) sending a large number of possible passwords

5. INFORMATION LEAKAGE AND IMPROPER ERROR HANDLING [

5.1 Insecure HTTP Methods Enabled (Count-1)

Exp. Insecure HTTP methods like GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS are enabled.

Impact: The OPTIONS HTTP method provides a malicious user with the most direct and effective way to figure out which HTTP methods are supported by the web server. The PUT & DELETE methods enable an attacker to remotely add web pages or delete files, thus enabling website defacement. The TRACE method allows any malicious user, to trace the content that is received at the other end of the request, to make use of it to perform specific attacks on the application.

5.2 Application Exceptions Revealed

Exp. It is possible to gather error information in application

Impact: Information obtained from the errors displayed may be used by the attacker to perform specific application attacks directly on the web application.

5.3 Web server Banner Information revealed

Exp. web server banner revealed sensitive server related information as follows : "Server: Apache/2.2.3 (Red Hat) Liferay-Portal: Liferay
Portal 5.1.2 (Calvin / Build 5102 / October 3, 2008)"

Impact: Server specific information revealed by web server might facilitate the attacker to perform version specific attacks on the UBMI application server.

6. INSECURE COMMUNICATIONS

Exp. Failure to encrypt sensitive communications - Sensitive information such as password was sent unencrypted to the server and/or back to the user.

Impact: Any information sent to the server can be used for malicious purposes.

7. FAILURE TO RESTRICT URL ACCESS

Exp. Link for uploading images to the server is not restricted

Impact: It is possible for any user to upload images to the UBMI server without authentication.

8. Forceful Browsing

Exp. It is possible for any unauthorized user to view the admin page by forcibly browsing to the page

Impact: If successfully exploited, this would lead an unauthorized user to perform admin functions.

Please update if you have come across similar issues and If Liferay has any fix for any of these.

Regards,

Vinod

Nice Post~~

Liferay should spend more effort on this since it intends to be enterprise....

By the way, have Liferay been certificated by any third-party security audit?

[MICHAIL MOUDATSOS, geändert vor 12 Jahren.]

Kaon . Z:

By the way, have Liferay been certificated by any third-party security audit?

Someone should answer this. Also, are the mentioned vulnerabilities present in 6.0.6 and 6.1?

[Guenter Baumgart, geändert vor 12 Jahren.]

Kaon . Z:

Someone should answer this. Also, are the mentioned vulnerabilities present in 6.0.6 and 6.1?

Hi,
given the dimensions of the initial post we also would like to know about 6.1. Some of the points can be fixed on our side but for larger components we would need to spend 1-3 weeks of pretty hard and expensive men work.

Could somebody from Liferay give here a short statement ?
In our case we would like to know only which components can be considered as "secure" or vice versa, which components shouldn't be used in production? We were almost about to use the shopping and forum built-in but now we are very nervous about.

[David H Nebinger, geändert vor 12 Jahren.]

MICHAIL MOUDATSOS:

Are the mentioned vulnerabilities present in 6.0.6 and 6.1?

Liferay CE is not guaranteed to be secure. Never has been, and probably never will be. As a community edition, it is meant to provide an entry point to Liferay, an introduction to the Liferay platform, and is not intended to be a foundation for enterprise deployments.

If security is your concern, you really should be looking at Liferay EE. As you will see through the description of Liferay EE, they follow the OWASP top 10. EE goes through extensive security testing where CE does not.

[Guenter Baumgart, geändert vor 12 Jahren.]

hi,
we already asked for the price but we never got a response.

Short question, is the shopping component secured in the EE? We are already looking at an implementation of Broadleaf into Liferay but of course we prefer built-in components.

Thanks again
G