XSF & XSS: Double your pleasure, double your fun

If you've read this blog, or those of my peers, you're likely quite familiar with cross-site scripting, and the problems associated with open redirect vulnerabilities. A vulnerability you may be less familiar with is cross-site framing, which largely couples the best of both above-mentioned vulnerabilities.
What then, if there's a cross-site framing vulnerability coupled with cross-site scripting in the content offered by the frame? All sorts of problems come to mind: phishing, malware, credential theft; all arguably twice removed from the attacker's source, tucked away in the context of two victim sites.
First, I'll discuss the original XSS issue that led to this finding.
Recently, I was investigating a flawed parameter in Openhire, a career posting vendor used by major companies like Crate&Barrel, Eileen Fisher, Enterprise, Benjamin Moore, Scottrade, and Getty Images.
Most of these sites simply link to the Openhire offering that hosts job postings on their behalf which, in turn, has been crafted to look like the referring site.
As an example, here's Scottrade's employment page hosted by Openhire.

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?version=1&company_id=15624

Standard stuff, looks nicely like the Scottrade site, so everything's cool, right?
Wrong? What if someone hosting a service on your behalf suffers a security gap?
You're only as strong as your weakest link!
Here's the posting for an Application Security Engineer (funny, eh?) at Scottrade as hosted on their behalf by Openhire:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=976367&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters%3B%3B%3BInformation%20Technology%3B%3B%3BSecurity&startflag=3&CFID=66851845&CFTOKEN=29a95-d12594d4-47d9-49e8-9067-1091bdf68e80

Now here the same job posting spewing massive cookie data:

http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3

Screen shot offered below, as the code above will likely be repaired very soon by Openhire. I notified them this past Thursday.



It's bad enough when there's an application security hole in code someone else is hosting on your behalf, but what if your method of displaying said code is also at risk? Enter the Getty Images Jobs page.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=careeropps&startflag=0&company_id=15531&version=2&CFID=12265212&CFTOKEN=60213778

Watch what happens when you pull the Openhire code. Can you say self-replicating frame loop from hell (in Firefox)? Trust me your browser will crash if you leave this running too long. This will likely be fixed soon, so if the URL doesn't work, the screen shot exemplifies the issue.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html



What if, instead of Openhire's Getty Images page, or nothing at all (which obviously creates its own issue), we drop in an arbitrary URL?
Yep, you guessed it.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://www.xssed.com/news/26/Cross-site_framed/



Now, bringing it all home for double the pleasure, double the fun, what if we coupled the original Openhire cross-site scripting vuln with Getty Images' cross-site frame vuln?

It hurts twice as much, in my book.

http://www.gettyimagesjobs.com/gettyImagesJobsDisplay.html?http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=130527&company_id=15624&version=1&source=ONLINE&JobOwner=%22%3E%3CSCRIPT%3Ealert(document.cookie)%3C/SCRIPT%3E&level=levelid3&levelid3=18247&parent=St.%20Louis%20Corporate%20Headquarters;;;Information%20Technology;;;Security&startflag=3



The lessons learned:
1) Ensure your partners are writing secure code on you behalf.
2) Ensure that the code you utilize to incorporate said partner's code is also well written. ;-)

Double the headache, double the dumb.

del.icio.us | digg