XSS on request parameter on submitted form

[Brijesh Desai, geändert vor 8 Jahren.]

Hello All,

We have created custom registration portlet on which there are fields like firstname, last name.

We are doing security testing by interceptor Burp suite tool where we can change the parameter value of firstname to "securityuser <script>alert("Script Executed")</script>".

Here on controller it receives first name value as "securityuser <script>alert("Script Executed")</script>" and saves the same value on DB table since the request parameter value is changed by Burp suite, on the browser we just typed value as securityuser.

Here How can I filter or prevent values such as <script>alert("Script Executed")</script>.

Regards,
Brijesh

[Samuel Kong, geändert vor 8 Jahren.]

You just need to escape the user's input before displaying in the browser. Liferay portal provides several methods for escaping. See http://docs.liferay.com/portal/6.2/javadocs/com/liferay/portal/kernel/util/HtmlUtil.html

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

Adding to Samuel's answer: You probably want to save the full name, as given, to the database. The reason why you can't escape it to &lt;script&gt;... is that you don't know where you'll use it: In a text-only email, <script> does not do any harm. When sent to the printer: Same. When saved in the database, you rather want to use proper escaping for SQL-related exploits.

There's proper escaping for all uses of the values, and the easiest way to deal with it is to save data in its natural form and use proper escaping for the environment you're using it in.

Filtering (disallowing) "<" in names won't help you much as any of the other environments will demand other filters. And don't go for ASCII only without annoying people with names written in foreign alphabets, or just slightly modified ASCII characters (e.g. "ä")

[Brijesh Desai, geändert vor 8 Jahren.]

Thanks Samuel / Olaf for the reply.

Here challenge for me is we have many form parameters and multiple forms as well.

Using HtmlUtil.escape I believe is not good practice to do go ahead.

What do you suggest on using filter for this ?

regards,
Brijesh

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

It's good practice to save the original content and escape during output, according to the channel that you're rendering to (HTML, EMail, etc - see my last statement).

If you're doing this through HTMLUtil or any other means it up to you. My recommendation has not changed. Welcome to the web: If you have more than one field of user-generated data, you'll have to escape more than one field of user generated data. If you have hundreds of fields, escape all of them.

[Dushyant Tusharkant Dave, geändert vor 8 Jahren.]

Hi,

I'm facing the same issue. I'm using Liferay 6.1 EE.
I tried to find out on Google if suppose this scenario in pure JAVA, I found that I need to create RequestWrapper class which extends HttpServlerRequest. Therefore I used this concept. I have created one filter & in the filter, I'm passing the serveletRequest to this RequestWrapper class & I passed that requestWrapper object to filterChain.doFilter.
In this class, I have overridden getParameter(String arg0) & getParameterValues(String parameter). After putting all these things, I print those values on console & I'm getting those values as well but the chellenge for me is why these overridden methods didn't get applied on those parameter values though I've implemented the escape plan for those values.
Therefore, I again debug all the Liferay classes & found that, it might be possible because of a PortletRequest instead of a HttpServeletRequest which Liferay uses to get parameter values.
Afterwards, I again created on PortletRequestWrapper class so if I could manage by overriding LiferayPortletRequest methods but still I'm bit confused & stucked where to go because still all these legitimates are not working for me at all.

Am I on the right way or not? Please if anyone can give a solution/a suggestion.
Any help would be appreciated.

Regards.

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

IMHO you're on the wrong track. You should escape on the response side, not on the request side - see my arguments above.

[Dushyant Tusharkant Dave, geändert vor 8 Jahren.]

Hey Olaf,
Thanks for the humble suggestion

You should escape on the response side, not on the request side

Can you please elaborate your concern?
Is your concern suggest to override any response methods as same as I did for request side or something else?

This is because I know how to escape but I didn't get where to escape.

Regards

[Kartik Sharma, geändert vor 8 Jahren.]

while displaying back the user input value in JSP use JSTL ${fn:escapeXml(var)}"

