Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

5/20/2020
02:00 PM
Ido Safruti
Ido Safruti
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Digital Transformation Risks in Front-end Code

Why making every front-end developer a DevSecOps expert will lead to a more holistic approach to web and native application security.

One important, often overlooked, area for empowering developers with security tools and capabilities is front-end code. Front-end code is mostly JavaScript and HTML. It is the closest to the user and runs on their browser or inside their hybrid mobile applications. Companies are constantly changing their front-end code because websites and applications require frequent refreshes. There is also a high volume of vulnerabilities and security issues reported on front-end code, in part because it is easier to access and attempt to penetrate front-end code.

Digital transformation is tightly tied to the front end, the accessible face of every business in the modern era. Surveys of developers demonstrate widespread popularity of front-end coding languages. In the 2019 StackOverflow developers' survey, 69.7% of professional developer respondents listed JavaScript as their most commonly used programming language. Right behind in second place was HTML/CSS with 63.1%. According to the HTTP Archive, the number of JavaScript kilobytes requested per page loaded has increased over the past decade by 408% for desktop devices and 689% for mobile devices. This clearly demonstrates the growing reliance of web applications on JavaScript. 

Increasingly, front-end code relies on third-party code components provided by vendors and open source projects. This code does not sit in the application. Rather, it is fetched and loaded dynamically by the browser. Using third-party code makes sense in a lot of ways. It allows developers to leverage existing code that is useful, saving them development time.

Unfortunately, some of the most serious cybersecurity attacks target front-end code. Magecart attacks, for example, are executed when malicious hackers inject unauthorized front-end code into an application or modify the application's front-end code. This injected modified code, called a skimmer, collects users' financial information when they try to make a purchase. Magecart attackers abuse vulnerabilities in third-party vendors used by the application or first-party code written by your own developers that allow code modifications and the insertion of skimmers. These attacks often inject minor code modifications, which make them hard to spot with basic code reviews.

How DevSecOps Can Protect Front-end Code
Understanding the intent of code you do not control and can't see is challenging. This is the primary problem of policing third-party libraries for security risks. To tackle these, you need to adapt a two-pronged approach. You need to enable early detection of risks and vulnerabilities during integration time, but you also need to maintain the safety net of a runtime detection engine that monitors live scripts as they run on actual users' browsers and detects unauthorized changes.

To allow developers to test these libraries far earlier, we need to add tools to CI/CD pipelines that can peer inside the library code and validate the code has not been altered to carry malicious payloads like Magecart. At the same time, we need to run user-testing and client-testing of applications as they are being built. More granular testing of how applications should behave in the browser earlier in the process will allow developers to establish a baseline of "known and acceptable app behaviors."

This baseline can then be compared against how code and applications are behaving in production. In fact, security teams can run automated systems that perform deep analysis of thousands of factors identifying behavior deviations from the baseline. Deviations might be caused by new libraries or code that were not added through the standard CI/CD and automated code review process or behavior changes by third-party vendors and libraries. Changes in third-party code may be planned by the vendor due to updates and enhancements. However, these changes may have happened or, in other cases, may be due to an attacker managing to inject malicious code.

Lastly, deviations from baseline might result from changes to your own code that was modified without authorization by hackers, disgruntled employees, or well-meaning employees trying to fix something and bypassing the code and security processes to speed up their work.

This type of baseline testing would identify Magecart attacks very quickly and before they do significant damage. The testing will only work well, however, if developers make recording application behavior prior to deployment a regular part of their work practice. That's really the key - making sure that for developers' front-end security is not tedious and adds minimal work.

How This Might Work in Practice
The good news? Adding security checks and validations to CI/CD pipeline tools and platforms is straightforward, more like adding a new type of quality assurance to the existing suite of tests. Doing this does not take the developers out of their existing workflows, so it has little impact on their productivity. It also does not require additional hours or workers on the information security team.

Here's how the process might flow.

  1. A developer checks their latest code into their version control system (like GitHub). Before the new code is integrated into the main branch of the application code, the new code will be automatically built and tested with a set of security checks.
  2. If a security flaw is detected in the code or any of the libraries or third-party modules that the code is using, then the version control system automatically flags the specific lines of code under question and generates a ticket to the developer calling for additional quality assurance along with suggested remediation steps.
  3. The developer sees the ticket in their normal ticket queue and makes the fixes.
  4. The code is then run through the test suites again. It will be merged into the main branch of code if all tests pass and then deployed into production.
  5. The updated application runs in a staging environment for analysis to create a baseline of accepted behaviors that can be checked in an automated fashion against actual live behaviors.

Making every front-end developer a DevSecOps expert creates a far more holistic approach to web application and native application security. This approach is more proactive and preventative - and a lot less expensive and time-consuming over the long haul. Adopting a DevSecOps approach is only one part of a broad and inevitable transition for all developers toward assuming more responsibility for application security - and creating a world where security starts with the code.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's featured story: "The Entertainment Biz Is Changing, But the Cybersecurity Script Is One We've Read Before."

Ido Safruti is a co-founder and CTO at PerimeterX, provider of application security solutions that keep businesses safe in the digital world, detecting risks to web and mobile applications and proactively managing them. Previously, Ido headed a product group in Akamai focused ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/3/2020
Data Loss Spikes Under COVID-19 Lockdowns
Seth Rosenblatt, Contributing Writer,  5/28/2020
Abandoned Apps May Pose Security Risk to Mobile Devices
Robert Lemos, Contributing Writer,  5/29/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13792
PUBLISHED: 2020-06-03
PlayTube 1.8 allows disclosure of user details via ajax.php?type=../admin-panel/autoload&page=manage-users directory traversal, aka local file inclusion.
CVE-2020-3339
PUBLISHED: 2020-06-03
A vulnerability in the web-based management interface of Cisco Prime Infrastructure could allow an authenticated, remote attacker to conduct SQL injection attacks on an affected system. The vulnerability is due to improper validation of user-submitted parameters. An attacker could exploit this vulne...
CVE-2020-3353
PUBLISHED: 2020-06-03
A vulnerability in the syslog processing engine of Cisco Identity Services Engine (ISE) could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to a race condition that may occur when syslog messages are processed. ...
CVE-2020-13379
PUBLISHED: 2020-06-03
The avatar feature in Grafana 3.0.1 through 7.0.1 has an SSRF Incorrect Access Control issue that allows remote code execution. This vulnerability allows any unauthenticated user/client to make Grafana send HTTP requests to any URL and return its result to the user/client. This can be used to gain i...
CVE-2020-13790
PUBLISHED: 2020-06-03
libjpeg-turbo 2.0.4, and mozjpeg 4.0.0, has a heap-based buffer over-read in get_rgb_row() in rdppm.c via a malformed PPM input file.