Theory and practice of web application security efforts in organizations worldwide

75% of executives believe their organization scans all web applications for security vulnerabilities, while nearly 50% of security staff say they don’t, a Netsparker survey reveals.

web application security efforts

Web application security efforts are insufficient

Even more concerning, over 60% of DevOps respondents indicate that new security vulnerabilities are being found faster than they can be fixed, indicating that web application security efforts are insufficient.

However, only just over 40% of executives are aware of this situation, and thus most companies are unlikely to be making the required investments to remedy the situation.

Despite this, respondents ranked web application security highest among areas they believe their company should focus. Over 66% of respondents named web application security as a priority – more than any other aspect of IT security, ahead of network security, endpoint security, and patch management.

Additional highlights

  • While just 20% of developers believe that development teams are resistant to incorporating security, close to half of security professionals say they encounter developer resistance.
  • Just under 40% of developers indicated that critical security issues get automatically escalated, showing that organizations still have a long way to go to fully integrate security into the software development process.
  • Just under 35% of developers report friction caused by security false positives, compared to over 54% of security staff. This suggests that security teams bear the bulk of extra work caused by false alarms.

Disconnect between theory and practice

The survey shows a worrying disconnect between the theory and practice of web application security. While most organizations appreciate the importance of web security, many still don’t scan all their applications and an even greater number struggle to deal with vulnerabilities in a timely manner.

web application security efforts

This research shows that perceptions and expectations of web application security vary widely depending on the role. This misalignment between perception and reality creates dangerous threats to the security of organizations and their customer’s data as well.

Biomedical orgs working on COVID-19 vaccines open to cyber attacks

In a recently released report by the UK National Cyber Security Centre (NCSC), whose findings have been backed by Canada’s Communications Security Establishment (CSE) and the US NSA and CISA (Cybersecurity and Infrastructure Security Agency), the agency has warned about active cyber attacks targeting biomedical organizations that are involved in the development of a COVID-19 vaccine.

Biomedical cyber attacks

On Friday, BitSight researchers shared the results of a study that looked for detectable security issues at a number of companies who play a big role in the global search for a vaccine, and found compromised systems, open ports, vulnerabilities and web application security issues.

Biomedical orgs under attack

The report details recent tactics, techniques and procedures (TTPs) used by APT29 (aka “Cozy Bear”), which the NCSC and the CSE believe to be “almost certainly part of the Russian intelligence services.”

The agencies believe that the group is after information and intellectual property relating to the development and testing of COVID-19 vaccines.

“In recent attacks (…), the group conducted basic vulnerability scanning against specific external IP addresses owned by the organisations. The group then deployed public exploits against the vulnerable services identified,” the report states.

Among the flaws exploited by the group are CVE-2019-19781 (affecting Citrix’s Application Delivery Controller (ADC) and Gateway), CVE-2019-11510 and CVE-2018-13379 (affecting Pulse Secure VPN endpoints and Fortigate SSL VPN installations, respectively) and CVE-2019-9670 (affecting the Synacor Zimbra Collaboration Suite).

The group also uses spear-phishing to obtain authentication credentials to internet-accessible login pages for target organizations.

After achieving persistence through additional tooling or legitimate credentials, APT 29 uses custom malware (WellMess and WellMail) to execute arbitrary shell commands, upload and download files, and run commands or scripts with the results being sent to a hardcoded Command and Control server. They also use some malware (SoreFang) that has been previously used by other hacking groups.

The report did not identify the targeted organizations nor did it say whether the attacks were successful and whether any information and IP has been stolen.

Biomedical orgs open to cyber attacks

As many security researchers pointed out, Russian cyber espionage groups aren’t the only ones probing these targets, so these organizations should ramp up their security efforts.

BitSight researchers have recently searched for security issues that attackers might exploit. They’ve looked at 17 companies of varying size that are involved in the search for a COVID-19 vaccine, and found:

  • 25 compromised or potentially compromised machines (systems running malware/bots, potentially unwanted applications, spam-sending machines and computers behaving in abnormal ways) in the past year
  • A variety of open ports (i.e., exposed insecure services that should be never exposed outside of a company’s firewall): Telnet, Microsoft RDP, printers, SMB, exposed databases, VNC, etc., which can become access points into a company’s network
  • Vulnerabilities. “14 of the 17 companies have vulnerabilities and six of them have very serious vulnerabilities (CVSS score > 9). 10 companies have more than 10 different active vulnerabilities.”
  • 30 web application security issues (e.g., insecure authentication via HTTP, insecure redirects from HTTPS to HTTP, etc.) that could be exploited by attackers to eavesdrop on and capture sensitive data, such as credentials, corporate email, and customer data.

