A Flaw Worth Fixing? How We Tested (And Stopped) the Facebook Notes Flaw


Recently, independent researcher Chaman Thapa published a report on an attack scenario showing how someone could use Facebook Notes to DDoS any website. When Facebook and DDoS enter the conversation, news spreads quickly and questions emerge. What is the flaw? How serious is it? Who or what can be affected? The Radware Emergency Response Team (ERT) decided to take a look at the Facebook Notes attack type by testing it in our lab. First, here’s some background:

What is ‘Facebook Notes’:

Facebook Notes is an application offered by Facebook. It allows users to use tags


and link to external images and files. When Notes are published, any viewer of the Note will see the image via Facebook fetching the image and then presenting it the user.

How can it be used for Attacks?

During Thapa’s research, he noticed an anomaly. Facebook will not fetch the same image twice. This led him to suggest the following attack:

If even a single bogus parameter is changed in the URL that is requested, Facebook will fetch it again-and-again. An attacker can create a Note like this:

* From “A Programmer’s Blog”

The Note tags above would cause Facebook to make 1,000 HTTP request to the targeted site. If an attacker were to open even 10 pages per second, that Note could potentially generate an average of 10,000 HTTP requests to the targeted site. Using large images or even PDF files can amplify this effect so that essentially, one small request could potentially pull several megabytes of traffic back. In one test, Thapa was able to pull 900Mbps from a website – large enough to kill either the web server or the Internet pipe of many websites.

If a malicious user were to craft a Note with numerous links, many HTTP requests and the resulting increase in traffic sent to a victim’s site may cause an outage.

What is Facebook Doing about This?

Thapa shared his research with Facebook’s Bug Bounty program and was told they “appreciated this report and discussed it at some length.” Ultimately, however the social media giant decided against making changes to “avoid disrupting intended and desirable functions.”

Here’s Our Test:

Radware ERT researched how difficult it is to stop such an attack yet found that even the most basic Web Challenge mitigation technique could block it. Web Challenge, a common technology to block HTTP application attacks, is available in many security systems today.

Here’s how the block works:

When under attack the security system challenges all HTTP requests and sends them back a 302 Redirect reply. Included in this reply is a special cookie. Legitimate users using normal browsers will honor the redirect command, even without the user necessarily noticing. They will send the HTTP cookie back, which will authenticate them to the security system and allow them to go on to their desired sever. Attackers using scripts, however, which generate dozens of request per second, do not wait for the response. They are unable to process the 302 redirect or to save the cookie.


Although Facebook reviewed Thapa’s research and decided against a fix, it is interesting that this flaw could potentially generate up to 900 Mbps of web traffic from a social media site that is accessible to 728 million daily users. Granted – there are other “go-to” attack vectors that cyber-attackers could use at their disposal for DDoS, but this flaw piqued our interest due to Facebook’s worldwide presence.

Like this article? Receive similar articles by subscribing to our blog today!


  1. “If an attacker were to open even 10 pages per second, that Note could potentially generate an average of 10,000 HTTP requests to the targeted site.”

    Do you mean if an attacker we’re able to create 10 Notes per second? Aren’t the URLs fetched by Facebook at Note creation? I’m confused as to how an attacker can generate more HTTP requests beyond just the URLs they paste into the Note. Is there some amplification happening here?

  2. So your basically blocking Facebook? what kind of “mitigation” is that? besides, who cares about outbound? just use rate limiting for Christ’s sake.

  3. It actually isn’t outbound, it is inbound. FB sends HTTP requests to your server. Rate limiting impacts legitimate traffic not to mention responses would be far bigger than HTTP requests, so ability to block those HTTP requests is much better choice of action.

  4. This is a bad fix. Do you want a 302 for every content on your CDN ?
    “When under attack..”
    So you know in your labs that you’re being attacked. How do people running websites know if each request is legitimate or not ? Rate limiting is the answer

  5. Regarding the question about Detection, then yes the blog focus on the Mitigation part. Detection is not discussed, but there are several detection technologies that can trigger the mitigation such as detecting the HTTP transaction have increased or detecting that outbound traffic had increased in proportion to the requests.
    Rate-limit is considered much less surgical mitigation technique than web challenges and has inherent false-positive effect.
    Yes, when the mitigation is in place it will block Facebook request to the site, but the it is very safe to assume that under such an attack the victim will prefer to block Facebook for the attack duration than to lose the site.

    • So why challenge? Just block facebook during DDoS (though imho it’s a very bad fix). The challenge is useless here because it proves nothing.

    • Rate limit is less surgical?!? You are blocking facebook! Why not limit facebook only? Because your’e lacking the feature?

    • Unless someone is using services that will detect these attacks and block it on the fly without having false-positive effect, the damage with this kind of attack will already be done. What you talk about is “detect” high traffic, not “malicious” traffic.
      “Attackers using scripts, however, which generate dozens of request per second, do not wait for the response. They are unable to process the 302 redirect or to save the cookie. ”
      Why are they unable ? This is not true. For amplified attacks, they can and will use cookies and your method will fail.

  6. Clearing cache is crucial for effective functioning of Magento modules – After installing modules individually,
     Magento coders ensure that the cache is completely cleared and the session is reset by logging in and logging out of the Magento administrator panel.
    A lot of offshore centers provide exceedingly flexible and exceptional
    services, which do not burn a hole in the
    pocket of the corporate house, and yet enable to them register a unique presence in the web world.
    Our professional Magento Developers are passionate about developing Magento websites and its striking design that help you in build
    a successful ecommerce store that increases your online sell and ahead you from the market


Please enter your comment!
Please enter your name here