Cross-Site Scripting: Still One of the Biggest Cyber Threats

Cross-site scripting, also known as XSS, is one of the most dangerous software errors that threatens websites and applications, even the likes of Gmail.

Security researcher Michał Bentkowski of Securitum recently discovered a cross-site scripting vulnerability in Gmail’s AMP4Email, also known as “dynamic email”. Launched in July 2019, Gmail’s dynamic email allows users to take action directly from within the message itself, such as RSVP to an event, filling out a questionnaire or browsinga catalog.

Allowing dynamic content in Gmail, Google knows it opens itself to security vulnerabilities such as cross-site scripting – a security vulnerability that allows malicious actors to add malicious code into trusted websites or applications. While Google takes a number of precautionary measures against cross-site scripting, Bentkowski discovered that Gmail’s dynamic email didn’t block the specific code HTML id attribute, thereby opening the email service vulnerable to cross-site scripting.

Bentkowski said he reported the cross-site scripting vulnerability to Google on August 15, 2019. According to Bentkowski, Google replied that “the bug is awesome, thanks for reporting”. Bentkowski added that on October 12, 2019, he received a confirmation from Google that the bug was fixed.

What Is Cross-Site Scripting?

Cross-site scripting vulnerability is so widespread that it’s ranked second in the 2019 Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Errors. According to CWE, which is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA), ranking for the top most dangerous software errors is based on the data from Common Vulnerabilities and Exposures (CVE) data and data from the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD).

The NVD data, in particular, covered the period from the years 2017 and 2018, which consisted of nearly 25,000 CVEs. Based on the NVD count, out of the 25,000 CVEs for the years covered, 3,430 CVEs were cross-site scripting vulnerabilities.

Cross-site scripting is a security vulnerability found in web pages or applications that accept user input. This includes login page, check-out page and, in the case of the Gmail case, Gmail’s AMP4Email or dynamic email.

While users typically place legitimate inputs such as usernames and passwords in login pages, credit card details in check-out pages or RSVP to an event in the case of Gmail’s dynamic email, these fields that accept user input could be exploited by malicious actors, giving them opportunity to insert malicious code into an otherwise trusted website or application.

In the case of Gmail’s dynamic email, there’s no report that malicious actors were able to exploit the said cross-site scripting vulnerability.

Security engineers at Microsoft were the first ones to coin the term cross-site scripting back in December 1999. In December 2009, in commemorating the 10th year anniversary of coining the word, security engineers at Microsoft, in the blog post “Happy 10th birthday Cross-Site Scripting!”, wrote, “Let's hope that ten years from now we'll be celebrating the death, not the birth, of Cross-Site Scripting!”

As shown in the latest ranking in the most dangerous software errors, cross-site scripting appears to be far from dead. Microsoft itself recently patch a cross-site scripting vulnerability on its Microsoft Outlook for Android software. The company said that the cross-site scripting vulnerability allows an attacker to “run scripts in the security context of the current user”. 

Magecart

Cross-site scripting has recently been put back into the headlines by Magecart – the umbrella term given to cybercriminal groups that steal credit card details from unsecured payment forms on websites. Magecart has been linked to the data breach at British Airways and the recent data breach at Macy’s.

Researchers at RiskIQ reported that Magecart breached British Airways baggage claim information page by just inserting 22 lines of code, enabling the attackers to grab personal and financial details entered by customers and sent the data stolen to the server controlled by the attackers. A security researcher, meanwhile, who wishes to remain anonymous, told BleepingComputer that the recent data breach at Macy's website was caused by the alteration of https://www[dot]macys[dot]com/js/min/common/util/ClientSideErrorLog[dot]js script, enabling the attackers to grab data entered by customers in the company’s website, in particular, checkout page and wallet page.

Preventive and Mitigating Measures Against Cross-Site Scripting

Attempts in the past have been made to stop cross-site scripting. One such attempt was XSS Auditor, a feature added to Google Chrome v4 in 2010.

XSS Auditor aims to detect XSS vulnerabilities while the browser is processing the code of websites. It uses a blocklist to identify suspicious code. In July of this year, Google security engineer Thomas Sepez announced the retirement of XSS Auditor.

Google senior security engineer Eduardo Vela Nava first proposed the retirement of XSS Auditor in October 2018. “We haven't found any evidence the XSSAuditor stops any XSS, and instead we have been experiencing difficulty explaining to developers at scale, why they should fix the bugs even when the browser says the attack was stopped,” Nava said. “In the past 3 months, we surveyed all internal XSS bugs that triggered the XSSAuditor and were able to find bypasses to all of them.”

As shown in the above examples, cross-site scripting vulnerability is a menace to websites and applications.

This holiday season – the time of the year when online shopping and other transactions are at its peak, it’s important to sanitize your organization’s website and applications to protect it from cross-site scripting.

When you need to protect your website and web applications against XSS and other common attacks, our team of experts is a phone call away and ready to protect your web applications in just minutes.

Under denial of service attack with ransom demands? Don’t pay! We will stop the DDoS attacks in a few minutes, for good.

Call today (888) 900-3749 or connect with us online.

Magento SQL Injection Flaw Puts E-Commerce Sites at Risk

