Sverre Huseby examines some security issues with Spring-MVC. As it turns out, the Spring JSP form-taglib provide no HTML-escaping by default, making it very easy to get Cross-Site Scripting vulnerabilities included in the code. The article comes complete with a standalone application that illustrates the problem.
Link: Spring-MVC Cross-Site Scripting Vulnerabilities
As interesting as this is, Sverre has yet to report the issues to the Spring-MVC team, making this premature disclosure unethical at best.
Poppycock, Anders :-). A security advisory with a workaround should always be welcome. Security is always better when information is widely disseminated.
But the issue should be reported to the Spring team *as well*. And I trust Sverre is one step ahead of us on this.
I'm glad you have trust in Sverre (he's the best), but I know for a fact it has yet to be reported. The issue here is timing. Giving the maintainer of the affected product some time to respond to the issue before disclosing the advisory is common practise among most sane people. For future reference; see http://www.wiretrip.net/rfp/policy.html for an excellent guideline for handling the interaction between a security researchers and software maintainers. Given the fact that Spring-MVC is being widely used among financial applications, I'm left to hope that the readers of your blog are merely people with good intentions. Hopefully we'll all be able to fetch Spring-MVC 2.0.3 from our local mirror very soon.
Hi, Anders. If this was a bona-fide bug, I'd agree with you. It's a request to “default to safe”, which is something different. In this case, the onus to fix is on the billions of software developers using Spring-MVC. But the Spring team could ease their pain. (And I'm not going to be drawn into a discussion about the bestitude of Sverre)
As interesting as this is, Sverre has yet to report the issues to the Spring-MVC team, making this premature disclosure unethical at best.
Poppycock, Anders :-). A security advisory with a workaround should always be welcome. Security is always better when information is widely disseminated.
But the issue should be reported to the Spring team *as well*. And I trust Sverre is one step ahead of us on this.
I’m glad you have trust in Sverre (he’s the best), but I know for a fact it has yet to be reported. The issue here is timing. Giving the maintainer of the affected product some time to respond to the issue before disclosing the advisory is common practise among most sane people. For future reference; see http://www.wiretrip.net/rfp/policy.html for an excellent guideline for handling the interaction between a security researchers and software maintainers. Given the fact that Spring-MVC is being widely used among financial applications, I’m left to hope that the readers of your blog are merely people with good intentions. Hopefully we’ll all be able to fetch Spring-MVC 2.0.3 from our local mirror very soon.
Hi, Anders. If this was a bona-fide bug, I’d agree with you. It’s a request to “default to safe”, which is something different. In this case, the onus to fix is on the billions of software developers using Spring-MVC. But the Spring team could ease their pain. (And I’m not going to be drawn into a discussion about the bestitude of Sverre)
Jeez, guys, let's be friends. After all, it's just bits and bytes.
And I've been informed that the only _bug_ I point at is being fixed in the next 2.0.x release. Not because of me, but because someone reported it the day after I started mailing my thoughts to some friends.
The design flaw may be (maybe) addressed in the next 2.x.y release.
Jeez, guys, let’s be friends. After all, it’s just bits and bytes.
And I’ve been informed that the only _bug_ I point at is being fixed in the next 2.0.x release. Not because of me, but because someone reported it the day after I started mailing my thoughts to some friends.
The design flaw may be (maybe) addressed in the next 2.x.y release.
“I have a dream that one day the Spring Framework will add “secure by
default” to its list of fundamental design principles.”
Well if that happened, then Sverre could well be out of a lot of consulting revenue!
“I have a dream that one day the Spring Framework will add “secure by
default” to its list of fundamental design principles.”
Well if that happened, then Sverre could well be out of a lot of consulting revenue!