Being aware of the threats that lurk out there is mandatory in order to know how to defend against them. Since applications are getting more sophisticated and a lot more technologies are brought in the game, new attack vectors arise. Here are 4 lesser-known attacks and vulnerabilities, new and old, that you have most likely not stumbled upon.

Repudiation attacks

Repudiation attacks aim to deprive the application and/or accompanying components of properly registering a user’s activity. Such attacks can occur at any level (web server, application, network infrastructure, etc.) and their goal is to cover up either an ongoing attack or one that is generally not meant to be discovered. This is achieved by eliminating the possibility for tracking one’s actions against the target system (access logs, event logs or other).

Attack scenario against the Apache web server:

  1. A malicious third-party uploads a web shell on the server;
  2. The attacker’s web shell executes the malicious content and sends the result to a remote (attacker controlled host);
  3. The attacker ensures that the process which handles the request is terminated after the malicous content is executed;
  4. Apache fails to log the request in either the access or error log since the process did not finish gracefully.

How does this work? Assume the following PHP snippet:
Alt text

The process is terminated before it could serve content to the end-user. Therefore Apache would not log the request. From its docs:
Alt text
Prerequisites for the attack:

  • Apache must be run with prefork MPM
  • PHP must be ran as an Apache module (mod_php)

References / Credits:
Do Apache access logs ever miss requests

Relative path overwrite (RPO) and path-relative stylesheet imports

Relative path overwrite was written about back in 2014 by Gareth Heyes, yet it has not been popularized enough yet. RPO attacks aim to overwrite relative paths (URLs) to attacker control resources or payloads. The attack makes use of how browsers and web applications interpret relative paths and as a result can allow for the injection of arbitrary CSS styles.

A simple usage of a relative path could be the following:
<link href="styles.css" rel="stylesheet" type="text/css" />

Depending on how resources are loaded, certain applications may fail to load a relative-path resource if it’s requested from a different URL that is otherwise not meant to be used. For instance, leaving a trailing slash may provoke the application to misbehave and result in a 404 for all resources requested via a relative path.

PortSwigger later on coined the term “Path-relative Stylesheet Import” (PRSSI) and further elaborated on how this attack technique could be utilized to have an even greater impact (for example stealing CSRF tokens, stealing cookies, creating keyloggers, etc). The vulnerability first hit the phpBB3 bulletin board and was assigned CVE-2015-1431. To provide a better insight into the practical part of this attack type, the following CSS can be used as a sample payload:
%0A{}*{color:red;}

Which ends up forming the following URL address:
http://example.com/phpBB3/search.php/%0A{}*{color:red;}///

Ultimately, the injected CSS style is parsed and all elements on the page would have their font color changed. How can this be exploited? For one. it can be used for UI redressing attacks (a.k.a clickjacking) and two, depending on the application it could “extract” elements from the DOM and send them to an external host, essentially hijacking session-related information. Under certain browsers such as IE and certain other prerequisites, expressions could be used to execute Javascript as well.

References / Credits:
Detecting and exploiting path-relative stylesheet import (PRSSI) vulnerabilities
The Spanner - RPO

Cross-site frame leakage (CSFL)

The most recent of all on this list is the cross-site frame leakage attack (CSFL) which was demonstrated in March, 2019 as a side-channel attack against web applications. The attack showcased how it’s possible to obtain sensitive information regarding an external host using the window frames property in Javascript. It was PoC’d against Facebook’s Messenger and proved that based on the number of iframe elements on the page, it was possible to deduce whether you have been in contact with a specific person or not.

CSFL exploits the cross-origin properties of iframe elements to draw conclusions of whether or not (depending on the application) sensitive information could be retrieved. Cross-site frame leakage works by having the user visit a malicious website from which he is redirected to a new window that observes the window.frames property. By analyzing the conditions under which Messenger was creating iframe elements, it was possible to determine whether or not the application is in a specific state.

The following is a PoC of how the frames are count while the background tab redirects to Messenger:

const recorder = setInterval(() => {  
   pattern.push(backgroundTab.frames.length);  
}, 0);  
setTimeout(() => {  
   // Stop the recorder  
   clearInterval(recorder);  
   // Output the result  
   console.log(hasDrop(pattern) ? 'Not in Messenger contacts' : 'In Messenger contacts');  
}, 6 * 1000);

The full proof-of-concept can be found on the author’s repository: https://gist.github.com/masasron/1beca41f42599db1c6d48a89e135f653

Of course, this is not a unique exploitation that would fit in every case, simply because it is specifically meant to address the behavior of Messenger and how it stores (or used to store) most of its content in iframes. In addition to that, a bit of a social engineering is also required in order to have the end user visit an external, attacker-controlled, host.

A visual representation of the attack flow is given below (credits Ron Masas @ Imperva):
Alt Text

Since the application cannot do much (at least not practically useful) to prevent this, the best mitigation would be to get rid of all iframes as the browser allows certain properties to obtain information about them.

References / Credits:
Mapping Communication Between Facebook Accounts Using a Browser-Based Side Channel Attack

Reverse tabnabbing

Reverse tabnabbing occurs when an application creates insecure links to cross-origin destinations. The attack works by exploiting a badly created link originating from a trusted website to a remote one that has been compromised. This attack type can be often be seen used in conjunction with waterholing. Consider the following HTML link that can be found on a trusted website (let’s say a-legit-website.com):
Our partners

The link points to another host - example.com by specifying a target loading location. A prerequisite for the attack to work would be to have the website at example.com compromised. Redirecting the end user to a new tab (using target=_blank) means that the foreign host will now have access over the window object of the originating host using the window.opener property.

Graphical overview of the attack (credits OWASP):
Alt Text

Having access to the window object of the source page, it would be possible for the compromised web application to redirect the end-user to another malicious website or depending on the circumstances the attack vector may also include: rewriting content on the page, spoof links and others.

References / Credits:
Reverse Tabnabbing at OWASP
Links to cross-origin destinations are unsafe