Summary
In a lot of security audits one thing that usually comes up is not to use untrusted data without validation/sanitation. Looking at UsernamePasswordAuthenticationFilter, the username which is retrieved as a web parameter (form post) isn't validated until it hits a AuthenticationProvider, or UserDetailsService in case of a DaoAuthenticationProvider. This feels late, it might not be clear in several places that a username has had no validation, for example when reporting a error about a user not found, doesn't this make html injection more likely?
I might be missing the point here, in which case I'd love a counter argument :)
Actual Behavior
No username validation in UsernamePasswordAuthenticationFilter, or any of the default components.
Expected Behavior
Some validation, or support for validation of username as early as possible: in UsernamePasswordAuthenticationFilter.
Version
3.2.6
Comment From: rwinch
You cannot really perform validation without knowing more about the system and the correct place to do this is in the UserDetailsService. Note that forbidding html characters may appear to help if your application is written in HTML, but won't help in a REST + Rich client scenario. It gets even more complicated when you run into applications that support more than one type of client where characters that are safe for one client are not for another. The takeaway here is that encoding is the proper way to protect against injection attacks.