The analysis of this vulnerability started with the provided commit acc477143b50de2138854548bc5bad06677e708a. The commit shows a change in the JSP file modules/apps/expando/expando-web/src/main/resources/META-INF/resources/edit/expando.jsp, where HtmlUtil.escape is added to sanitize the output of LanguageUtil.format. The variable being escaped is propertyDisplayType, which is derived from the displayType request parameter mentioned in the vulnerability description.
The root cause of the vulnerability is a reflected Cross-Site Scripting (XSS) issue. The displayType parameter is not sanitized before being rendered in the HTML response, allowing an attacker to inject arbitrary JavaScript.
Based on this, two vulnerable functions were identified:
-
org.apache.jsp.edit.expando_jsp._jspService: This is the most direct location of the vulnerability. JSP files are compiled into Java Servlets, and the _jspService method contains the code from the JSP. The unescaped rendering of the propertyDisplayType parameter happens within this method. This function would certainly appear in a runtime profile during exploitation.
-
com.liferay.expando.web.portlet.ExpandoPortlet.render: The vulnerability description points to the ExpandoPortlet via the namespaced parameter _com_liferay_expando_web_portlet_ExpandoPortlet_displayType. In a typical Liferay MVC architecture, the portlet's render method is the entry point that handles the request and forwards it to the JSP for rendering. Therefore, this function is the starting point of the vulnerable code path and would also be present in a stack trace during exploitation.
By identifying both the entry point in the application logic (ExpandoPortlet.render) and the exact location of the vulnerable code execution (_jspService of the compiled JSP), we get a comprehensive view of the functions involved in this vulnerability.