“These findings are not abnormal when compared to other groups of large companies (e.g. the Fortune 1000), but given the heightened threat environment, they do provide cause for concern,” the researchers pointed out.

“It only takes a misconfigured piece of software, an inadvertently exposed port, or an insecure remote office network for a hacker to gain entry to systems that store scientific research, intellectual property, and the personal data of subjects involved in clinical trials.”

40% of security pros say half of cyberattacks bypass their WAF

There are growing concerns around the number of businesses vulnerable to cyberattacks due to hackers’ ability to bypass their Web Application Firewall (WAF), Neustar reveals.

cyberattacks bypass WAF

Cyberattacks bypass the WAF

49% of security professionals reported more than a quarter of attempts to sidestep their WAF protocols had been successful in the last 12 months. In addition, as many as four in ten respondents disclosed that 50% or more of attacks had managed to get around their application layer firewall.

These findings come at a pivotal time, as organizations continue to adapt their security strategies to cope with the increase in malicious web activity associated with COVID-19.

29% of respondents admitted they had found it difficult to alter their WAF policies to guard against new web application attacks, while just 15% said they had found the process very easy.

No fully integrated WAF

Despite many having already been on the receiving end of a successful web-application attack, 39% of respondents declared they do not have a WAF that is fully integrated into other security functions; a technique that is critical in developing a holistic defense against a variety of attack types. Three in ten also claimed that half of network requests have been labelled as false positives by their WAF in the last year.

“As members of the public, we have witnessed the steady and significant growth of volumetric DDoS attacks, fake domains, malicious malware and harmful misinformation. However, while these may be the security concerns capturing headlines, those within the community have also seen the unsettling rise in application-layer attacks,” said Rodney Joffe, Senior VP and Fellow at Neustar.

“Often unleashing destruction before they are even recognized, these attacks are equally as damaging, targeting specific vulnerabilities to cause a multitude of complications for those on the receiving end.”

“Due to their ‘under-the-radar’ nature, application-layer attacks are difficult to detect and therefore require a security posture that is always-on in order to be identified and mitigated. Only by providing protection across the entire network can organizations respond to the type of threats we are seeing today.

“For full-protection that doesn’t hinder business performance or add unnecessary complexities, organizations should opt for a cloud-based WAF, underpinned by curated, actionable threat data.

“Not only is this approach guaranteed to safeguard against the most common web threats, it also delivers visibility into application traffic, no matter where the applications themselves are hosted,” added Joffe.

DDoS attacks and system compromise ranked as the greatest concerns

There has also been a steep 12-point increase on the International Cyber Benchmarks Index year-on-year. Calculated based on the changing level of threat and impact of cyberattacks, the Index has maintained an upward trend since May 2017.

During March – April 2020, DDoS attacks and system compromise were ranked as the greatest concerns for security professionals (both 21%), followed by ransomware (17%) and intellectual property (16%). To date, 68% of enterprises surveyed indicated that they had been on the receiving end of a DDoS attack at any given time, up 3% on previous reports.

As companies rely on digital revenue, the need for web and mobile app security skyrockets

As non-essential businesses have been forced to shut their doors around the world, many companies that previously relied heavily on the brick-and-mortar side of the business are now leaning more on revenue from their digital platforms. By 2023, according to research performed by Statista, applications may generate nearly $935 billion in revenue. With increased reliance on these applications and increasing customer traffic, security will play a critical role.

applications security

Although the use of applications has steadily increased, the difference in the ways that web and mobile applications are protected is not widely understood. Additionally, many companies that have been using security tools for their web application may feel that moving these security tools to mobile may be difficult, but it isn’t.

Let’s delve deeper into the similarities and differences in mobile and web apps, and what protection for each of those platforms looks like.

Mobile applications

When it comes to mobile applications, the customer that is using a service has an operating system that stores data. Because sessions and identities are usually saved, the app knows who the user is when it’s opened. The user’s data is saved on that particular device. If the application that the user uses is hacked, the cybercriminal can also access the personal information and sessions that the application uses to remember and authenticate the user.

Web applications

Unlike mobile applications, web applications don’t have long-term memory (although they do perform some caching). This means that they do not save a large amount of data in the same way that mobile applications do. If a web application is hacked, the cybercriminal has gained a foothold, but not instant access to user data. The foothold can later be leveraged to access back-end databases or other sensitive places within the company’s network. This can lead to a potential breach.

Application security for both types of apps

