Almost all cybersecurity issues can be attributed to two underlying causes: a technical one and a non-technical one. The technical issue is the lack of clear separation between code and data and the non-technical issue is the end-user, and how individual browsing habits can expose end users to attacks. In this blog, Tala VP of Engineering, Sanjay Sawhney explores how these issues lead to all kinds of security headaches.
From a security standpoint, all bets are off when code comes masquerading as data. Without strict separation of program instructions from user-generated input, attackers can inject malicious code into snippets of data, from where it’s able to execute freely.
This lack of separation has led to some of the biggest cybersecurity headaches of the last 20 years: Buffer overflow, SQL injection, Cross-Site Scripting (XSS) and everything that comes to a user’s browser today. Let’s take a look at some of the exploits before moving on to the impact of human behavior.
Buffer Overflow / Buffer Overrun
The buffer overflow vulnerability has, historically, been a major source of chaos for all security professionals. In its simplest form, a cleverly crafted input (let’s call it data) can get into program areas adjacent to a buffer known to hold executable code and modify it with malicious code or alter the flow/state of the program.
Exploits of this vulnerability have manifested in some shape or form since the late 1980s: Morris Worm (1988), CodeRed (2001), SQL Slammer (2003), Sasser (2005), Conficker (2008-09), Stuxnet (2009-10 with several zero-day overflows), Flame (2010-12). This vulnerability caused so much pain that even chip vendors started supporting an NX (No Execute) bit for memory pages that were supposed to hold nothing but data. Even today, vulnerabilities have been found in WhatsApp and NVidia Shield TV, among others.
SQL injection (the placement of malicious code in SQL statements, via web page input, aka data) is another issue that stems from the lack of separation of data and code. This was supposed to have been resolved ten years ago, according to WAF and code analysis tool vendors. If that’s the case, why do we still have a SQL Injection Hall of Shame?
Cross-site Scripting (XSS)
What about the mess that comes to any browser connecting to a website today? It’s lots of code, not just data. Even more interesting is the fact that only a third of this code comes from the actual website whereas two thirds (tag management, social media connectors, audio/video integration, form builders) comes from outside the administrative domain of the website. So, what are the problems that result from this mess?
Cross-site Scripting (XSS) involves the injection of malicious scripts into otherwise benign and trusted websites. Because a single XSS vulnerability compromises the domain on which it occurs, it’s a popular exploit with cybercriminals and fraudsters. Once again, this happens at the point where user input (data) meets code (the web application). The flawed application uses input from the users within the output it generates, without validating or encoding it - enabling malicious actions to be executed. XSS is the No.1 web vulnerability exploited today.
Reflected XSS attacks typically involve a malicious link that’s sent to the user. This embeds a malicious script which isn’t sanitized by the end server and is sent back to the end user’s browser session, where it executes.
Persistent XSS attacks involve the storing of the script on the server side (usually a database, message forum, comment field etc), masquerading as legitimate content. Typically, the attack happens in web apps where the end user submits input through which the script is injected.
To bring some semblance of order to this tangled web, experts in the web security domain pushed for browser-enforced controls that differentiate between legitimate and illegitimate sources of code, data and resources via standards such as CSP, SRI, Feature Policy, iframe sandboxing.
The Human Factor
Technical solutions can help us a lot but aren’t enough to counter a major non-technical issue: end-user behavior. Each user is wired differently. Some are suspicious of everything online and don’t click on random offers from their “Great Great Grandfather who has left them a fortune which they could collect by providing wiring instructions to their bank account.” Others fall for the “Free $500 Amazon gift card.” Either way, the exploit is based on our tendency to click without thinking or the lure of a free lunch - and it’s a tendency that’s extensively exploited by an entire community of hackers and vendors with business models built on collecting personal data.
Let’s take a look at some examples:
Data exfiltration involves enticing users to click on a well-disguised malicious link (special offer, etc) on a web page or in an email. Personal information could leak by some of these vectors: query parameters in http(s) get requests, referrer header with query parameters, http posts etc.
The leaked information is often UUEncoded, encrypted or partly hashed - but let us be very clear that full ID can be easily reconstructed. The best defense against such deliberate or inadvertent tracking or exfiltration is for the website folks to proactively understand the data collection practices of third parties and to limit the exposure of sensitive data in forms to third party libraries.
Clickjacking (as defined by OWASP), 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 the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another, most likely owned by another application, domain, or both. One of the main defenses against clickjacking is to use a CSP policy with frame-ancestors directive that whitelists legitimate sites that can frame/iframe a given site.
The image below shows how links in web based email can be used to track users. If I hover over “Register Now” in the email, I can see the URL (at the bottom of the image) that’ll be instantiated when I click on that portion of the email. The query parameters of the link include my email address - the sender didn’t even bother to obfuscate or hash it.I am probably a more advanced user but a vast majority of end users may not be able to detect such deceptions and tracking mechanisms that are out there.
UI based attacks/tracking are much harder for end users to detect on mobile platforms where screen real estate is limited and there’s a lack of a security indicator (e.g. in the Android GUI). Deceptive UI attacks (such as tapjacking, likejacking, sharejacking, cursorjacking, tabnabbing) have been extensively researched in this brief. A variety of attack vectors (some previously known, others novel, such as a non-escapable fullscreen overlay) allow a malicious app to surreptitiously replace or mimic the GUI of other apps and mount phishing and click-jacking attacks. Limitations in the Android system GUI make these attacks significantly harder to notice than on a desktop machine, leaving users completely defenseless against them.
In general, proactive platform/browser controls can definitely limit such attacks but not completely eliminate them because one cannot predict each user’s behavior in the event of deceptive screen overlays.
An Ongoing Challenge
Without strict separation of program instructions from user-generated input, attackers can inject malicious code into snippets of data, from where it’s able to execute freely. That’s why attacks like the ones I’ve just described will continue to be a challenge for businesses.
And while you can’t legislate for individual developers or end users, the good news is that we have browser-native controls that can help you to proactively defend your website from these attacks, including CSP, SRI, Feature Policy and iFrame sandboxing.