2016 has been a hot year for hackers and this trend shows no sign of stopping. Major hacks and the breached data released as a result over the course of 2016 have led to millions in losses for the organizations who failed in establishing proper web application security.
The now-infamous Yahoo hack cast some shades of doubt on how Verizon was going to proceed with its $4.8 billion acquisition while Iceland’s prime minister Sigmundur Davíð Gunnlaugsson resigned as part of the fallout from the Panama Papers.
According to the Ponemon Institute’s 2015 Cost of Cyber Crime Study, the cost of cybercrime is increasing year after year, a cost that Cybersecurity Ventures predicts will increase to $6 trillion annually by 2021. Not only are the instances of attacks increasing, but also the costs associated with remediation as the average time to contain a cyber attack was 31 days at an average cost of $639,462. Ponemon’s latest cost of cyber crime study also shows that out of the all the attacks that threaten organizations’ data, reputation and revenue, malicious insiders, denial of service, and web-based attacks combine to account for more than 55% of all cyber crime costs.
With a focus on web-based attacks, here are some web application security lessons that we can take from some vulnerabilities and exploits we’ve seen come to light over the course of 2016.
Web Application Security Lessons from Notable 2016 Hacks and Breaches
Panama Papers: A Complete Failure of CMS Security
The Attack: Vulnerable Content Management System (CMS) Plugins
While the hack against Mossack-Fonseca that resulted the Panama Papers actually happened in 2015, this incident only made headlines in spring 2016 due to the sheer amount of data (more than 11.5 million documents) that a consortium of journalists needed to sift through prior to reporting on it. Contained within the leaks was all the information needed to gain an understanding of how wealthy individuals, politicians and celebrities were able to store their money offshore in shell companies in ways that often crossed the line in terms of both legality and ethics.
For a shadowy organization that specialized in secrecy, Mossack-Fonseca’s information security was nearly non-existent. Not only did the company fail to encrypt their emails, the way that they used various content management system (CMS) elements was highly irresponsible.
An out-of-date version for their image slider plugin on WordPress that contained an exploit that, according to the CEO of the company behind the popular WordPress security plugin WordFence, contained a vulnerability that was, “trivially easy to exploit.” In addition to this problematic WordPress plugin there was also Mossack-Fonseca’s three-year-old version of Drupal which also contained several known vulnerabilities. Both of these outdated versions had fixes that could have been implemented by Mossack-Fonseca’s systems administrators, however they were not.
IT consultant Jason Bloomberg notes that, “outdated versions of software that organizations haven’t properly patched is the most common cybersecurity vulnerability today,” and this lack of some of the most basic security precautions led to the world’s largest data-leak.
- Always ensure that all CMS platforms, themes and plugins are regularly updated and patched
- Stay up-to-date on current CMS security threats through Drupal, WordPress, Joomla and other hosting services’ threat databases
- Scan any plugins using a security scanner prior to implementing them and activating them on your website or blog
- The Worrying Security State of CMS Platforms
- WordPress Vulnerability Database
- Drupal Security Advisories Page
PayPal’s Profile Picture Vulnerability
The Attack: Cross-Site Request Forgery
Background: French software engineer and bug-bounty hobbyist Florian Courtial
found a cross-site request forgery (CSRF) vulnerability in one of PayPal’s newer sites, PayPal.me. PayPal.me is a faster, easier way to get paid through PayPal where users are able to share their personal PayPal.me/YourName link with others in order to receive quick payments directly.
While snooping around PayPal in search of vulnerabilities, Courtial discovered that he was able to remove or edit the CSRF token and in turn update a user’s PayPal profile picture.
On his blog, Courtial explains how he managed to accomplish this: “I decided to also check on paypal.com without much hope. I found out that when removing or editing the CSRF token (http header in that case) there was no error and the profile picture was updated. I tried a real world scenario using the basic HTML page.
Thanks to some missing headers such as X-Frame-Options: DENY it was possible to transparently submit the form without redirection.
The result was an error 500 due to a missing header
X-Requested-With:XMLHttpRequest. Even if this header is not a good protection against CSRF, it is hard to exploit (besides some genius). Fortunately, despite the error, the picture was still updated.”
- Unique CSRF tokens – The user should get a random CSRF token every time he logs into the web application. In all subsequent requests, this token should be passed and validated in the server. This effectively cripples the malicious URLs as they cannot be authenticated by the server, which checks for the unique CSRF tokens.
- Tokens per request – The aforementioned CSRF tokens are usually given out per session, but can be given out for each request separately for added protection.
- Timing out sessions – Making sure the session times out after a short period of time reduces the time-frame that the victim has to perform the attack.
- The Ultimate Guide to Understanding & Preventing CSRF
- Troy Hunt’s OWASP Top 10 for .NET Developers: CSRF
- Coding Horror’s ‘Preventing CSRF and XSRF Vulnerabilities’
- OWASP CSRFGuard Project for Java
Exploit The “Hack” That Never Happened – Russian Foreign Ministry Falls Victim to XSS Embarrassment
The Attack: Cross-Site Scripting (XSS)
While it’s obvious that most successful web application attacks bring both a financial and reputational loss to the hacked organization, there are attacks that merely bring embarrassment to the insecure victim of the hack. This is the case in an unusual attack that by an American “patriotic hacker” against the Russian foreign ministry website. According to Wikipedia, patriotic hacking is “a term for computer hacking or system cracking in which citizens or supporters of a country, traditionally industrialized Western countries but increasingly developing countries, attempt to perpetrate attacks on, or block attacks by, perceived enemies of the state.”
In this exploit where the hack had much more “bark than bite,” an American patriotic hacker known as The Jester exploited a cross-site scripting (XSS) vulnerability found in the Russian Foreign Ministry website by adding a detailed, and at times vulgar, message to their site that looked like the site was hacked. For many, this seemed as the latest salvo amid growing cyber tensions between the United States and Russia. Rather than the massive blow to the cyber flagship of the Russian government that it appeared to be, The Jester was able to have his message, which warned Russia to cease their cyber attacks against the United States, displayed for all visitors without damaging or breaching the site itself.
Rather than the “earth-shattering mega-hack” that brought the Russian Foreign Ministry’s website to its knees, what The Jester did was more of a nuisance. Instead of hacking the actual site, The Jester drove traffic from a tweet to a new site that he created that contained XSS code with his message to Russia. Once someone clicked through to that website, they were then redirected to the Russian Foreign Ministry website which was then populated with The Jester’s message for Russia. The attack, or spoofing, of what seemed to be the Russian website only took place on the visitor’s devices rather than the actual official website. The severity of this attack fooled many, including briefly stunning the Russian government-funded media outlet Russia Today.
- Never insert untrusted data except in allowed locations.
- HTML escape before inserting data into HTML element content.
- Attribute escape before inserting untrusted data into HTML common attributes.
- CSS escape and strictly validate before inserting untrusted data into HTML style property values (while trying to insert untrusted data into stylesheets or style tags).
- URL escape before inserting untrusted data into HTML URL parameter values.
- Sanitize HTML markup with a library designed for the job (HTML Sanitizer).
- Prevent DOM-based XSS vulnerabilities
- OWASP’s DOM based XSS Prevention Cheat Sheet
- XSS: The Definitive Guide to Cross-Site Scripting Prevention
Checkmarx scans over 20 programming languages, and their most popular frameworks, for security, compliance and quality issues including cross-site scripting, cross-site request forgery and more. Learn more in our vulerability knowledge base.