Security issues for APIs
The many benefits that APIs bring to the software and application development communities – namely, that they are well documented, publicly available, standard, ubiquitous, efficient, and easy to use – are now being leveraged by bad actors to execute high profile attacks against public-facing applications. For example, we know that developers can use APIs to connect resources like web registration forms to many different backend systems. The resultant flexibility for tasks like backend update also provide support for automated attacks.
The security conundrum for APIs is that whereas most practitioners would recommend design decisions that make resources more hidden and less available, successful deployment of APIs demands willingness to focus on making resources open and available. This helps explain the attention on this aspect of modern computing, and why it is so important for security teams to identify good risk mitigation strategies for API usage.
Security threats to APIs
OWASP risks to APIs
In addition to its focus on risks to general software applications, OWASP has also provided useful guidance for API developers to reduce security risk in their implementations. Given the prominence of the OWASP organization in the software community, it is worth reviewing the 2019 Top 10 API Security Risks (with wording taken from the OWASP website):
1. Broken Object Level Authorization. APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface level access control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
2. Broken User Authentication. Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user compromises API security overall.
3. Excessive Data Exposure. Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
4. Lack of Resources & Rate Limiting. Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
5. Broken Function Level Authorization. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
6. Mass Assignment. Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to mass assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
7. Security Misconfiguration. Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
8. Injection. Injection flaws, such as SQL, NoSQL, command injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
9. Improper Assets Management. APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
API security requirements
As exemplified by the OWASP list, the cyber security community is beginning to identify many familiar, canonical issues that emerge in the use of APIs for public-facing applications. Below are five generalized cyber security requirements for APIs that come up in design and development context frequently for both legacy and new Internet applications:
The adage that knowledge-is-power seems appropriate when it comes to API visibility. Application developers and users need to know which APIs are being published, how and when they are updated, who is accessing them, and how are they being accessed. Understanding the scope of one’s API usage is the first step toward securing them.
API access is often loosely-controlled, which can lead to undesired exposure. Ensuring that the correct set of users has appropriate access permissions for each API is a critical security requirement that must be coordinated with enterprise identity and access management (IAM) systems.
In some environments, as much as 90% of the respective application traffic (e.g., account login or registration, shopping cart checkout) is generated by automated bots. Understanding and managing traffic profiles, including differentiating good bots from bad ones, is necessary to prevent automated attacks without blocking legitimate traffic. Effective complementary measures include implementing whitelist, blacklist, and rate-limiting policies, as well as geo-fencing specific to use-cases and corresponding API endpoints.
Vulnerability exploit prevention
APIs simplify attack processes by eliminating the web form or the mobile app, thus allowing a bad actor to more easily exploit a targeted vulnerability. Protecting API endpoints from business logic abuse and other vulnerability exploits is thus a key API security mitigation requirement.
Data loss prevention
Preventing data loss over exposed APIs for appropriately privileged users or otherwise, either due to programming errors or security control gaps, is also a critical security requirement. Many API attacks are designed specifically to gain access to critical data made available from back-end servers and systems.
The API community continues to drive toward more standardized agreement on the optimal approach to security. To this end, industry groups such as OAUTH, for example, have proposed criteria requirements for API security that are quite useful. The most likely progression is that the software security community will continue to refine its understanding and insight into the full range of API security requirements in the coming years. Observers should thus expect to see continued evolution in this area.
API security methods
API abuse in action
By design, APIs are stateless, assuming that the initial request and response are self-contained, holding all the information needed to complete the transaction. Making program calls to an API directly, or as part of a mobile or web application improves user experience and overall performance. This makes it very easy for a bad actor to script and automate their attack as highlighted in two examples below
Account takeover and romance fraud: Zoosk is a well-known dating application. Bad actors decompiled the Zoosk app to uncover account login APIs. Using automation and attack toolkits, they then executed account takeover attacks. In some cases, compromised accounts were used to establish a personal relationship with another Zoosk user and, as the relationship blossomed, the bad actor requested money due to a sudden death or illness in the family. The unsuspecting user gave the money to the bad actor, who was never to be heard from again. Prior to implementing Cequence, romance scams at Zoosk averaged $12,000 with each occurrence. Now, they are virtually eliminated, resulting in increased user confidence and strengthened brand awareness.
Account takeover and financial fraud: Another example of APIs being targeted with an automated attack involves a large financial services customer finding that attackers had targeted its mobile application login API to execute account takeovers. If successful, the bad actors could attempt to commit financial fraud by transferring funds across the Open Funds Transfer (OFX) API. OFX, of course, is the industry standard API for funds transfer within the financial services community, and as such the APIs are publicly-available and well-documented to facilitate use.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.
This is third in a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection. Explosion of APIs The API explosion is also driven by several business-oriented factors. First, enterprises are moving away from large monolithic applications that are updated annually at best. Instead, legacy and new applications are being broken into small, independently functional components, often rolled out as container-based … More
This is the first of a series of articles that introduces and explains application programming interfaces (API) security threats, challenges, and solutions for participants in software development, operations, and protection.
Purpose of article series
Researching the wide range of API security alternatives can be confusing – even to seasoned experts. This article series is written with the goal of helping all types of readers better understand the pros and cons of the various modern approaches to protecting APIs from cyber security risks. The material is intended to help enterprise security and software development teams develop and maintain a consistent protection philosophy.
The target reader includes software developers who depend on and use APIs every day, as well as technical managers who might have responsibility for API security in their organization. The target reader also includes, however, technical-minded individuals possessing little experience with APIs, but who are nevertheless interested in the security aspects of this important issue. We try to describe the API security concepts in a manner accessible to each type of reader.
Introduction to APIs
The typical user of network and Internet services tends to think of computer interfaces in terms of screens, keyboards, monitors, and the like. These interfaces are the visible means by which systems exchange information with human users, and they have advanced rapidly in recent years. The touch screen from Apple, for example, emerged only a decade ago, and a generation of youngsters barely remembers what the world was like before such useful capability existed.
But there is another type of interface that exists in computing, perhaps more hidden to the everyday user. This other type of interface is how software programs communicate with one another. For many years, this process was poorly specified, with programmers inventing protocols for something called inter-process communication (IPC). An early operating system from Bell Laboratories called Unix, which now serves as the base of both Apple iOS and Android, made IPC designs easier, but they were non-standard.
By 2000, the industry decided that these software-to-software interfaces needed to become more open and standard. Such technical decision became the genesis of what we now refer to as an application programming interface or more commonly – API. Recognize that an API provides a standard interface through which two software programs, also referred to commonly as processes, can communicate, share messages, or managed shared memory.
More specifically, an API is an interface which makes software services available to workloads or applications for bidirectional communication and message sharing. APIs are also commonly used to share memory between different processes. An API is stateless in nature, and will commonly include all the information needed to complete a transaction, unlike a web form that may require multiple transactions for processes like user registration.
Figure 1. General API model
Unix Operating System IPC
Roughly half a century ago, researchers Ken Thomson and Dennis Ritchie of Bell Laboratories initiated a project to build a multitasking operating system for use inside AT&T. Despite such relatively modest original goals, the so-named Unix software and associated design philosophy that they produced have served as the technical base for virtually every successful commercial operating system since. Linux and Android are direct derivatives, whereas iOS and Windows are massively influenced by Unix.
An important design consideration for the Unix operating system involved the need to create an IPC mechanism that would allow for data sharing and message passing between computer programs. Thompson and Ritchie were influenced by many rapidly evolving technical concepts being designed at the time in the computer science community. This included the emergence of producer-consumer models, as well as new methods for distributed computing.
The Unix IPC approach can be viewed as an early attempt to address many of the issues now covered by APIs. Both are concerned with the need to modularize, standardize, and simplify the manner in which data or messages are shared between cooperating processes. The big difference, obviously, is that modern APIs benefit from the massive scale that comes with the Internet. Original Unix efforts were local and operating system-specific.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.
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.
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.
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-srcdirective 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-srcdirective 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-srcdirective 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-srcdirective in CSP blocks font downloads from any unwanted or potentially malicious sites.
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.
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.
Figure 2. Commercial client-side security lifecycle
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
Figure 3. Magecart Card Skimming
Contributing author: Aanand Krishnan, CEO, Tala Security.