Spoofing is a common attack type targeting humans as well as computer systems. Let's see what forms it can take.

Spoofing is the first threat type (the ‘S’) in the STRIDE threat model that has been adopted by much of the application security community. A spoofing attack abuses an existing trust relationship between the target and an (legitimate) entity by falsifying data in the trusted entity’s name.

Due to the deception-focused nature of spoofing, its primary targets are the system’s legitimate users. Many attack patterns make use of social engineering techniques such as pharming or phishing – these are considered out of scope from a software security standpoint.

Aside: ‘WHO are you’ vs. ‘who are YOU’

A common misunderstanding is confusing (or conflating) authentication and authorization and their relevant threats. In an authentication function, an entity can prove its identity in a verifiable manner. In an authorization function, the system decides on whether an entity has access to a particular resource or function. In STRIDE, the threat for authentication is Spoofing, and the threat for authorization is Elevation of Privilege.

As an aside, the difference in risk between Spoofing and Elevation of Privilege-type threats is reflected in the OWASP Top Ten: Broken Authentication is #2, while Broken Access Control is ‘only’ #5!

The many faces of spoofing

Unsurprisingly, all aspects of communication can be spoofed by an attacker. In most cases, the ultimate goal is to mislead, trick, or manipulate a legitimate user of the system. CAPEC defines the main types of spoofing as:

• Identity spoofing: Perhaps the most well-known subclass of spoofing. The attacker pretends to be a different entity by stealing or faking authentication credentials. The attacker can also exploit a weakness in the communication to make a message look like it was sent by someone else. This can be caused by a large variety of vulnerabilities related to authentication.
• Content spoofing: The attacker modifies the content displayed to the victim (originally from a legitimate entity) to mislead the user, and possibly even expose them to malware. This attack is made possible by weaknesses in verifying data authenticity.
• Resource location spoofing: The attacker falsifies a location of a resource used by the system, forcing it to use a malicious version of the resource controlled by the attacker instead. This enables attacks such as DLL hijacking and path traversal, but the attacker can also leverage it to mislead the user and carry out phishing attacks.
• Action spoofing: The attacker tricks the user into performing anaction without being aware of it – or making them think they performed a different action altogether. Clickjacking and CSRF are typical examples of this attack.
• Manipulation of human behavior: The attacker deceives or manipulates the user into interacting with the system in a way that benefits the user, usually through social engineering. From a technical standpoint, such attacks can be made possible by the UI misrepresenting critical information.

The user interface, in general, is an underestimated part of an application’s attack surface. Depending on how it’s implemented, there can be many ways it can be abused to trick or mislead the user. Some examples related to Unicode (see Unicode Technical Report #36) include bidirectional text spoofing which works by abusing control characters that set text direction, and script spoofing / homograph attacks which abuse identical-looking Unicode characters to confuse a user.

Two factors are better than one

In general, the best way to protect against spoofing attacks is to put the systems in question (user authentication, data authenticity, file handling, UI) under heavy scrutiny and review.

Authentication functionality in particular should be reviewed – both on the design and code level – for potential weaknesses. Just as OWASP suggests, it is always a good idea to rely on multi-factor authentication just in case one of the factors becomes weak or vulnerable. Other spoofing attacks are enabled by vulnerabilities (CSRF, path traversal, insufficient data authenticity) that can be mitigated by fixing the core issue. On the UI level, the Unicode consortium itself has recommendations about mitigating visual Unicode-based spoofing.

Of course, many spoofing attacks have a social engineering aspect. To protect against it, users should be made aware of social engineering techniques via cyber awareness training. We discuss spoofing attacks and proper authentication methods to protect against them in all of our courses.