Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerability in LocaleChangeInterceptor [SPR-7779] #12435

Closed
spring-projects-issues opened this issue Dec 1, 2010 · 2 comments
Closed

Vulnerability in LocaleChangeInterceptor [SPR-7779] #12435

spring-projects-issues opened this issue Dec 1, 2010 · 2 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Dec 1, 2010

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

@spring-projects-issues
Copy link
Collaborator Author

Marcel Stör commented

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)

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

LocaleChangeInterceptor validates locale values (through StringUtils.parseLocaleString) in order to prevent an XSS vulnerability now.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants