Link: Spring-MVC Cross-Site Scripting Vulnerabilities

by Johannes Brodwall Posted on March 6, 2007

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.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Links, Software Development. Bookmark the permalink.
  • Anders Furseth

    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.

  • Mr. Senseless Talker

    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)

  • Anders Furseth

    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.

  • Mr. Senseless Talker

    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)

  • 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.

  • 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.

  • Kukenspeil

    “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!

  • Kukenspeil

    “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!