Both types of applications can be protected through the right type of application security testing. Mobile application security testing (MAST) and web application security testing tools are easily accessible nowadays. According to research performed by WhiteHat Security, organizations that perform scans during the application’s production have a lower chance of being breached. Additionally, organizations that include security in DevOps are able to lower the risk of a breach, reduce costs and have better time to market.

Security testing for web applications

Web application security testing focuses mainly on the relationship between the request and response. Because the size and complexity of websites has increased over time, the need for web app security testing tools that contextualize the risk carried by the vast amounts of data collected as they try to spot anomalies and identify vulnerabilities has increased as well.

There are two types of tools that can achieve this: dynamic application security testing (DAST) and static application security testing (SAST).

DAST scans apps on an ongoing basis once they have been deployed, and SAST scans applications at the pre-production level. Combining both DAST and SAST is a great way to strengthen the application’s security not only through the DevOps lifecycle, but also into production when the app is live and in use.

All about MAST

MAST looks at the coordination between the request and its response, and also how they are handled within the operating system. The best MAST approach uses both dynamic and static automated scanning in addition to manual mobile application-layer penetration testing. This offers coverage throughout the entire DevOps lifecycle. It also tackles compliance requirements, reduces risk and produces safer mobile apps that stay secure against potential attacks.

Adding a mobile app to a company’s product line-up should not be nerve-wrecking, even in these stressful times. By adding application security testing when implementing these applications, companies can save themselves and their customers from major data breaches and give the business time to appreciate the benefits of having an application – rather than fretting over risks.

Client-side web security

To address attacks such as XSS, Magecart and other card skimming exploits found in modern eCommerce environments, the use of client-side web security methods is beginning to emerge as a particularly useful practice.

client-side web security

Obviously, enterprise teams should integrate client-side protections with desired server-side countermeasures to ensure a full risk management profile (e.g., the client-side is a poor selection point to stop denial of service).

Several standards-based client-side security approaches have begun to mature that are worth examining from the perspective of website security and protection of browser sessions from malicious exploits. The best client-side security platforms automate implementation of these standards-based controls with emphasis on simplicity of administration. A typical, representative platform is used to demonstrate necessary client-side security controls.

Content security policy

To understand client-side security platforms, it helps to first explore the specifics of a standard approach known as a content security policy (CSP). This is a standard that is designed to address several types of web breaches such as cross-site scripting, click-jacking and form-jacking (all described earlier in this article series). CSP is also designed to reduce the risk of client-side malware injected from an infected advertising ecosystem.

CSPs are implemented as standard directives involving HTTP headers or page tags that specify which domains, subdomains, and resources a browser can load from a website. CSP use is consistent with the browsers any user would likely use including Chrome, Firefox, Safari, and Edge. The goal is that if malicious code is resident on a site, then visitors to that site would be prevented by the CSP from being directed to the hacker’s domain.

client-side web security

Figure 1. Content security policy

The example shown above in Figure 1 is taken directly from the original W3 recommendation. The CSP code can be interpreted as follows: Each source expression represents the location where content of the type specified is allowed to be pulled. To illustrate this whitelist security operation, consider that the self keyword-source designation, in the example above, represents the set of URIs in the origin as the protected website.

Companies like Google have rolled out CSP successfully and are using it to stop attacks against their web applications daily. However, CSP is deployed only lightly in most web application environments. The challenge with CSP implementation has been its complex administration. Tala Security researchers have found, for example, that roughly two percent of website operators in the top Alexa 1000 websites deploy the standard to prevent client-side attacks. Assisting with this administrative challenge is a primary motivation for client-side platforms.

Client-side security protection results from using CSP can websites can be quite impressive. Here are some observed statistics from the Tala Security research team based on their experiences with client-side security support:

  • Images – The average website in the Alexa 1000 loads images from roughly sixteen different external domains. The img-src directive in CSP blocks images from any unwanted or potentially malicious sites.
  • Stylesheets – The average website in the Alexa 1000 loads stylesheets from roughly two different external domains. The style-src directive in CSP blocks stylesheet loads from any unwanted or potentially malicious sites.
  • Fonts – The average website in the Alexa 1000 loads images from roughly one-and-a-half different external domains. The font-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.
  • Media – The average website in the Alexa 1000 loads images from different external domains. The media-src directive in CSP blocks font downloads from any unwanted or potentially malicious sites.

Subresource integrity

An additional applicable cyber security standard from the World Wide Web Consortium (W3C) is known as subresource integrity (SRI). This standard is designed to validate resources being served up by any third party on a visited website. Such third parties include content distribution networks (CDNs), where it has not been uncommon to find malicious code being offered up to unsuspecting websites.

