Thought leadership. threat analysis, news and alerts.
3 Most Common Web Application Security Vulnerabilities
Almost all organizations today have an online presence, mostly in the form of an official website. While these websites open a window of opportunities for organizations, these same websites are at times a bane to organizations as these are becoming attractive targets for cyber attackers.
What Are Web Application Security Vulnerabilities?
One of the ways by which cyber attackers wreak havoc on corporate websites is by exploiting the security vulnerabilities in web applications.
Web applications, also known as web apps, refer to software programs that run in a web browser. A web application can be as simple as a contact form on a website or a content management system like WordPress. Web application security vulnerabilities, meanwhile, refers to system flaw or security weakness in a web application.
Web applications are gateways to a trove of data that cyber attackers find attractive and easy to steal. Every time website visitors sign up for an account, enter their credentials or make a purchase via an official corporate website, all this data, including personally identifiable information, is stored on a server that sits behind that web application. Exploiting a security vulnerability in a web application allows attackers to access the data stored on that server.
Imperva, in its “State of Web Application Vulnerabilities in 2018”, reported that the overall number of new web application vulnerabilities in 2018 increased by 23%, that is, 17,308 web application vulnerabilities, compared to 2017 with only 14,082 web application vulnerabilities.
Most Common Web Application Security Vulnerabilities
Here are the 3 most common security vulnerabilities affecting web applications:
Based on Imperva’s data, the number one web application vulnerability in 2018 was injection, representing 19% of the web application vulnerabilities last year. In an injection attack, an attacker inserts or injects code into the original code of a web application, which alters the course of execution of the web app.
According to Imperva, the preferred method of attackers last year to inject code into web applications was remote command execution (RCE) with 1,980 vulnerabilities.
Remote command execution allows an attacker to remotely take over the server that sits behind a web application by injecting an arbitrary malicious code on the web app. The Equifax data breach that exposed highly sensitive data of millions of U.S. customers, as well as thousands of U.K. and Canadian consumers, is an example of a cyberattack that used the injection method, in particular, remote command execution.
Attackers gained access to the data of millions of Equifax’ customers by exploiting the vulnerability designated as CVE-2017-5638in the web application used by the company. At the time of the attack, Equifax then used an outdated Apache Struts, a popular open source framework for creating enterprise-grade web applications.
Despite the advisory from the Apache Software Foundation, the organization that oversees leading open source projects, including Apache Struts, to update the software to the latest version, Equifax failed to do so, leading the attackers to breach the sensitive data of millions of the company’s customers.
On March 7, 2017, the Apache Software Foundation issued a patch or security update for CVE-2017-5638 vulnerability. On May 13, 2017, just a few days after the CVE-2017-5638 patch was released, attackers started their 76-day long cyberattack on Equifax, this according to the findings of the U.S. House Oversight Committee.
2. Cross-Site Scripting
The second most common web application vulnerability is cross-site scripting. According to Imperva, cross-site scripting ranked as the second most common vulnerability in 2018, representing 14% of the web application vulnerabilities last year.
Cross-site scripting, also known as XSS, is a type of injection in which malicious code is inserted into a vulnerable web application. Unlike injection in general, cross-site scripting particularly targets web visitors.
In a cross-site scripting attack scenario, an attacker, for instance, embeds an HTML tag in an e-commerce website’s comments section, making the embedded tag a permanent fixture of a webpage, causing the browser to read the embedded tag together with the rest of the original code every time the page is opened, regardless of the fact that some site visitors don’t scroll down to the comments section.
The injected HTML tag in the comments section could activate a file, which is hosted on another site, allowing the attacker to steal visitors’ session cookies – information that web visitors have inputted into the site. With the stolen session cookies of site visitors, attackers could gain access to the visitors’ personal information and credit card data.
3. Vulnerabilities in Content Management Systems
Imperva’s State of Web Application Vulnerabilities in 2018 also showed attackers are focusing their attention to vulnerabilities in content management systems, in particular, WordPress.
Attackers are focusing their attention on WordPress as this content management system powers nearly one-third of the world’s website. Data from W3Techsshowed that as of late December, last year, WordPress usage account for 32.9% of the world’s websites, followed by Joomla and Drupal.
According to Imperva, the number of WordPress vulnerabilities increased in 2018 despite the slowed growth in new plugins. Imperva registered 542 WordPress vulnerabilities in 2018, the highest among the content management systems. The WordPressofficial website, meanwhile, reported that only 1,914 or 3% from the total 55,271 plugins were added in 2018.
Ninety-eight percent of WordPress vulnerabilities are related to plugins, Imperva reported. Plugins expand the features and functionalities of a website. WordPress plugins are, however, prone to vulnerabilities as with this content management system (being an open source software), anyone can create a plugin and publish it without security auditing to ensure that the plugins adhere to minimum security standards.
Web Application Attack Prevention
A web application firewall (WAF) is one of the best cybersecurity solutions that your organization can employ against web application vulnerabilities.
Trust the experienced team that protects hundreds of sites and applications. Protect your web application within 10-minutes and keep cybercriminals at bay. Get started today!
Why Your Organization Should Replace All TLS Certificates Issued by Symantec
October 2018 is a crucial month for anyone owning a website as two of the world’s biggest browsers, Chrome and Firefox, will “distrust” TLS certificates issued by Symantec.
What Is a TLS Certificate?
TLS stands for Transport Layer Security. This technology is meant to keep the internet connection secure by encrypting the information sent between the website and the browser, preventing cybercriminals from reading and modifying any information that’s being transferred.
The more popular TLS isn’t free. A website owner has to buy this technology – referred to as TLS certificate – from any of the companies trusted by browsers. Symantec was once a trusted issuer of TLS certificates by Google, the owner of Chrome, and Mozilla, the organization behind Firefox.
HTTPS, which stands for Hyper Text Transfer Protocol Secure, appears in the URL when a website uses a TLS certificate. Google has also been rewarding websites using TLS certificates with improved web rankings. As of July 2018, according to Mozilla, 3.5% of the top 1 million websites were still using Symantec TLS certificates.
When a visitor attempts to connect to a website, the browser used by the visitor requests the site to identify itself. The site then sends the browser a copy of its TLS certificate. The browser, in return, checks if this TLS certificate is a trusted one. If the browser finds that the TLS certificate can be trusted, the browser then sends back a digitally signed acknowledgment to start the TLS encrypted session.
Reasons Behind the Distrust of Symantec TLS Certificates
In March 2017, Ryan Sleevi, software engineer at Google Chrome, posted on an online forumGoogle’s findings, alleging that Symantec failed to properly validate TLS certificates. Sleevi said that Symantec mis-issued 30,000 TLS certificates over a period spanning several years.
“Symantec allowed at least four parties access to their infrastructure in a way to cause certificate issuance, did not sufficiently oversee these capabilities as required and expected, and when presented with evidence of these organizations’ failure to abide to the appropriate standard of care, failed to disclose such information in a timely manner or to identify the significance of the issues reported to them,” Sleevi said.
Symantec, for its part, said that Google’s allegations are “exaggerated and misleading”. “Google’s statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading,” Symantec said. “For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm. We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program.”
Mozilla, for its part, conducted its own investigation surrounding Symantec’s issuance of TLS certificates. Mozilla said it found a set of issueswith Symantec TLS certificates. A consensus proposalwas reached among multiple browser makers, including Google and Mozilla, for a gradual distrust of Symantec TLS certificates.
On October 31, 2017, DigiCert, Inc. acquired Symantec’s website security business, and on December 1, 2017 DigiCert took over the validation and replacement of all Symantec TLS certificates, including TLS certificates issued by Symantec’s subsidiaries: Thawte, GeoTrust and RapidSSL.
“DigiCert will replace all affected certificates at no cost,” DigiCertsaid in a statement. “Additionally, you don’t need to switch to a new account/platform. Continue to use your current Symantec account to replace and order your SSL/TLS certificates.”
Implications of the Distrust of Symantec TLS Certificates
Mozillasets October 23, 2018 as the distrust date of all TLS certificates issued by Symantec. Googlesets October 16, 2018 as the distrust date for all TLS certificates issued by Symantec to non-enterprise users, while January 1, 2019 is the distrust date set by Google for all TLS certificates issued by Symantec to enterprise users. Apple, the owner of the Safari browser, sets “Fall 2018” as the date of complete distrust of Symantec TLS certificates.
In the case of Chrome, if website owners fail to replace their Symantec TLS certificates beyond the prescribed period by Google, the message below will be shown instead:
Image by Google
In the case of Firefox, the message below will be shown instead:
Image by Mozilla
As can be gleaned from the distrust notices by Google and Mozilla, failure to replace Symantec TLS certificates runs the risk of attackers trying to steal information from your organization’s website, including passwords, messages and credit card details.
According to Mozilla, whenever it connects to a website, it verifies that the TLS certificate presented by the website is valid and that the site’s encryption is strong enough to adequately protect the privacy of the visitor. If Firefox determines that the TLS certificate can’t be validated or if the encryption isn’t strong enough, the connection to the website will be stopped and instead, the message, “Your connection is not secure” will be shown, Mozilla said.
“When this error occurs, it indicates that the owners of the website need to work with their certificate authority to correct the policy problem,” Mozilla added.
Contact us today if your organization needs assistance in replacing legacy Symantec TLS certificates.
How a Secure Website Can Boost Your SEO
Back in 2014, Google announced that they would introduce HTTPS as a signal for ranking criteria. This was great news for anyone who had a secure website.
However, there were questions. Was a secure website a good point for SEO, or was hardly a drop in the bucket?
If it was a big deal, what type of certificates would help?
There's a lot of questions, and unfortunately, not a lot in the way of answers. However, we're here to help provide some clarification.
How does a secure website boost your ratings?
Using a secure website as a ranking booster is still a relatively untapped way to jump up the Google ladder. Only about 2% of the top million websites redirect to a secure version of that site.
This could be because there aren't that many websites that are secure.
The main benefit to using a secure website is the fact that any user experiences will be secure. This is especially important if a user is transmitting data like credit card information.
Of course, this should be obvious. It's not an up-and-coming cyber security precaution, but it does endure.
You can see if your website is secure by looking at your address bar. If you see "https" before your URL, you're in the clear. Some browsers, such as Firefox and Google Chrome, highlight this in green to bring more attention to the fact.
Security and SEO?
The above may be true, but how does a site security help your website out in the important ranking race?
Google has begun to prefer indexing secure versions of websites over insecure versions.
For the most part, since so few people have made the switch to secure certificates, the use of a secure website acts as a tiebreaker in the race.
For instance, if all other factors are dead on, neck-in-neck, the website which is secure will take precedence over the one that isn't.
Your backups are safe
The great thing about using a secure website is that it doesn't erase your referrals or any of your data. You can switch over to a secure certificate and keep your referrals.
Another plus? It almost guarantees that you'll keep your traffic.
If your website and business relate to sales or other confidential information, it's almost mandatory that you use a security certificate. If you don't you risk your audience dropping off when they see that their information isn't secure.
A security certificate can be a lifesaver when it comes to your Google rankings. While there are still plenty of websites ranking without it, the idea of using a certificate is growing in popularity.
In most situations, so few people have switched to using a certificate that it can't be factored into crucial criteria. However, a certificate can give you a leg up that can be used to break any ties between your site and another.
In the ultra-competitive SEO world, you can take any advantages that you can get. For that reason, you'd be foolish if you didn't make the switch to using a security certificate.
If you have questions regarding cyber security and how to keep your data safe, we're happy to get in touch with you and help you make your website secure.
What to do After Suffering a Website Hack
Even if you do everything right to protect your website, there's still a chance that someone can find a way to hack it.
So what do you do after suffering a website hack? It can be difficult to figure out where to start.
You want to be sure to get your site back up and running as soon as possible -- here are five things you need to do ASAP.
1. Scan Your Website
Before you dive into trying to fix the problem, you need to figure out exactly what happened.
Start a scan to assess the damage and figure out where your issue is coming from.
It's a good idea to download some AntiVirus software to make sure that your computer isn't the issue. If the virus is in your desktop or laptop, fixing just your website won't help.
If it's not your computer, scan your website to find the problem. Then move on from there.
2. Change Your Passwords
This seems like a no-brainer, right? But not everyone realizes how important it is to change all of your passwords after a website hack.
You need to change the password for every single access point that your website has.
While you're at it, make sure that your password is strong and is not based on a dictionary word. The longer and more complex, the better. And don't use the same password for every access point -- change it up!
If you're worried about remembering your new passwords after you've changed them, use a password manager to keep them straight.
3. Reinstall Software & Plugins
We know -- this sounds like a lot of work, and probably something you'd rather avoid.
But if you want to be sure that everything malicious has been removed from your site, you're better off removing and reinstalling your software and plugins.
That reduces the risk of a virus sticking around after your cleanup just to hack your site all over again. The last thing you want is a new website hack just after you've cleaned up the old mess.
A fresh installation works wonders.
4. Restore Your Backup
Hopefully, you back up your website often. If you do, restore your latest backup after you've reinstalled all of your plugins.
If you don't have a backup to work with, now is a great time to start over.
Think about it like an important document for work. The smart thing to do is save multiple copies or use an online storage service just in case.
Your website is just as important, so you should take the same precautions.
Use an offsite service to back up your site and test it often!
5. Make Sure Users Aren't Driven Away
How fast do you click away after Google warns you that a site isn't safe?
If Google recognized that your site was hacked, chances are there's now a warning displayed when users try to navigate to your site.
After you've re-secured your website, be sure Google isn't driving away traffic. You can check their guide for how to make sure the 'hacked' label is removed.
After you've completed all of these steps, your website should be ready to go.
Steve E. Driz