[Dushyant Tusharkant Dave, geändert vor 8 Jahren.]

Hi Kartik,

We are not using JSTL tags & currently there is no possibility to incorporate a sudden big change.
But I'm expecting a generic solution if you can suggest.

Regards

[Kartik Sharma, geändert vor 8 Jahren.]

We are not using JSTL tags & currently there is no possibility to incorporate a sudden big change.

Are you not using JSP? how you display the value?. Using JSTL tag is simplest way, In JSP you can use the JSTL <c:out> tag or fn:escapeXml function for this.
you do not need to escape it in servlet/filter/javacode/database/whatever. You're only unnecessarily overcomplicating things. Just escape it during display. That's all.

[Arun R S Chandran, geändert vor 8 Jahren.]

Dushyant Tusharkant Dave:

Hey Olaf,
Thanks for the humble suggestion

You should escape on the response side, not on the request side

Can you please elaborate your concern?
Is your concern suggest to override any response methods as same as I did for request side or something else?

This is because I know how to escape but I didn't get where to escape.

Regards

When you want to display or render the content to somewhere in your user interface. Just before you do that rendering you can do an HTMLescape.

If you don't want to include that kind of Java code into your JSP, you can escape the data in your render method or before the render method.

Only thing we want to keep the exact user data in the persistence. It will be helpful for some future data analysis.

Thanks,
R S

[Dushyant Tusharkant Dave, geändert vor 8 Jahren.]

Hi Arun,

Thanks for your suggestion
As per your suggest, it requires so much effort. I'm at the stage when we are planning to release & I believe this will not make it.
There should be a generic solution intended to accomplish all the requirement, e.g., a filter configuration incorporation. If you can suggest something like that, please do share your opinion.

Regards

[Arun R S Chandran, geändert vor 8 Jahren.]

Dushyant Tusharkant Dave:

Hi Arun,

Thanks for your suggestion
As per your suggest, it requires so much effort. I'm at the stage when we are planning to release & I believe this will not make it.
There should be a generic solution intended to accomplish all the requirement, e.g., a filter configuration incorporation. If you can suggest something like that, please do share your opinion.

Regards

I didn't get

Dushyant Tusharkant Dave:

There should be a generic solution intended to accomplish all the requirement, e.g., a filter configuration incorporation.

Don't you feel escaping data is not a generic solution for the problem?

What I understand from your point is that, you have some sort of specif system design and you are already ready with your application. But you may need to put a lot of effort to change your code to escape the HTML chars.

If that is the case, you may proceed with the implementation which is already done. From the previous post I understand that you had done the html escape when you get data from the request. If you don't want to use the user submitted data for any future analysis, this will be fine, but not the best practice.

[Arun R S Chandran, geändert vor 8 Jahren.]

Brijesh Desai:

Thanks Samuel / Olaf for the reply.

Here challenge for me is we have many form parameters and multiple forms as well.

Using HtmlUtil.escape I believe is not good practice to do go ahead.

What do you suggest on using filter for this ?

regards,
Brijesh

As Olaf mentioned, this is a Best practice, when you store the original data and while providing your response, just escape the data. This way you can use the orginal data, from the database for any future analysis. You can read more about handling XSS using Java on Owasp. https://www.owasp.org/index.php/CategoryWASP_Java_Project

Thanks,
Arun

[Jaya Sharma, geändert vor 6 Jahren.]

hi,

will it work with liferay 4.2.2?.thanks

[Samuel Kong, geändert vor 6 Jahren.]

The product is stable..we are not suppose to upgrade it. Any alternate?

The alternative to upgrading is to patch the software on your own. You'll need to take a look at how the fix was done in 7.0 and try to figure out how to apply that fix to 4.2. As you mentioned some of the fixes in 7.0 uses code/class that do not even exists in 4.2. Class have been renamed/moved. Implementations have changed. It's not going to be easy. And you'll not only have to do this for this issue but all the other known issues. You have a lot of work ahead of you if you want to go with the alternative. Sorry.

