You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the LocaleChangeInterceptor does not an escaping of the value from the request. This can lead to a XSS issue if you use the standard implementation and you call:
In this case some component (which one??) of the framework will write a http-response header for the Content-language and write the provided header instead (Content-length here 30 byte) with content (here a javascript) before of the real content of the site!
I discovered the very same issue today...It's not exactly true that this bug leads to XSS vulnerabilities. However, since the interceptor alters the locale in the HTTP response header without any validation whatsoever your code may suffer from XSS vulnerabilities when you render the locale in the HTML code.
In my JSP I have <html lang="${pageContext.response.locale.language}">. So, this bug does affect me.
At first I wasn't convinced that it's the most sensible approach to propose a fix for LocaleChangeInterceptor. One could simply escape (or handle it differently) the locale value when it's actually used. However, since the LocaleChangeInterceptor may alter an otherwise perfectly legit locale in the HTTP response header I believe it makes sense to fix it in the interceptor.
I don't think the interceptor should escape the parameter value, though. What's the actual benefit of an escaped locale string? Since, the string does not represent a valid locale anyway in this case it might only break things in other corners.
IMO the interceptor should validate the parameter and only process it when it contains a legit value. Otherwise it should simply ignore it.
-> added a patch (no Java file but a diff)
Sandro Ruch opened SPR-7779 and commented
The current implementation of the LocaleChangeInterceptor does not an escaping of the value from the request. This can lead to a XSS issue if you use the standard implementation and you call:
http://someUrl?locale=%0D%0AContent-length:30%0D%0A%0D%0A%3Cscript%3Ealert%28123%29%3C/script%3E
In this case some component (which one??) of the framework will write a http-response header for the Content-language and write the provided header instead (Content-length here 30 byte) with content (here a javascript) before of the real content of the site!
Please find a patched version as attachment.
Affects: 3.0.5
Attachments:
Issue Links:
Referenced from: commits 7af890c, f4a2282
3 votes, 5 watchers
The text was updated successfully, but these errors were encountered: