Variant · Low-Medium

CWE-293: Using Referer Field for Authentication

The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

CWE-293 · Variant Level ·1 Mitigations

Description

The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

Potential Impact

Access Control

Gain Privileges or Assume Identity

Demonstrative Examples

The following code samples check a packet's referer in order to decide whether or not an inbound request is from a trusted host.
Bad
String trustedReferer = "http://www.example.com/"while(true){n = read(newsock, buffer, BUFSIZE);requestPacket = processPacket(buffer, n);if (requestPacket.referer == trustedReferer){openNewSecureSession(requestPacket);}}
Bad
boolean processConnectionRequest(HttpServletRequest request){String referer = request.getHeader("referer")String trustedReferer = "http://www.example.com/"if(referer.equals(trustedReferer)){openPrivilegedConnection(request);return true;}else{sendPrivilegeError(request);return false;}}
These examples check if a request is from a trusted referer before responding to a request, but the code only verifies the referer name as stored in the request packet. An attacker can spoof the referer, thus impersonating a trusted client.

Mitigations & Prevention

Architecture and Design

In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Use other means of authorization that cannot be simply spoofed. Possibilities include a username/password or certificate.

Detection Methods

  • Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Taxonomy Mappings

  • CLASP: — Using referrer field for authentication
  • Software Fault Patterns: SFP29 — Faulty endpoint authentication

Frequently Asked Questions

What is CWE-293?

CWE-293 (Using Referer Field for Authentication) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.

How can CWE-293 be exploited?

Attackers can exploit CWE-293 (Using Referer Field for Authentication) to gain privileges or assume identity. This weakness is typically introduced during the Architecture and Design phase of software development.

How do I prevent CWE-293?

Key mitigations include: In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Use other means of authorization that cannot be simply spoofed. Poss

What is the severity of CWE-293?

CWE-293 is classified as a Variant-level weakness (Low-Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.