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

Already on GitHub? Sign in to your account

SEC-812: Framework can help protect against XSS attacks on login page by escaping stored last username #1073

spring-issuemaster opened this Issue May 2, 2008 · 8 comments


None yet
1 participant

Chris Castaldo(Migrated from SEC-812) said:

During a penetration test the username field in j_acegi_security_check was found to be vulnerable to XSS. Additionally the XSS seems to preform a pseudo SQL attack with the following instructions, note this can only be reproduced with FireFox.

Open FireFox and visit http:/host/j_acegi_security_check?j_username=%27%3Cscript%3Ealert%28%27xss%27%29%3C%2Fscript%3E&j_password=d&login=Login

A session error should occur.

Kill or end the FireFox process.

Reopen FireFox with the “Restore Session” option.

User data should now be dumped in the browser.

Luke Taylor said:

Thanks for the report. We’ll look into it. Could you possibly expand a bit on what kind of setup you were running against? I can see how the XSS can occur without validation of the entered username, but some more info would be useful.

Luke Taylor said:

The username parameter issue isn’t a problem unless someone re-renders the value into a web page without escaping (which they will get automatically if using JSTL’s tag, for example). So it could be argued that it’s not the framework’s responsibility to sanitize the submitted value, but the application developer’s. The client may not even be a browser. However since most applications are unlikely to have a requirement to allow HTML characters in usernames we could consider sanitizing the value to prevent this kind of thing completely. Again, it would be useful to know how the login page was being rendered in the application you were testing.

We should also check that the sample applications don’t suffer from this to illustrate best practice and raise it as a potential issue in the docs somewhere.

Chris Castaldo said:

I am collecting more information from the user. I will have your questions answered hopefully by Wednesday.

Chris Castaldo said:

Spring Version – 1.2.6

Acegi Version – 0.9.0

The Acegi Version has been extended to incorporate DB based

Let me know if I can provide anymore details.

Luke Taylor said:

Thanks. I guess the question is really how they are rendering their login page – they must be resinserting the username into the page after a failed login and it’s at that point that they should escape the value to replace the <>"’ character with HTML entities.

Luke Taylor said:

Do you have any more information on how they are rendering the page?

I have updated the code to escape the username value which is stored in the session, so in future this should prevent users from inadvertently running into this problem. I don’t think it’s a bug in the framework though.

Luke Taylor said:

Changed title to reflect that this isn’t a bug in Spring Security but rather an issue with rendering the application’s login page with a previously entered username.

Luke Taylor said:

The previous username is now stored with XML escaping enabled.

@spring-issuemaster spring-issuemaster added this to the 2.0.2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment