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.
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.
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.
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.
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.
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.
The previous username is now stored with XML escaping enabled.