SRI is implemented through cryptographic hash functions which finger-print JavaScript being offered by third parties. Browsers can then fetch a resource, check the cryptographic hash value – which include the location of the resource, and then make a policy decision about whether to accept the resource. This capability is supported in all important browsers, and significantly reduces the risk of malware from third party actors.

Client-side security platform

Client-side security platforms will make use of both CSP and SRI to provide effective client-side protections. The goal of these platform is to provide policy-based mitigation of fine-grained behavior for third-party sources where content is being served. Client-side platforms can then watch for any data collection suggestive of the attacks used by Magecart (and similar groups).

The client browser mitigation should be implemented based on artificial intelligence-based classification and learning. The software should install quickly and easily. Commercial platforms should support implementation for many target environments including Apache Nginx, IIS, NodeJS, and others. Performance and latency impacts should also be essentially non-existent and non-affecting of the user experience. Specific capabilities included in a commercial platform should include:

  • Indicator evaluation – The selected platform should be designed to evaluate many different indicators of a web page’s architecture to analyze code, content, connections, and data exchange.
  • Behavioral and risk modeling – The platform should include support for analysis to inform a behavioral and risk modeling task designed to highlight normal behavior and expose vulnerabilities.
  • Operational improvement – Insights gained from the platform evaluation and modeling should be made available to help prevent client-side attacks such as XSS, Magecart, and the like.

The operation of world-class client side security platforms should include an on-going interaction between four different activities: Build, Monitor, Block, and Respond. The connection flow between these different lifecycle phases is depicted below.

client-side web security

Figure 2. Commercial client-side security lifecycle

Information model

Client-side security platforms should implement some type of information model that can be used to analyze the different behaviors on pages from the customer’s website to be protected. The security objective for such extraction should be to explicitly identify any sources of code and content on these web pages, as well as to find any data exchange support options that could involve sensitive data.

The resultant behavioral information model will thus provide a functional baseline on which to perform the necessary client-side risk management. The goal obviously should be to determine in real-time whether the site is vulnerable to attacks, third-party insertion, or other advanced breaches. As one would expect, performance of such behavioral modeling and protection in real-time complements any existing server-side security tools.

Contributing author: Aanand Krishnan, CEO, Tala Security.

Web shell malware continues to evade many security tools

Cyber attackers are increasingly leveraging web shell malware to get persistent access to compromised networks, the US National Security Agency and the Australian Signals Directorate warn.

Web shell malware

What are web shells?

Web shells are malicious scripts that are uploaded to target systems (usually web servers) to enable attackers to control it remotely. In affect, they create a backdoor into the target system.

The threat is not limited to internet-facing web servers, though, and can be deployed on non-internet facing internal content management systems or network device management interfaces.

Preventing web shell installation

Attackers usually manage to deploy web shells by exploiting web application vulnerabilities, weak server security configuration, or by uploading to otherwise compromised systems.

Among the web application vulnerabilities that are commonly exploited to install web shell malware are:

“This list is not intended to be exhaustive, but it provides insight on some frequently exploited cases,” the agencies noted, and advised organizations to regularly patch/update web apps and limit their permissions.

“In particular, web applications should not have permission to write directly to a web accessible directory or modify web accessible code. Attackers are unable to upload a web shell to a vulnerable application if the web server blocks access to the web accessible directory,” they pointed out.

If the latter step is not possible, they advised orgs to implement file integrity monitoring to block file changes to web accessible directories or alert when changes occur.

Finally, they should add defense layers such as Intrusion Prevention Systems (IPS) and Web Application Firewalls (WAF), and improve network segregation and harden web servers.

Detecting installed web shells

“Web shells are difficult to detect as they are easily modified by attackers and often employ encryption, encoding, and obfuscation,” the agencies explained. That’s what makes them so useful to attackers and so dangerous to defenders.

There are several methods that can be used to detect their presence, such as:

  • Comparing a verified benign version of the web app against the production version (and analyzing the discrepancies)
  • Monitoring web traffic for anomalies
  • Detection based on signatures (can work for detecting popular web shells that have been minimally modified)
  • Monitoring for unexpected network flows
  • Using Endpoint Detection and Response (EDR) and logging tools such as Microsoft Sysmon or Auditd (on Linux systems) to spot system call or process lineage abnormalities

The NSA has set up a GitHub repository with tools and signatures that can help defenders implement these techniques.

Finally, the agencies warn, organizations that find a web shell on one or more of their systems should investigate how far the attacker penetrated within the network.

Understanding web security solutions

As should be evident to anyone in the cyber security industry, the wide range of available web security solutions from commercial vendors will necessarily have varying degrees of effectiveness against different threats.

understanding web security solutions

A premise of this article is that client-side security has been under-represented in these solutions – and to see this, it helps to briefly examine the specifics of the well-known web security solutions in use today, and their respective emphases.

Web Application Firewalls (WAFs)

The design of web application firewalls (WAFs) addressed the fact that the target of most malicious activity is not always the infrastructure surrounding a web hosting environment, but rather the application itself. By manipulating or exploiting security weaknesses in the critical applications of a business, bad actors could gain access to the most valuable assets.

WAFs are built to track the specifics of an application protocol versus the most foundational focus of an IDS/IPS. A WAF has the great advantage of being able to line up closely with the back-and-forth between user and application so that weird commands or other unusual behavior can be identified easily. Doing this properly is easier said than done, but a WAF positioned on the server side of an application architecture can be helpful.

understanding web security solutions

Figure 1. WAF architecture

One challenge to WAF operation is the complexity of dealing with the incessant pace of change for applications in a modern DevOps environment. Another challenge, however, is a WAF’s inability to detect and mitigate client-side security exploits. Like an IDS/IPS, when exploit code finds its way to the user’s browser, mitigation of subsequent attack behavior is no longer in the purview of the server-side controls.

Secure Sockets Layer (SSL)

The use of Secure Sockets Layer (SSL) is an important contribution to secure eCommerce because it provides strong protection for the provision of user credential information – and, in particular, credit card numbers over the Internet. Virtually all eCommerce purchases today require some form of credit card exchange, and SSL has been invaluable in reducing the risk of this data being inappropriately observed in transit.

The infrastructure supporting SSL is surprisingly complex, and has required cooperation between various different organizations including the eCommerce vendor, the hosting provider, the browser companies, and security entities known as Certification Authorities (CAs.) Nevertheless, the SSL infrastructure for modern on-line transactional business is strong, and has benefited companies such as Amazon.com in a profound manner.

understanding web security solutions

Figure 2. SSL architecture

While SSL has been a great success, its focus has been on the confidentiality of credentials, and not on the prevention of malicious attacks – especially on the client-side. Sadly, too much user training has incorrectly advised users that if they see evidence of SSL in action, that the “security issues” are covered. This might be true for avoidance of credit card sniffing attack in transit, but it is definitely not true for most web attacks, including client-side exploits.

Intrusion Detection Systems (IDS)

The most traditional means for protecting endpoints and infrastructure from security attacks involves insertion of an intrusion detection system (IDS) or intrusion prevention system (IPS) in-line with access to these components. The earliest IDS/IPS systems were built to detect attacks based on signatures of known methods, but more recent systems have been designed to include some more behavioral attributes.

Nevertheless, all IDS/IPS platforms inspect live session traffic to determine whether a given activity should be prevented from starting or terminated while on-going. This man-in-the-middle (MITM) approach its respective benefits and drawbacks, but it is common – especially since such functionality is regularly integrated into a next-generation firewall or gateway. The resulting architectural set-up for most enterprise looks as follows:

understanding web security solutions

Figure 3. IDS/IPS architecture for web security

One challenge with any inspection-based solution is that encrypted communications traverse the MITM security with impunity. Another is that normal downloads to the client are not easily differentiated from malicious ones. Once a bad script finds its way past the IDS/IPS onto a client browser, the malware can run without the gateway security having any idea it is occurring. This does not remove the need for MITM security, but it does highlight a major weakness.

Client-side security

The provision of security for client-side attacks requires a new type of focus, one not found in many commercial solutions. It requires that security protections either pre-install on the client, or travel to the client in a dynamic manner based on the transaction being protected – usually a user with a browser visiting a website. The traditional deployment of client-side security for enterprise users has involved the following types of solutions:

Traditional anti-malware – The use of signatures as the basis for detecting malware continues to be a mainstay of modern enterprise security – and this extends to web application security. Many CISO-led teams rely on their anti-malware vendor to help reduce the risk of malware that might have been downloaded from a website. As one might expect, even with behavioral enhancements, this remains a weak control.

Virtual containers – The use of virtualized client computing environments, sometimes referred to generally as virtual containers, supports the idea that if malware finds its way to the endpoint, then it cannot reach real assets. This approach requires deployment of endpoint virtualized software, which often requires some work to minimize impact to application performance or use.

Web isolation – This technique involves a MITM gateway being positioned between the client and the website. Such processing can be software-only, or for higher assurance, implemented in hardware. The use of MITM gateways is shown here as a client-side protection because it extends the virtualization concept to the gateway.

Off-line detonation – The use of virtualized, off-line detonation is a useful means for detecting downloadable malware, and is commonly found in protection schemes for email attachments. It is also implemented frequently as part of a MITM gateway, and like isolation, complements the use of controls more specifically designed to protect the browsing session from website-born malware.

That such an assortment of methods exists is both good news and bad news for enterprise security managers: On the one hand, it is good news because these are all sensible controls, each with successful vendors supporting a range of enterprise customers. But it is also bad news in the sense that none address the problem of flexible, policy-based security policy enforcement for applications executing on the client browser.

In the next article, we’ll describe several standard application-specific controls that have emerged to address the risk of attacks such as Magecart, card skimming, and other web application and eCommerce-born exploits. The technology will be explained in the context of a typical client-side security platform, which implements content security policies, subresource integrity, and other security safeguards that should be of interest to the security team.

Contributing author: Aanand Krishnan, CEO, Tala Security.

A client-side perspective on web security

Threats to web security are explained in this first of a three-part article series, and client-side security is shown to address a commonly missed class of cyber attack exemplified by Magecart. Traditional solutions to web security are outlined, including a new approach to web security based on client-side standards such as content security policy and subresource integrity. These emerging approaches are explained in the context of a representative client-side security platform.

threats web security

Introduction

Perhaps the most salient aspect of cybersecurity as a professional discipline is its continuous cycle of change. That is, as cyber attacks emerge that challenge the confidentiality, integrity, or availability of some on-line resource, corresponding protection solutions are invented to reduce the risk. Once these solutions become integrated into the underlying fabric of the resource of interest, new cyber-attacks emerge, and new solutions are invented – and the cycle continues.

In some cases, new protective cyber solutions have the side-benefit anticipating new forms of malicious attacks – and in cases where this works, security risks are often avoided in a wide range of different scenarios. Two-factor authentication, for example, was created in response to password guessing, but is now an important component in the design of new Internet of Things (IoT) machine-to-machine application protocols to reduce risk.

Nowhere is this process of introducing and mitigating cyber risk more obvious than in web security – also referred to as web application security. With valuable assets being provisioned and managed increasingly through web-based interfaces, the value of web-based exploits continues to rise. One consequence of this rise is that despite the many technologies available to protect web resources, the gap between offense and defense is growing.

A main premise in this technical series is that this web security gap stems from the fact that most application execution occurs on the modern browser. The web security community has long recognized the need to deploy functional controls to safeguard the server-side vulnerability of web servers delivering content and capability to client browsers. Too little attention, however, has been placed on this client-side vulnerability, which is attractive to attackers and largely ignored by today’s security infrastructure.

The three parts that follow in our series are intended to help address this oversight. In Part 1, we offer an introduction to the most common cyber attacks that target websites today. Part 2 then provides an overview of the web security solutions that are deployed in most production environments today. Finally, Part 3 offers an introduction to how a representative client-side security solution can help rectify the client-side weaknesses exploited by bad actors today.

Common attacks to websites

Commensurate with Tim Berners-Lee’s idea in the mid-1990’s to layer hypertext protocols and markup languages onto the Internet protocol (IP) came the emergence of offensive means to attack the infrastructure, systems, and applications that make up the now-called web. And thus was born the discipline of web security, which can be defined as the set of protective measures required to manage the security risk of web-based computing.

As one would expect, the taxonomy of web security issues quickly grew in several directions, but early focus was on avoiding denial of service attacks, protecting hosting infrastructure, and ensuring free flow of web content to users. Such focus on availability corresponded to the observation that if a website was down or not working properly, then eCommerce transactions would not occur – which had obvious revenue implications.

In addition to these infrastructure concerns, however, came a growing observation that application-level security issues might have severe consequences – often to the privacy of customers visiting a website. Thus was born the so-called web applications threat, which quickly evolved from a small concern to a massive security challenge. Even today, finding sites with exploitable vulnerabilities in their web applications is an easy task.

Several standard attack strategies have emerged in recent years that have been difficult to eradicate. These nagging problems prey on the complexity of many web application designs, and on the relative inexperience and ignorance of many web software administrators. Below, we describe these strategies – four in total – that continue to drive risk into eCommerce infrastructure and to cause challenges for many enterprise security teams:

Cross-Site Scripting (XSS)

The most common application-level web security attack is called cross-site scripting or just XSS. A cross-site attack involves a technique known as injection – where the attacker finds a way to get scripts running on a target website. The ultimate goal is for that targeted web application to send the attacker’s code to some unknowing user’s browser. The XSS attack works best when a website accepts, processes, and uses input without much checking.

The end goal is that the attacker has managed to inject code into someone’s browser. That user will expect any downloaded scripts to be fine, since they came as dynamic content from the visited, and presumably trusted website. Their browser will then execute this code, often JavaScript, thus exposing sensitive information such as session tokens or cookies to the original attacker. The XSS code can also redirect a user to some infected website.

threats web security

Figure 1. XSS Attack Schema

Organizations such as Open Web Application Security Project (OWASP) suggest various defenses against XSS attacks. Their suggestions, many of which continue to be ignored by practitioners, involve common-sense coding and web administrative procedures that improve the processing of data from users. Most involve better validation of input data on the server side, which is a welcome security control and should be present in any web ecosystem.

Content and Ad injection

The challenge of dealing with content and ad injection attacks, also known as malvertising, has increased substantially in recent years. This should come as no surprise given the rise of the on-line advertising ecosystem as a force in modern business. Some estimates have the size of on-line advertising now reaching aggregate levels as high as $100B. Hackers and criminals understand this trend – and take advantage of exploitable weaknesses.

The way malvertising works follows a similar pattern to XSS attacks: Malicious actors find ways to inject their code onto websites through legitimate advertising networks. The goal, again similar to XSS, is to target visitors to the site, usually with the intent to redirect their browsers to some targeted website that has been planted with malware and that forms the basis for whatever attack is desired, such as credential theft.

Many observers have referenced the injection process as involving something called a drive-by download. This term references a user viewing an advertisement using a browser with an exploitable vulnerability (which is sadly a common scenario). While the user interacts with the ad, a redirection process is initiated whereby the malicious software finds its way to the unsuspecting visitor to the site.

threats web security

Figure 2. Drive-By Download via Malvertising

The traditional solution to this problem involves placing a control such as a web application firewall (WAF) in-line with the access. The WAF would be programmed to use signature or behavioral analysis to stop malicious code execution from untrusted sources. As with XSS security, this server-side protection is commonly found in advertising ecosystems as a primary control. Such emphasis can address malvertising, but might not work for all forms of attacks.

Magecart

The hacking group Magecart emerged several years ago, terrorizing websites with an attack known as card skimming. Normally, hacking groups tend to come and go quickly, but Magecart hit a nerve with their targeted breaches of enterprise websites and web applications. Wide ranges of different organizations saw their sites formjacked, and security solutions were not immediately evident to most victims.

The man-in-the-middle attack from Magecart is quite simple to explain: It begins with malicious code added to the JavaScript served to clients from a website. The malicious code then watches for and collects sensitive data such as credit card information from legitimate users visiting the site with their browser. The data is exfiltrated to a malicious drop site and is unloaded in the usual illegal manner. It’s that simple.

threats web security

Figure 3. Magecart Card Skimming

The nagging issue, however, is that common server-side security tools don’t account for this man-in-the-browser (MITB) attack because it occurs on the client side. Web application firewalls (WAFs), for example, don’t see the JavaScript activity and have no means for scanning libraries for code insertions. And when this attack is served from third or fourth-party hosted sites, the cascading result is something called piggy-backing.

Contributing author: Aanand Krishnan, CEO, Tala Security.

Increase web application security without causing any user disruption

In this podcast recorded at RSA Conference 2020, Jason A. Hollander, CEO, and Paul B. Storm, President at Cymatic, talk about how their platform builds a defensible barrier around the user, so web-based threats can be stopped at the source.

increase web application security

Here’s a transcript of the podcast for your convenience.

Welcome to the Help Net Security podcast. In this edition, I’m joined with the guys from Cymatic. Can you please introduce yourselves?

My name is Paul Storm. Good morning or good afternoon, wherever you are. And my name is Jason Hollander and we’re both the co-founders of Cymatic.

Can you tell me what is Cymatic’s approach to web security and what differentiates you in the marketplace?

Paul: Sure. I guess I could take it Paul. We built a web application defense platform that’s able to identify, basically calculate risk, and also really understand users from inside of the web application. Think of it as almost like a client-side WAF.

Jason: When you think about web application defense, it includes a lot of different silos of technology. And one of the things that we want to do is build a technology that brings the silos together. That way they can leverage each other to make smarter decisions. And we’re able to bring that as close to the user as possible.

If you think about web application threats and breaches, you want to catch it left of boom. A lot of the technology today is either at boom or right of boom because it’s in the network. We push it straight out to the user. It’s invisible. We surround the browser or the mobile device, and therefore we’re able to eliminate a lot of the threats, to see the threats that a lot of technology cannot, because they create silos.

