Protecting Your Website: CloudFlare or Incapsula?
I get this question a lot whenever I talk with clients or give presentations, “How do I prevent my website from being hacked?”. Many actually confuse the service we offer at Sucuri as a preventive service. Good thing we don’t advertise preventive services.
That’s right, our service sits in the detection and remediation realm. By the nature of what we do there are preventive components that we implement, but our service has always been about detection, and more importantly remediating the mess. For any InfoSec professional working in the security domain you can understand this approach; you have long learned that prevention is ideal but detection is key and that’s based around the understanding that prevention, like detection, will never be a 100% solution.
That being said, I came across a recent report by Philip Tibom of Sweden titled Incapsula vs. CloudFlare (PDF Download). It was published October 15th, 2012 and in it he chronicles his experiences with both platforms over the last 6 months. If you’re not familiar with either then you’re really not that concerned with your security posture, and that’s ok of course but unfortunate none the less.
I would argue that CloudFlare is likely winning the popular vote, entering into the most partnerships and making the most noise, but Incapsula is perhaps the most effective based on the report. The two services are software as a service (SaaS) based solutions targeting the preventive side of the house; yes these would be the first-line of defense solutions so many folks are looking for.
They fall into the latest category of Web Application Firewalls (WAF) coming to the market designed to address the pandemic problem that is website attacks and web malware distribution. They are designed to slow down, if not completely, prevent the attacks from ever occurring; in essence doing away with your need for a detection / remediation service, right?
If that were only the case…
THE REPORT
The report is much more in depth than I will outline here; here is a complete list of the questions he sought to answer:
- DNS changes – How does it affect your security?
- SQL injection protection – How well does it work?
- XSS (Cross Site Scripting) protection – How well does it work?
- Remote File Inclusion protection – How well does it work?
- OWASP Top 10 Vulnerabilities – Are they protected?
- SSL – Does it work? Is it easy?
- Control panel – How does it help you protect your site?
- Spam bot / Bad bot protection – Is it effective?
- PCI Compliance – Does the WAF meet the requirements?
- DDoS protection – Is it included?
Here though I was specifically interested in three areas:
- SQL injection attacks
- Cross Site Scripting (XSS) attacks
- Remote File Inclusion Attacks (RFI)
I chose these three areas as they make up a very high majority of the attack vectors attributed with most websites, specifically those built on Content Management Systems (CMS) like WordPress, Joomla and Drupal.
SQL Injection Attack
A quick definition of this attack:
A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.
Source: OWASP
His test scenario included 30 different SQLi variations against a personal site in which he purposely introduced SQLi vulnerabilities. He actually made a very good video, which I watched, and which I recommend you watch as well. He goes through the process of enabling and disabling both services and showing you sample attacks so that you can see it in practice. Some of his points around the result pages are pretty insignificant, with exception to one:
Once we have filled in those two words and requested access, we are free to post any SQLinjection we like without getting stopped!
What he is referring to is the splash page that CloudFlare presents the browser after an attack. On it they provide you a CAPTCHA to verify you are human, once that is filled out, all subsequent attempts are allowed through unchallenged. If this is in fact true that is very dangerous. I have not tested this but do plan to in the coming months.
In terms of the results: Incapsula blocked all 30 attacks and CloudFlare blocked 1
Both tests were done on the same application; the only difference was when the application was turned on and off.
Cross Site Scripting (XSS)
A quick definition of this attack:
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
Source: OWASP
This is by far probably one of the more prevalent attack vectors today, impacting many of today’s websites. In short its the ability to pass actions to your browser that allow an attacker to make use of browser technologies like JavaScript, ActiveX and AJAX; allowing actions to take place without you ever knowing. These can be very dangerous, they can be used for a variety of actions like drive-by-download attempts, session / cookie hijacking and key / screen logging.
Similar to the SQLi scenario, he used his personal site with built in vulnerabilities. He also made use of 15 different XSS test cases leveraging the well known XSS Filter Evasion Cheat Sheet by OWASP.
In terms of the results: Incapsula blocked all 12 attacks and CloudFlare blocked 0
Remote File Inclusion (RFI) Attack
A quick definition of this attack:
Remote File Include (RFI) is an attack technique used to exploit “dynamic file include” mechanisms in web applications. When web applications take user input (URL, parameter value, etc.) and pass them into file include commands, the web application might be tricked into including remote files with malicious code.
If you’re trying to get your head around this type of attack try thinking about last year’s TimThumb outbreak. This was the type of attack conducted against the file. Unfortunately this attack is more common than many realize and can be found in a number of other files.
In his example he pulled the example for his test right off wikipedia. Amazing how readily available some data is. The rest of the test scenario in this case was not as comprehensive as his XSS and SQLi tests; this one only included one scenario.
In terms of the results: Incapsula blocked 0 and CloudFlare blocked 0
FINAL THOUGHTS
While Incapsula failed a few tests in the XSS attacks and failed the one RFI, based on his study, Incapsula appears to be the ideal solution for your everyday website owner looking for a preventive service. Understand that I have not tested these platforms for myself and am simply paraphrasing the findings in the a 23 page report.
The report is well laid out and looking past the grammatical / a structural issue provides exceptional content that has not been provided elsewhere. It’s also important to note that the study only looked at the security components of both services. It did not attempt, or intend, to compare any of the various other features both providers offer.
As it stands right now, based on what I have read and the sound judgment offered in the report, if someone were to ask me the same question today, I would say that Incapsula is the ideal solution from a preventive measure.