The Vulnerability of Digital Library Services to Pornographic Hijacking and Identity Theft Scams
Cross-site Scripting Attacks via Linking are a Disaster We Can Avoid
About a year ago, as part of my work on NISO's OpenURL Standardization Committee, I started worrying about how features in the emerging OpenURL standard might be exploited in an attack that would destabilize the Internet. My worries were partly fueled by the observation that Microsoft's software monoculture had created a fertile breeding ground for viruses and worms- both enabled by the standardization of software. I started imagining what would happen if the standard we were working on was implemented as pervasively as we hope it will be. I fancifully began to wonder: what would happen if our standard had a bug in it that one day caused the Internet to crash?
My mind reaches peak creativity when a direct challenge presents itself. Could I possibly imagine a way to cause mischief using the OpenURL standard? I quickly thought of a few scenarios where our beloved OpenURL Standard could, in obscure and remote circumstances, "go kaboom". The engineering side of my brain quickly thought of some plausible defenses, but I scared myself enough that I decided to call in a reinforcement. One of my college classmates happens to be a computer virus researcher at IBM Labs, perhaps one of the top people in the world. I gave him a call and explained to him my worries about the Standard. To make a long story short, he basically told me that the things I was worried about were pretty minor, given the other problems that were out there. It was sort of like being told not to worry about ferocious bears while going on a hike in the woods because all the people you're hiking with are a whole lot slower than you are. I felt a bit better, and work on the standard proceeded.
But in the same conversation, my friend said that, given what OpenURL link servers do, I should be very worried about "Cross-Site Scripting Attacks". I googled this term, read the description, and thought to myself, "oh that's interesting. Rather far-fetched, though."
That night, as I was laying in bed, I suddenly figured out what a "cross-site scripting attack" was. Have you ever jumped out of bed and said "OH S***!"?
The first thing I did was to look though all our code for vulnerabilities, of which I found many. It was easy to fix. The next thing I did was to look at the competition...
Over the past year, I have been on a little crusade to plug the Cross-Site Scripting Attack vulnerability where ever I find it. Whenever I examine the linking of a site, I test for Cross-Site Scripting Attack vulnerability. I have found it in about two thirds of the large publisher sites that I have examined. I have found the vulnerability in 6 different OpenURL linking server systems. I have not yet seen the problem in an OPAC system. (Although there was one OPAC that I kept crashing) In each case I have informed key contacts about the vulnerability. You learn a great deal about organizations this way. The offending web sites are either fixed immediately (with in a week) or they are never fixed.
In January, the OpenURL Committee finally sent a Standards Document to the NISO membership for ballot. In the end we put some notes about security into an "Implementation Guidelines" Document which was not part of the Standard. I wanted this to be in the standard, but I was outvoted. Committees are all about compromise. Here is the relevant excerpt from these Implementation Guidelines:
By-Reference Transport, either of ContextObject or entities within ContextObjects, introduces certain security risks. In particular, the ability for a request to specify arbitrary network-locations from which the Resolver is expected to fetch documents raises particular concerns.
OpenURL 1.0 implementers must be aware of several possible attacks that could compromise security.
- When an OpenURL Resolver has privileged access to resources, such as IP-authenticated licensed content, it is possible that an attacker could hijack this access by sending OpenURL with by-reference URLs. Resolvers should take care not to expose licensed metadata by returning the resulting metadata to unprivileged users.
- In a cross-site scripting attack, crafted data values are used to insert code into a webpage seen by a user. This code can be used to insert foreign content or steal personal data, such as authentication data or passwords from a user's "cookie" file.
- In a vortex or maelstrom attack, By-Reference URLs and the data they return might be constructed in such a way that an endless series of requests is generated. Where possible, Resolvers may need to recognize protocols and services which that might generate such endless loops and prevent their propagation.
This is pretty tame and opaque language. Let me elaborate a bit in hopes that I can properly put the "fear of God" into OpenURL Implementers. Here are a few examples of things the Cross Site Scripting Vulnerability could conceivably lead to:
- An attacker could repoint a large fraction of a user's links to porn sites, thus earning him income from the traffic he drives.
- An attacker could hijack the reputation of a large publisher by asking a user for personal and financial information (for document delivery, etc.). This is also known as a "phishing" attack. An attacker could mimic an authentication dialog, and steal the user's password. Depending on the nature of the attacked website, the attacker could ask for a user's credit card information. The attacker could then use the information to charge the users credit card.
- An attacker could fool a user into downloading and installing spyware, adware, or spamware.
Now all these things could and do happen without the Cross-Site Scripting Attack bug. But imagine if you were the victim of such a scam, and you were able to determine that the scam took advantage of a software bug "owned" by a Billion dollar organization. I think my attorney might want to talk with you.
Perhaps the most pernicious thing about this bug is that in certain library configurations, the presence of the bug in one service might allow an attacker to compromise an unrelated service which is otherwise secure.
Now before everyone goes to turn off their e-journals and their link server, let me tell you the good news. First of all, we know of no cross-site scripting attacks on library oriented resources that have occurred "in the wild". Second, many of the publishers and developers that I have worked with over the last year have fixed this vulnerability in their software. And finally, the vulnerability, once identified, is usually very simple to repair. There is no cause for alarm, but we really do need to fix the bugs before they become a problem.
At this point I'd like to ask the community for help. I have written a much more detailed and explicit description of how the vulnerability manifests itself, how the vulnerability can be detected, exploited and eliminated. The page includes tools that can be used to probe suspect sites. Due to the sensitivity of this information, that page is only available on a password protected site. I will be happy to make that page available to interested parties on the presumption that they will use the information responsibly. (email me at eric@openly.com) Another good resource is here
In summary, I would like to ask the digital library development community to
- remove the Cross-Site Scripting Attack vulnerability from their own applications
- identify other services that are vulnerable
- pressure owners of vulnerable services to fix them
- remove vulnerable services from situations where they could seriously compromise others
Eric Hellman
