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

From OWASP
Jump to: navigation, search
 
(Reverting to last version not containing links to www.textacpasv.com)
 
(17 intermediate revisions by 8 users not shown)
Line 1: Line 1:
 
+
{{Template:Vulnerability}}
 
+
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
The referrer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Consequences ==
+
==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.
  
* Authorization: Actions, which may not be authorized otherwise, can be carried out as if they were validated by the server referred to.
+
'''Consequences'''
  
* Accountability: Actions may be taken in the name of the server referred to.
+
* 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 ==
+
'''Exposure period'''
  
* Design: Authentication methods are generally chosen during the design phase of development.
+
* Design: Authentication methods are generally chosen during the design phase of development.
  
==Platform ==
+
'''Platform'''
  
* Languages: All
+
* Languages: All
 +
* Operating platforms: All
  
* Operating platforms: All
+
'''Required resources'''
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Very High
 
Very High
  
==Avoidance and mitigation ==
+
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.
  
* Design: Use other means of authorization that cannot be simply spoofed.
 
  
==Discussion ==
+
==Risk Factors==
  
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.
+
TBD
  
==Examples ==
+
==Examples==
  
 
In C/C++:
 
In C/C++:
  
 +
<pre>
 
sock= socket(AF_INET, SOCK_STREAM, 0);  
 
sock= socket(AF_INET, SOCK_STREAM, 0);  
 
...
 
...
Line 59: Line 59:
 
if (buffer+...==Referer: http://www.foo.org/dsaf.html)
 
if (buffer+...==Referer: http://www.foo.org/dsaf.html)
 
//do stuff
 
//do stuff
 +
</pre>
 +
 
In Java:
 
In Java:
  
 +
<pre>
 
public class httpd extends Thread{
 
public class httpd extends Thread{
 
   Socket cli;
 
   Socket cli;
Line 82: Line 85:
 
         new DataOutputStream(c.getOutputStream());
 
         new DataOutputStream(c.getOutputStream());
 
       ...  
 
       ...  
==Related problems ==
+
</pre>
  
* Trusting self-reported IP address
+
In J2EE:
  
* Using the referer field for authentication
+
Any J2EE program that uses
 +
<pre>
 +
HttpServletRequest.getHeader("referer")
 +
</pre>
 +
to make a decision is also vulnerable.
  
==Categories ==
 
  
[[Category:Vulnerability]]
+
==Related [[Attacks]]==
  
[[Category:Protocol Errors]]
+
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Trusting self-reported IP address]]
 +
 
 +
 
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* Design: Use other means of authorization that cannot be simply spoofed.
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
 +
 
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:Authentication Vulnerability]]
 +
[[Category:Authorization Vulnerability]]
 +
[[Category:OWASP_CLASP_Project]]

Latest revision as of 13:30, 27 May 2009

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



Last revision (mm/dd/yy): 05/27/2009

Vulnerabilities Table of Contents

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