Authentic8 Blog Author: Guest Contributor

By Derek Handova

Content management systems present attractive targets for cybercriminals and state-sponsored adversaries. E-commerce sites, investor relations pages, and HR portals are just three examples where CMS vulnerabilities can cause severe reputational and financial harm.

The CMS offers multiple attack surfaces for targeting commercial or public sector entities. How can IT, administrators, creative personnel, and developers ensure CMS security?

In 2018 alone, more than 18 million CMS users suffered security breaches. 73.2 percent of well-known websites managed with WordPress, the most widely used CMS, contained vulnerabilities exploitable through common attacks.

Which security approaches would effectively protect CMS owners, their network, their business, and their customers? To answer this question, we have to confront the issue that many data breach vulnerabilities lie within the surface layer of the websites themselves.

There, threat actors can insert malicious code without website owners even knowing about it. For example, RiskIQ recently reported that JavaScript vulnerabilities in CloudCMS and Picreel web service scripts allowed the

In a new report titled Malicious Injections: The Tip of the Spear for Browser Threats, researchers with security firm RiskIQ predict that browser-based attacks will be a significant portion of the threat landscape for years to come, and will continue to cause major problems.

What do these attacks all have in common? Malicious injects targeting locally installed browsers. “Internet browsers are proving an invaluable attack vector for criminals,” the report concludes.

The point of injecting malicious scripts is to have the local browser dutifully execute code on the user’s machine. Attackers aim either to inject a piece of script into a web page directly or to inject a remote script (resources) into the page.

The report documents the top six techniques that they use to achieve either direct and remote injects:

Tacking it On

This is the most common method of adding malicious code to a page and can be done by injecting a malicious script in a <script>

WebAssembly, a newer type of “low-level” code that can be run by modern web browsers, is aimed at improving the web experience. The catch: Regular browsers execute such code locally. WebAssembly - merely a faster way for web-borne exploits to reach the local browser?

WebAssembly (WASM) is currently supported by major browsers including Firefox, Chrome, WebKit/Safari, and Microsoft Edge. Because the browser is running the WebAssembly code locally, any problems with that code also end up on the user’s machine and potentially pose a threat to the local IT environment.

How does WebAssembly work? WASM is not a high-level language. It is a way for language compilers (like those that read C, C++, and Rust high-level code) to express their assembly-level output in a different format. This output then can be directly executed by the browser.

Source: LogRocket Blog

By itself, WebAssembly code isn’t supposed to be able to do anything. It’s run inside a sandboxed virtual machine.