I have lost track of the number of times I have had this conversation with security groups over the years. I even had one report once that claimed that Liferay was executing shell commands that were passed to it. Obviously it doesn't lol -- but to make the point, I bet the client the value of my next invoice and asked them to submit the command rm -rf / 
My own experiences are the same as David -- false positives. Most notably, most of these tools assume that if a 200 OK Response comes back from a request then it automatically means that it did whatever was submitted. When I dig into these scenarios (now I have never committed to reviewing 1700 of them, but I have done as many as 100+ -- which was really boring), the results showed that the urls were returning a 200 OK and that the actual result was the Portal Error page -- meaning Liferay detected an invalid request and didn't do anything. I'm willing to bet that most of your results fall into this scenario.You could submit something to Fortify, but I doubt anything would change. These are false positives in Liferay, in other tools they may be deemed as perfectly valid results. Ideally there would be a way to mark a test as a false positive to have it eliminated from future runs -- but outside of that, I think you have to eye ball them. That's what I always end up doing.
My own experiences are the same as David -- false positives. Most notably, most of these tools assume that if a 200 OK Response comes back from a request then it automatically means that it did whatever was submitted. When I dig into these scenarios (now I have never committed to reviewing 1700 of them, but I have done as many as 100+ -- which was really boring), the results showed that the urls were returning a 200 OK and that the actual result was the Portal Error page -- meaning Liferay detected an invalid request and didn't do anything. I'm willing to bet that most of your results fall into this scenario.You could submit something to Fortify, but I doubt anything would change. These are false positives in Liferay, in other tools they may be deemed as perfectly valid results. Ideally there would be a way to mark a test as a false positive to have it eliminated from future runs -- but outside of that, I think you have to eye ball them. That's what I always end up doing.
Thanks David for your response . They are valid points and I believe I should be able to use for the fall positive challenge. The task is how to proceed whether to challenge or implement. It will take a considerable amount of work to add the frame ancestor headers thats if the challenge was denied. For worst case, if the challenge was denied and implementation need to take place, is it possible to add the headers in the apache web server or portal-ext.properties file?
. They are valid points and I believe I should be able to use for the fall positive challenge. The task is how to proceed whether to challenge or implement. It will take a considerable amount of work to add the frame ancestor headers thats if the challenge was denied. For worst case, if the challenge was denied and implementation need to take place, is it possible to add the headers in the apache web server or portal-ext.properties file?
Andrew Jardine:
I have lost track of the number of times I have had this conversation with security groups over the years. I even had one report once that claimed that Liferay was executing shell commands that were passed to it. Obviously it doesn't lol -- but to make the point, I bet the client the value of my next invoice and asked them to submit the command rm -rf /
Andrew, the repsponse gets back is 200 but I dont see portal error page but just the home page. Is this a vulnerability if there is no portal error page because a false positive I am using is that there was no action taken from Liferay as it accept request and discard the repsone by presenting the ehome page. Can you advise?
Another clickjacking item is whenever a .js is reference in the URL doing a GET it returns the entire javascript page for exmaple http://localhost:8080/o/frontend-js-metal-web-1.0.7/metal-dom/src/events.jso/frontend-js-metal-web-1.0.7/metal-dom/src/events.js. Is this a vulnerable issue?
Also, do you or anyone know how to Remove X-Powered-By and its value from the reponse hearder in Liferay ?
Andrew, the repsponse gets back is 200 but I dont see portal error page but just the home page. Is this a vulnerability if there is no portal error page because a false positive I am using is that there was no action taken from Liferay as it accept request and discard the repsone by presenting the ehome page. Can you advise?
I have seen this, but honestly I can't recall the exact use case for when it happens. Can you give me one of the urls that you are trying when it returns your to the home page? I am wondering if perhaps it is a private page you are trying to hit without an authenticated session so it're rerouting you to the default public page (homepage).
Another clickjacking item is whenever a .js is reference in the URL doing a GET it returns the entire javascript page for exmaple http://localhost:8080/o/frontend-js-metal-web-1.0.7/metal-dom/src/events.jso/frontend-js-metal-web-1.0.7/metal-dom/src/events.js. Is this a vulnerable issue?
I'm not clear on the problem with the JS. The response from the server contains references to JS files (like just about every web application these days .. css files too for that matter). The browser makes separate requests to download those files so that it can use them in the rendered page. /o is just the filter that liferay uses to understand the the request is looking for a resource.
Also, do you or anyone know how to Remove X-Powered-By and its value from the reponse hearder in Liferay ?
I've never looked because, quite honestly, I've never cared that it was there
. I'll bet if you search the portal source though you'll find it.
Andrew Jardine:
Andrew, the repsponse gets back is 200 but I dont see portal error page but just the home page. Is this a vulnerability if there is no portal error page because a false positive I am using is that there was no action taken from Liferay as it accept request and discard the repsone by presenting the ehome page. Can you advise?
I have seen this, but honestly I can't recall the exact use case for when it happens. Can you give me one of the urls that you are trying when it returns your to the home page? I am wondering if perhaps it is a private page you are trying to hit without an authenticated session so it're rerouting you to the default public page (homepage).Another clickjacking item is whenever a .js is reference in the URL doing a GET it returns the entire javascript page for exmaple http://localhost:8080/o/frontend-js-metal-web-1.0.7/metal-dom/src/events.jso/frontend-js-metal-web-1.0.7/metal-dom/src/events.js. Is this a vulnerable issue?
I'm not clear on the problem with the JS. The response from the server contains references to JS files (like just about every web application these days .. css files too for that matter). The browser makes separate requests to download those files so that it can use them in the rendered page. /o is just the filter that liferay uses to understand the the request is looking for a resource.
Also, do you or anyone know how to Remove X-Powered-By and its value from the reponse hearder in Liferay ?
I've never looked because, quite honestly, I've never cared that it was there
Sample Attack payload. I don't believe its a private page.
http://localhost:8080/c/portal/render_portlet?p_l_id=20150&p_p_id=com_liferay_site_navigation_menu_web_portlet_SiteNavigationMenuPortlet&p_p_lifecycle=0%0d%0aSPIHeader:%20SPIValue&p_t_lifecycle=0&p_p_state=normal&p_p_mode=view&p_p_col_id=null&p_p_col_pos=null&p_p_col_count=null&p_p_static=1&p_p_isolated=1¤tURL=%2Fportal%2Frender_portlet&settingsScope=portletInstance
The only way to know for sure for that one is to look up the p_l_id value in the Layout table in the database. Regardless, all that URL is doing is asking Liferay to render the navigation portlet that is associated with that page. I'd hardly call that an attack -- or if it is "an attack", it's a pretty pathetic one
Andrew Jardine:
Andrew, the repsponse gets back is 200 but I dont see portal error page but just the home page. Is this a vulnerability if there is no portal error page because a false positive I am using is that there was no action taken from Liferay as it accept request and discard the repsone by presenting the ehome page. Can you advise?
I have seen this, but honestly I can't recall the exact use case for when it happens. Can you give me one of the urls that you are trying when it returns your to the home page? I am wondering if perhaps it is a private page you are trying to hit without an authenticated session so it're rerouting you to the default public page (homepage).Another clickjacking item is whenever a .js is reference in the URL doing a GET it returns the entire javascript page for exmaple http://localhost:8080/o/frontend-js-metal-web-1.0.7/metal-dom/src/events.jso/frontend-js-metal-web-1.0.7/metal-dom/src/events.js. Is this a vulnerable issue?
I'm not clear on the problem with the JS. The response from the server contains references to JS files (like just about every web application these days .. css files too for that matter). The browser makes separate requests to download those files so that it can use them in the rendered page. /o is just the filter that liferay uses to understand the the request is looking for a resource.
Also, do you or anyone know how to Remove X-Powered-By and its value from the reponse hearder in Liferay ?
I've never looked because, quite honestly, I've never cared that it was there
I was able to removed the X-Powered by removing its entry from standalone.xml jboss/wildfly10.0
Community
Company
Feedback