will it work with liferay 4.2.2?.thanks

Upgrading to 4.2.2 probably won't solve your specific issue. But 4.2.2 will have some fixes that 4.2.0 doesn't have. So upgrading to 4.2.2 is better than nothing. But you shouldn't feel safe just because you upgraded to 4.2.2.

[Dushyant Tusharkant Dave, geändert vor 8 Jahren.]

Hi Brijesh,

I got the solution how to prevent this XSS Attack.
I created one filter hook & in that doFilter() method, I'm iterating all the request-parameter-map-values & escaping it using HtmlUtil.escape().
By comparing request-parameter-map-values old value with the new escaped value, I implemented the logic what to do if any XSS Attack.

This is how I made the configuration:

/**
* @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
*/
@SuppressWarnings("unchecked")
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

Map<String, String[]> paramMap = servletRequest.getParameterMap();
Set<Entry<String, String[]>> paramMapSet = paramMap.entrySet();
String[] values;
boolean xssAttack = false;

for (Entry<String, String[]> entry : paramMapSet) {
values = (String[])entry.getValue();
for(String value : values){

String xssPreventedValue = value;
xssPreventedValue= HtmlUtil.escape(xssPreventedValue);

if(!value.equals(xssPreventedValue)){
xssAttack = true;
}
}
}

if(xssAttack){
_log.error(xssAttackLog);
HttpSession session =((HttpServletRequest)servletRequest).getSession();
if (session != null)
session.invalidate();

response.sendRedirect(homepageURL);
_log.info(sessionInvalidated);
} else{
filterChain.doFilter(servletRequest, response);
}
}

private static final String xssAttackLog = "Cause of XSS Attack. User is trying to malicious data which is prohibited.";

private static final String sessionInvalidated = "Session invalidated";

private static final String homepageURL = "/web/guest/home";

This code will make a logout and do homepage redirect if XSS Attack is there.

Regards.

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

Dushyant Tusharkant Dave:

This code will make a logout and do homepage redirect if XSS Attack is there.

IMHO this solution is totally wrong. E.g. assume I'm a book author, writing a book about secure Web Development. One of the titles I could think of would be

<script>alert("Avoid XSS");</script>

Now this book would not sell at all if it was sold through your system, because nobody could enter it into the inventory system. Instead, you should save the name like I entered it, but properly escape it when it's being rendered on HTML pages. However, don't HTML-escape it, when it's used in plain text mail or printed.

Assume the publisher for this book is "Olaf & Others Ltd." - HTML-escaped this would be "Olaf &amp; Others Ltd." - a company name that would annoy me in your system because nobody can enter it: They'd be accused of attacking the system and logged out.

This is the wrong behaviour for a web application. Good if you're happy with it (at the moment), but anybody else who finds this solution and thinks it's a good idea to use your code should be warned that it is not a good idea.

[Dushyant Tusharkant Dave, geändert vor 8 Jahren.]

Hi Olaf,

Thanks for your humble suggestion. Considered marked. Indeed I honestly say that it didn't even worked for me.
I reverted my changes & now I'm using the same approach as I've explained above. Therefore I'm using RequestWrapper Class to prevent XSS Attack. There I've replaced string with this,

value.replaceAll("(?i)<script.*?>.*?</script.*?>", "")
.replaceAll("<script>(.*?)</script>", "")
.replaceAll("(?i)<.*?javascript:.*?>.*?</.*?>", "")
.replaceAll("(?i)<.*?\\s+on.*?/>", "")
.replaceAll("(?i)<.*?\\s+on.*?>", "")
.replaceAll("(?i)<.*?\\s+on.*?>.*?</.*?>", "")
.replaceAll("vbscript", "")
.replaceAll("encode", "")
.replaceAll("decode", "")
.replaceAll("src[\r\n]*=[\r\n]*\\\'(.*?)\\\'", "")
.replaceAll("src[\r\n]*=[\r\n]*\\\"(.*?)\\\"", "")
.replaceAll("</script>", "")
.replaceAll("<script(.*?)>", "")
.replaceAll("eval\\((.*?)\\)", "")
.replaceAll("expression\\((.*?)\\)", "");

I'm using this in getParameter(), getParameterValues & getHeader() methods to replace parameter values.

I've referred this link:

https://www.liferay.com/community/forums/-/message_boards/message/12934491

It's working for me with all expectations & I did check using BurpSuite as well.
I know you suggested me to go with the Response side but I didn't find any solution & I thought better to keep this on.

Regards.

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

Dushyant Tusharkant Dave:

I know you suggested me to go with the Response side but I didn't find any solution & I thought better to keep this on.

Well, escaping on the response side basically means that you'll have to escape everything that you display in HTML. There are multiple options for this: HtmlUtil.escape(text) is one. Various Liferay Tags have an escaped attribute that you can set to true.

The version you now decided for still is on the wrong side (as you state), and still is totally wrong. I didn't say it that clearly in the thread you link. Proper escaping needs to be done on the delivery side. You never know what you find in the database. And you never know what channel you'll need to output this content to. It might not be HTML!

[Tomas Polesovsky, geändert vor 8 Jahren.]

Hi Dushyant,

you can trust Olaf.

Blacklists simply don't work. There's always somebody that can find a way through it, correct escaping of output is the only safe way I'm aware of.

There's also a CWE issue assigned to this wrong practice: https://cwe.mitre.org/data/definitions/692.html

----

In short, some of the vectors that will bypass your protection

for vulnerability in HTML body:

<scrip<scrip<script>t&gt;t&gt;t&gt;T&gt;alert(1)</scrip<scrip<script>

<a href="javascript:alert(1)">click me</a>

in the form input values:

'" onfocus=alert(1) autofocus=1 

in JavaScript blocks - variable assignments, this usually works:

'+alert(1)+'"+alert(2)+"

Best,

-- tom +

[Jaya Sharma, geändert vor 6 Jahren.]

Hello,
we are working on liferay 4.2. i am getting these parameters in url 'p_p_state, p_p_mode,p_p_state. which is causing XSS issues in security scan.

Here How can I filter or prevent values such asscript>pholcidCallback(25176099973)</script>.

i tried 'Dushyant Tusharkant Dave's solution. but i don't have HtmlUtil class.

Kindly help .

thank you

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

Jaya Sharma:

we are working on liferay 4.2. i am getting these parameters in url 'p_p_state, p_p_mode,p_p_state. which is causing XSS issues in security scan.

You're running software that wasn't updated since 2007. XSS is your least problem. You should really consider to upgrade

[Jaya Sharma, geändert vor 6 Jahren.]

The product is stable..we are not suppose to upgrade it. Any alternate?

[Alberto Chaparro, geändert vor 6 Jahren.]

Hi Jaya,

Sure, you can use Liferay 4.2 but it is going to be difficult that someone can give you a solution for your issue since it's not supported anymore. What you can do it is try to solve it by your own checking the fixes applied to similar problems in newest versions of LIferay.

I hope it helps.

Regards.

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

Jaya Sharma:

The product is stable..we are not suppose to upgrade it. Any alternate?

Well, you just found one security issue, and it happened to be XSS. I'm not aware of anything that is contained in your installation, but there have been security issues in later releases (read: after 2007) that haven't even been inspected in the light of 4.2 because the version already wasn't supported any more. That's why I'm saying that this particular XSS is your least worry. It just happens to be the only worry you know about.

Not to mention that you're probably running on an old and unsupported application server, JVM and database.

[Meena Peddi, geändert vor 4 Jahren.]

we are working on liferay 6.2 and observed xss attack with  p_auth,p_p_lifecycle parameters.Can someone please help how can I fix this.

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

Meena Peddiwe are working on liferay 6.2 and observed xss attack with  p_auth,p_p_lifecycle parameters.Can someone please help how can I fix this.

Answered in your other post. Please don't crosspost without linking all of your postings.