Difference between revisions of "Using referer field for authentication or authorization"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 
+
<br>
__TOC__
+
 
+
 
[[ASDR Table of Contents]]
 
[[ASDR Table of Contents]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
==Description==
 
==Description==
 
 
The referrer field (actually spelled 'referer') in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.
 
The referrer field (actually spelled 'referer') in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.
  

Revision as of 09:27, 19 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



ASDR Table of Contents

Last revision (mm/dd/yy): 02/19/2009

Description

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

Consequences

  • Authorization: Actions, which may not be authorized otherwise, can be carried out as if they were validated by the server referred to.
  • Accountability: Actions may be taken in the name of the server referred to.

Exposure period

  • Design: Authentication methods are generally chosen during the design phase of development.

Platform

  • Languages: All
  • Operating platforms: All

Required resources

Any

Severity

High

Likelihood of exploit

Very High

The referrer field in HTML requests can be simply modified by malicious users, rendering it useless as a means of checking the validity of the request in question. In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used.


Risk Factors

TBD

Examples

In C/C++:

sock= socket(AF_INET, SOCK_STREAM, 0); 
...
bind(sock, (struct sockaddr *)&server, len) 
...
while (1)
newsock=accept(sock, (struct sockaddr *)&from, &fromlen);
pid=fork();
if (pid==0) {
  n = read(newsock,buffer,BUFSIZE);
...
if (buffer+...==Referer: http://www.foo.org/dsaf.html)
//do stuff

In Java:

public class httpd extends Thread{
  Socket cli;
  public httpd(Socket serv){
    cli=serv;
    start();
  }
  public static void main(String[]a){
  ...
  ServerSocket serv=new ServerSocket(8181);
  for(;;){
    new h(serv.accept());
  ...
   public void run(){
     try{
       BufferedReader reader
         =new BufferedReader(new InputStreamReader(cli.getInputStream()));
       //if i contains a the proper referer.
 
      DataOutputStream o= 
         new DataOutputStream(c.getOutputStream());
      ... 

In J2EE:

Any J2EE program that uses

HttpServletRequest.getHeader("referer")

to make a decision is also vulnerable.


Related Attacks


Related Vulnerabilities


Related Controls

  • Design: Use other means of authorization that cannot be simply spoofed.


Related Technical Impacts


References

TBD