Client-side vulnerabilities and their reduction

This subsection examines how attackers can exploit weaknesses that arise in the user’s interaction with web browsers and mobile devices. These are so‑called client-side problems, as opposed to server-side ones. The client side also includes challenges resulting from the trend of storing increasing amounts of data on the client rather than the server. In addition, some physical attacks are discussed.

Phishing and forged links, buttons, and images

Both web and mobile user interfaces contain weaknesses that make it easier for attackers to mislead users. At the root of the problem are users’ difficulties in checking URL addresses and the dynamic content of HTML documents.

Phishing

Previous module has already introduced phishing attacks and their ecosystem. Here we examine the deception technique. The basic idea is to make the user enter sensitive information—especially credentials—into a location controlled by the attacker. To direct the user to such a place, they are sent, via some message or webpage, a link that appears to them as something worth following (due to necessity, interest, etc.). The target, usually a website, must also appear genuine even though it is created by an attacker (e.g., visually a copy of a real one). Commonly faked web pages, or sites, that belong to services of social media, web banks and other payment processors.

To make the forged site look as authentic as possible, an attacker may use JavaScript to modify the browser’s address bar to display an image of a genuine URL or replace the original address bar with a new one. Phishers also exploit homograph attacks enabled by Internationalized Domain Names (IDN). Such an attack is based on the fact that different alphabets have similar-looking characters (homoglyphs). For example—even without IDN—the letters “l” and “I” (lowercase L and uppercase i) are hard to distinguish (and so can be even ”m” and ”rn”). By replacing—using IDN—the Latin “a” with the Cyrillic “а”, the URL pаypаl.com becomes deceptive (try Ctrl‑F for paypal on this page). Attacks involving manipulated URLs and address bars are especially difficult to detect on mobile browsers because the address bar is not visible during normal browsing. Likewise, even if the bar is visible, the URL may not fit entirely inside it. Website phishing is one of the most common attacks, and most human users find it difficult to detect phishing URLs and sites.

Common countermeasures include awareness campaigns and phishing-related training. These aim to draw attention to the possibility of phishing and teach users to recognize phishing URLs. Modern browsers also use technical security measures such as blacklists and visual indicators that highlight the top-level domain of a URL. For example, Google Chrome displays URLs in a way that reveals deceptive characters in IDN attacks.

Example of another kind of URL problem:The link
https://bestbank.secure.server.cоm
may lead a user to believe they are navigating to some server section of bestbank.secure. However, the link actually leads to the server.cоm site, under the section bestbank.secure. In addition, here cоm≠com, but such a top‑level name would not be registered.

Drive-by-download attacks

When a user visits a website or clicks a link or attachment in a phishing message or a malicious pop-up window, a drive-by-download attack may occur. These are a common problem on the web and play a significant role in phishing. Instead of delivering the intended website, the attack downloads and installs malware on the user’s computer. The attacker must determine the victim’s computer fingerprint. It is used also as part of ordinary web communication to infer software components on the computer. If there are vulnerable ones, e.g. old versions, the attacker knows how the malware may be possible to install. Detecting such attacks is an active research area and includes approaches such as anomaly detection and the use of malware signatures.

Forged links, buttons, and images

In clickjacking, attackers manipulate the layout of a webpage to trick users into clicking a link, button, or image that appears appropriate (attractive, useful, etc.), but the click actually affects a concealed target on the original site underneath. Clickjacking is also known as a user interface redress attack and belongs to the class of confused deputy attacks. The attacker “dresses” layers over the original webpage (transparent layers are also possible) and causes the victim to trigger actions on the original website. The attack is executed on the attacker’s crafted site, which uses an iFrame to load the target site (the “deputy”) and can exploit absolute positioning of iFrames for correct visual alignment. Thus, victims have difficulty noticing the attack elements through the real website. Clickjacking attacks are especially dangerous if the victim is already logged in and using a settings page, where—misled by the attacker—they may perform actions they did not intend. One of the most notable clickjacking attacks targeted Adobe Flash’s settings page. Attackers used invisible iFrames to trick victims into altering the security settings of the extension, granting attackers access to the victims’ microphones and cameras.

Clickjacking can be used to launch other attacks against websites and users, such as Cross-Site Request Forgery and Cross-Site Scripting attacks. Both desktop and mobile browsers are affected.

