Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

3/29/2007
07:45 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Killer Combo: XSS + CSRF

Researchers mix cross-site scripting and cross-site request forgery together in a deadly cocktail

Researchers will demonstrate a lethal combination of cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks tomorrow at Black Hat Europe in Amsterdam.

The goal is to show the danger of the two pervasive Web vulnerabilities teaming up in an attack. "Cross-site scripting has its strengths and limitations. Cross-site request forgery has its strengths and limitations," says Billy Rios, senior researcher with Ernst & Young's advanced security center. "We will show how when you use the two in combination, you can use the strength of one to overcome the weakness of the other." (See CSRF Vulnerability: A 'Sleeping Giant'.)

XSS bugs are rampant in Websites and have been well-documented by hacker groups such as sla.ckers.org. And CSRF, which is a bit more complex to execute in an attack, is just as pervasive, Rios says, but has mostly been ignored so far because there's no real solution for detecting it. "We're in a stage now where people know about it, but are ignoring it, and that's kind of dangerous." CSRF hasn't hit the front burner yet mainly because it's tougher to detect than XSS and other threats, he adds. (See Hackers Reveal Vulnerable Websites.)

But Rios and colleague Raghav Dube, also a senior researcher with E&Y's advanced security center, consider any type of one-two punch attack exploiting multiple client-side Web vulnerabilities -- not just XSS and CSRF -- a serious problem. "Any kind of client-side vulnerability that's leveraged by using it in combination with another one expands your arsenal [as an attacker]. It's more dangerous," Rios says, and the next big thing security experts need to be on the lookout for.

The researchers will release the client-side JavaScript code they developed for the two attacks, including the payloads. "We're not going to release our XSS proxy," Rios says. "We want people to understand you don't need my tool to pull this off. You have all you need already on the Net to do those attacks."

In the first attack, the researchers show how to take over a user's account via XSS and use that browser to attack another Website. In the demo, the user first visits a social networking/blogging site, which is easier to get XSS-infected due to the ability to upload content, post messages/comments, etc. But the attacker's real target is a large credit union site. It works like this: Once the user falls victim to the XSS exploit on the social networking site, XSS is used to take over the victim's browser, Rios says.

"In the grand scheme, we don't actually care about the social networking site," he says. The attack then uses CSRF to link between the social networking site and the credit union site, he says. "Once we control the victim's session with the social networking site, we can force and control a session between the browser and the credit union site."

From there, the attacker can attack the credit union site. "We will go into techniques for attacking the credit union, but it's actually the victim that is doing it" unknowingly with their browser, he says. And the victim would have little or no clue the attack was underway, Rios adds. The advantage of combining XSS and CSRF here is that it lets the browser move to different Web domains, not just a single one.

The second attack demo shows how XSS and CSRF can be used to do damage to an internal corporate network. "Because we're using the victim's browser to do these attacks, we can take advantage of all the privileges and trust established by their browser," Rios says. "Because it's inside the corporate LAN, we can drive it to attack other machines inside the firewall. The age-old moat-around-the-internal-net model is basically thrown out the door because our staging point is inside the internal net."

The victim's browser then attacks a network management system on his internal network. CSRF is then able to get information on the internal network. And if the attack is caught or traced back, it's on the victimized user's doorstep. "If they kick down the victim's door, the evidence is on that machine. It was [his] browser that did the attack," and he didn't even know it, Rios says.

And XSS lets CSRF work more two-way instead of just one way: "CSRF alone is a one-way deal," Rios says. "You do the attack and hope it executed. The only way to verify it is through a secondary channel. With XSS, you can verify the CSRF went through, and you get instant feedback."

The demos show targeted attacks on a specific user, but Rios says it would be easy to automate it across multiple users. "We're trying to show that this doesn't require that much sophistication to exploit."

— Kelly Jackson Higgins, Senior Editor, Dark Reading

  • Ernst & Young International
  • Black Hat Inc. Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio
     

    Recommended Reading:

    Comment  | 
    Print  | 
    More Insights
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    Brother Printer Support
    50%
    50%
    Brother Printer Support,
    User Rank: Guru
    7/3/2018 | 8:03:39 PM
    AOL Support
    I have shared the support bright, there are technical any issues there then go to support for help, but I need to what kind of support, Which supports give the proper resolution. Then My friend suggest that , I thought its helpful AOL Support
    COVID-19: Latest Security News & Commentary
    Dark Reading Staff 5/28/2020
    Stay-at-Home Orders Coincide With Massive DNS Surge
    Robert Lemos, Contributing Writer,  5/27/2020
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon Contest
    Write a Caption, Win a Starbucks Card! Click Here
    Latest Comment: Can you smell me now?
    Current Issue
    How Cybersecurity Incident Response Programs Work (and Why Some Don't)
    This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
    Flash Poll
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2020-11844
    PUBLISHED: 2020-05-29
    There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
    CVE-2020-6937
    PUBLISHED: 2020-05-29
    A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
    CVE-2020-7648
    PUBLISHED: 2020-05-29
    All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
    CVE-2020-7650
    PUBLISHED: 2020-05-29
    All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
    CVE-2020-7654
    PUBLISHED: 2020-05-29
    All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.