increase web application security

In browser automation detection

Your website mentions next generation pre-endpoint protection. Can you tell our listeners exactly how does it work?

Paul: I’ll preface this by saying we are a young startup and messaging is something we’re still working on. For the world of startups out there, it’s an iterative process.

How does it work? There is a line of JavaScript that gets embedded into an implementer’s header tag. We don’t mind if it’s an internal site, an external site, internal users, contractors or consumers landing on that site. Once an entity lands on the site, they don’t need to authenticate, they don’t need to be registered users, and they don’t need to be logging in from a controlled device.

We open up a socket from that browser session, back to our Cymatic cloud. Then everything’s streamed on a real-time socket. One of our micro services will pick up on the feed or speed and only grab the elements that it needs to provide visibility, control or identify risk.

Jason: One of the things we did, Paul mentioned it, it’s got this real-time socket connection back to our cloud, which does all the AI and ML part of our product. A lot of technology is stateless. Once they do their job, they fall off. We’re stateful, we see it the moment someone lands on a web application, to the moment that they end their session – we’ve got complete visibility and complete control over that.

increase web application security

Identity assurance

If we take a look at the current cybersecurity trends in the industry, we see account takeover attacks have been rising steadily in the last year. So, how does your company help organizations with this type of attacks?

Paul: When we first created this, ATO was the first thing that we were trying to attack, probably the wrong choice of words, but to stop. We are basically looking at users based upon user behaviors. When you do that and you’re looking at not just a single vector, it’s really able to identify not just ATO risks, which is a definite problem, but all the other issues that come with an externally facing property. It’s a lot more holistic than just going after ATO. We’re identifying bots, IP risk session based threats. It’s not just looking at specifically ATO.

Jason: I’d say with ATO, a lot of technology just looks at “I want to stop ATO by blocking automation”. You have a lot of bot mitigation products that do that. You could stop ATO by having a multifactor. There’s a lot of ways to try to prevent it. But again, our approach is taking these silos, that are blind, to really understanding if that bot is a real risk and combining that with the verification of the user, combining that with identification of their interactions to other users, environmental things, credential hygiene that the user might have.

Let’s try to be preemptive to stopping attacks. If you think about an ATO, typically it’s from a credential breach. But what if those credentials have been breached but they haven’t been exposed publicly yet? Now how do you determine that? How do you determine if someone has poor credential hygiene?

The credentials might not have been breached, a company might not have been breached, but they are a risk to the organization because they possibly share credentials with other people. Or maybe they leverage those credentials, their corporate credentials, which should be a lot more secure and controlled, on social networks. Our technology, because of where we sit and the visibility we have, we’re able to triangulate that. And that provides better visibility and an indication of possible breach to an organization, than a lot of the technologies that, again, are after boom.

increase web application security

Compliance-driven reports and analytics

Your platform provides compliance, written reports and analytics. Can you tell us more about it?

Paul: All these bits of information are being streamlined. We could either visualize that through our own dashboards or you can basically tie it into a SIEM or SOC. With all of this data, we’re able to look at things from an actual compliance side of things, especially on devices that aren’t managed.

Jason: For us, the product has always started with visibility cause what you can’t see, you can’t control or manage. It’s hard to just turn on switches and turn knobs, and those types of things. One of the things that we do right out of the box, and because it deploys so easily, like Google Analytics, it’s just as line of JavaScript. Basically, within seconds we light up where those visibility gaps are. That’s one of those reports that security practitioners, or board members, the stakeholders around that organization’s security posture can look at and say: “All right, this tool has been running. Where do we have these gaps in our current technology set?”

And once they recognize that, then Cymatic can start remediating that on the fly. So, we do a lot of auto remediation. We don’t have a lot of roles because once you start flipping switches, turning knobs, and you don’t really understand how the product is making decisions, it actually increases your risk. We try to take all that decision making out of the organization, put it into the product, let the product remediate. And then over time you see these gaps start settling and going away.

Also, out of that is these reports that provide organizations insight to their probability of being breached. Cause today, if you ask CISOs or anyone in security: “Do you really understand the probability that your organization could be breached?” Typical answer is no, they just don’t, with the current toolset. At Cymatic, we can print out this report and they can say: “Okay, I feel not that they’re not going to get breached, but I feel a lot more confident in our ability to defend against any attack that we might have.”

To find out more information, please visit our website at cymatic.io and you can always contact us. There’s information on there too. If you want to learn more about Cymatic or see a demo and how it can help your organization.