A clickjacking attack is not a programming bug but a conceptual problem in JavaScript. Therefore, countermeasures are not trivial. Detection and prevention can be performed on both server and client sides. Browser users may disable JavaScript and iFrames to prevent attacks. Since this would break many websites, various browser extensions (e.g., NoScript) allow controlled execution of JavaScript on the user’s behalf. To mitigate the effects of clickjacking, users should log out of online accounts when leaving a website, though this is impractical. To block clickjacking on the server side, website developers must ensure that the site cannot be framed; that is, it should not load if inside an iFrame. A site may include JavaScript code that detects if it is being framed and then breaks out of the iFrame. This defense technique is called FrameBusting. Because users may have disabled JavaScript, the method is not fully reliable. The recommended server-side defense mechanism is correctly setting the HTTP response header. The X-FRAME-OPTIONS header can be set to DENY, preventing the site from loading inside an iFrame.

Phishing and clickjacking on mobile devices

Phishing and clickjacking are not limited to browsers and the web. Mobile app users are vulnerable to both. Researchers have demonstrated the possibility of an end-to-end style phishing attack in which an attacker gains full control of the interface by abusing Android’s Instant App feature and password managers to steal login credentials. There is also the Cloak & Dagger attack, where holding just two permissions is enough for a malicious application to take over the entire UI loop. The attack enables advanced clickjacking, keylogging, stealthy phishing, and the covert unlocking of the device.

Data stored on the client

Client-side storage refers to areas provided by the browser or operating system for websites or mobile applications. Storage is therefore local and does not require server-side resources or an active Internet connection. Because malicious users can manipulate stored data, client-side storage areas must be protected. We consider the issue separately for browsers and mobile devices.

In the browser

Historically, client-side storage in browsers has been used only for storing cookies. However, cookies cannot be used to store large or complex data. With HTML5, more powerful and versatile alternatives exist. These include WebStorage, similar to cookies and storing key–value pairs, and IndexedDB, which functions like a noSQL database and can be used to store documents, other files, and binary large objects (blobs).

To ensure the integrity of sensitive information, such as session data, developers are advised to cryptographically sign the data stored on the client and verify it when retrieving it.

In addition to integrity, another storage-related consideration with WebStorage and IndexedDB is that stored data is not automatically cleared when users leave the website. For session‑like storage, web developers are advised to rely on the sessionStorage object in the WebStorage API.

In mobile applications

Mobile storage security also depends on the type of data and the storage mechanism. For example, an application may use private storage or shared storage such as an SD card. Developers are encouraged to sign and encrypt sensitive information and apply appropriate sanitization of user input. This is especially important for shared storage, which lacks protected access control—unlike an application’s private storage area.

Leakage of sensitive data in Android applications has been studied. For example, in an examination of 1,100 popular Android apps, a significant number were found leaking sensitive user data into publicly readable storage such as log files and SD cards. It has also been found that some sensitive data leaks are intentional, enabling the information to be passed to another cooperating malicious app.

Physical attacks

Physical attacks aim to exploit errors and weaknesses arising from device use.

Smudges on touchscreens

In a smudge attack, an attacker attempts to learn passwords, PIN codes, or patterns entered into a touchscreen device. When authentication information is entered with greasy fingers, traces remain on the screen. By using suitable cameras and image processing software, the attacker can recover the smudge traces and infer information from them. The attacker needs a clear view of the target screen.

Shoulder surfing

Shoulder surfing is a physical attack in which an attacker attempts to obtain confidential information such as passwords, PIN codes, unlock patterns, or credit card numbers. The attacker needs a clear view of the target screen. The attack can be performed either directly by looking over the victim’s shoulder or from a distance using tools such as cameras or telescopes. These attacks are dangerous for mobile device users when they authenticate to the device or network services in public places such as trains, stations, and airports.

Question 1

What is an IDN attack?

A forged link is sent to the victim by email.

Character encoding is used to make the phishing address appear identical to the address of the genuine site.

The attacker replaces the original address bar with a new one.

The manipulation of the address bar is targeted at mobile browsers so that it is harder to detect.

Question 2

What is clickjacking based on?

An iFrame containing e.g. malware is injected into the target site.

Overlay elements are used to make the victim click desired elements on the attack site.

A vulnerability in JavaScript.

The target site is loaded into an iFrame on the attacker’s page.

Question 3

The protection of client-side storage

is the responsibility of the client.

is important to allow the server to verify during retrieval that the data has not been altered.

requires that session data not be stored on the client.

is important in order to transmit sensitive information to a malicious application.

Question 4

Select all correct statements.

A drive-by-download attack downloads and installs malware on the user’s computer.

Phishing and clickjacking are not problems on mobile devices.

On mobile devices, physical attacks can also cause security problems.

A clear view of the target screen helps the clickjacking attacker.

A server can be protected against iFrame attacks using appropriate settings.

Blacklists can be used to reduce phishing attacks.

Posting submission...