Magento, an Adobe-owned company that promotes its e-commerce platform to have more than $155 billion in gross merchandise transaction volume annually, has called on online stores using its platform to install the company’s latest update as protection from a host of critical flaws.

Last March 26, Magentoannounced that it fixed 37 security vulnerabilities on its e-commerce platform. Out of the 37 vulnerabilities fixed by Magento through its security update, 4 vulnerabilities have a base score range between 9 to 9.8. Under the v3.0 standards of the Common Vulnerability Scoring System, base scores from 9 to 10 are considered as “critical.”

Out of the 37 vulnerabilities fixed by Magento through its latest security update, one vulnerability called PRODSECBUG-2198 stands out, not only because it’s one of the 4 vulnerabilities labeled as critical, but also because the exploit of this vulnerability is now out in the wild. Armed with this publicly available exploit, any day now PRODSECBUG-2198 vulnerability could be exploited by malicious actors.

PRODSECBUG-2198 bug is a SQL injection vulnerability found in Magento Open Source prior to 1.9.4.1, and Magento Commerce prior to 1.14.4.1, Magento 2.1 prior to 2.1.17, Magento 2.2 prior to 2.2.8, Magento 2.3 prior to 2.3.1. According to Magento, PRODSECBUG-2198 bug, also known as “SQL Injection vulnerability through an unauthenticated user” allows an unauthenticated user to execute arbitrary code through an SQL injection vulnerability, which causes sensitive data leakage.

According to Charles Fol of Ambionics, the one who reported the PRODSECBUG-2198 bug way back in November 2018, in a blog postsaid that the bug involves a minor mistake in the small piece of code of Magento. “This mistake, albeit minor, is very impactful …,” Fol said. “Surprisingly enough, this piece of code has been present since Magento 1.x !”

Ambionics also posted on GitHuba proof of concept on how the discovered mistake in the small piece of Magento code can be exploited. The publication of this proof of concept means that online stores using the Magento platform that haven’t installed the latest Magento update are at risk of this particular exploit.

The risk of SQL injection vulnerability through an unauthenticated user has a far-reaching effect.

What Is SQL Injection?

SQL, which stands for Structured Query Language, is a standard programming language for accessing databases. SQL injection, meanwhile, is one of the most common web hacking techniques. This form of attack was ranked by the Open Web Application Security Project (OWASP)in 2017 as the number one threat to web applications.

“Injection flaws, such as SQL … occur when untrusted data is sent to an interpreter as part of a command or query,” OWASP said. “The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.”

SQL injection was first documentedin 1998 by Jeff Forristal, also known by the alias Rain Forrest Puppy, now the CTO of mobile security vendor Bluebox Security. For years, many cyberattacks had been made possible through SQL injection. The cyberattacks on Sony in 2011 and TalkTalk in 2015 are some of the notable cyberattacks that used SQL injection as a weapon.

According to the Federal Bureau of Investigation (FBI), the cyberattack on Sony Pictures Entertainment between May 27, 2011 to June 2, 2011 in which attackers obtained confidential information from Sony Pictures’ computer systems was done using an SQL injection attack against Sony’s website.

In October 2016, UK’s Information Commissioner Office (ICO)fined TalkTalk for £400,000 (the company though settled the case for £320,000) for a cyber incident in October 2015 which led to the illegal accessed of personal data of 156,959 customers including their names, addresses, dates of birth, phone numbers, email addresses, as well as bank account details of 15,656 customers.

“The attack [October 2015 cyber incident on TalkTalk] was an SQL injection attack, a common type of cyber attack that has been well-understood … and for which known defences exist,” ICO said. “The investigation found there had been two previous SQL injection attacks on 17 July 2015 and between 2-3 September 2015 but TalkTalk did not take any action due to a lack of monitoring of the webpages.”

Prevention

Specific to Magento’s PRODSECBUG-2198 bug, online stores using the Magento platform, specifically Magento Open Source prior to 1.9.4.1, and Magento Commerce prior to 1.14.4.1, Magento 2.1 prior to 2.1.17, Magento 2.2 prior to 2.2.8, Magento 2.3 prior to 2.3.1 need to install the company’s latest update to prevent SQL injection attacks.

In general, e-commerce sites, regardless of the platform used, are attractive targets to hackers due to the fact that personal and payment information is required to complete a sale. SQL injection is a common weapon used by cyber attackers to compromise these e-commerce sites. Here are some security best practices that will harden your e-commerce site against SQL injection attacks:

• Keep all software, not just Magento, up to date.

• Use two-factor authorization for admin logins.

• Restrict outgoing connections to only those that are necessary, such as for payment integration.

• Use a dedicated Web Application Firewall (WAF) to analyze traffic and uncover suspicious patterns and proactively block SQL injection attacks.

• Do not install any unknown software applications, or open suspicious emails with suspicious links or attachments.

Preventing SQL injections attacks is easy, as long as you engage application security experts that understand your cybersecurity challenges and business goals delivering the right solution that works for you.

Contact ustoday and protect your web application against common threats in minutes without the need for capital investment or IT support.

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:

1. Injections

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.

Conclusion

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. 

Need more cyber security tips? Check out the rest of our blog posts or start a free trial of our web application security.