Difference between revisions of "Repudiation Attack"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to www.textgetpasace.com)
(14 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
 +
<br>
 +
[[Category:OWASP ASDR Project]]
 +
 +
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
  
 
==Description==
 
==Description==
Repudiation is the act of refuse authoring of something that happened. A repudiation attack happens when an application or system do not adopt controls to properly track and log users actions, thus permitting malicious manipulation or forging the identification of an action.
+
 
This attack can be used to change the authoring information of malicious actions that are stored on application log files and its usage can be extended to general data manipulation in name of others.
+
A repudiation attack happens when an application or system does not adopt controls to properly track and log users' actions, thus permitting malicious manipulation or forging the identification of new actions.
 +
This attack can be used to change the authoring information of actions executed by a malicious user in order to log wrong data to log files. Its usage can be extended to general data manipulation in the name of others, in a similar manner as spoofing mail messages.
 
If this attack takes place, the data stored on log files can be considered invalid or misleading.
 
If this attack takes place, the data stored on log files can be considered invalid or misleading.
 +
 +
== Risk Factors==
 +
TBD
  
  
 
==Examples ==
 
==Examples ==
===Example 1===
 
Consider a web application that makes access control and authorization based on user SessionId, but register its actions based on user parameter defined on request header, as follows:
 
  
 +
Consider a web application that makes access control and authorization based on SESSIONID, but registers user actions based on a user parameter defined on the Cookie header, as follows:
 +
 +
  POST <nowiki>http://someserver/Upload_file.jsp</nowiki> HTTP/1.1
 +
  Host: tequila:8443
 +
  User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) 
 +
  Gecko/20070515 Firefox/2.0.0.4
 +
  Accept:
 +
  text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 +
  Accept-Language: en-us,en;q=0.5
 +
  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 +
  Keep-Alive: 300
 +
  Connection: keep-alive
 +
  Referer: <nowiki>http://someserver/uploads.jsp</nowiki>
 +
  '''Cookie: JSESSIONID=EE3BD1E764CD6EED280426128201131C; 
 +
  user=leonardo'''
 +
  Content-Type: multipart/form-data; boundary=---------------------------
 +
  263152394310685
 +
  Content-Length: 321
 +
 +
And the log file is composed by:
 +
 +
Date, Time, Source IP, Source port, Request, User
  
POST https://tequila:8443/atualiza/atualizaUploads.jsp HTTP/1.1
+
Once user information is acquired from user parameter on HTTP header, a malicious user could make use of a local proxy (eg:paros) and change it by a known or unknown username.
Host: tequila:8443
+
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
+
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
+
Accept-Language: en-us,en;q=0.5
+
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+
Keep-Alive: 300
+
Connection: keep-alive
+
Referer: https://tequila:8443/uploads.jsp
+
'''Cookie: JSESSIONID=EE3BD1E764CD6EED280426128201131C; user=leonardo'''
+
Content-Type: multipart/form-data; boundary=---------------------------263152394310685
+
Content-Length: 321
+
  
 +
==Related [[Threat Agents]]==
 +
* [[:Category: Authorization]]
 +
* [[:Category: Logical Attacks]]
  
 +
==Related [[Attacks]]==
 +
* [[Web Parameter Tampering]]
  
 +
==Related [[Vulnerabilities]]==
 +
* [[:Category: Input Validation]]
 +
* [[:Category: Access Control Vulnerability]]
 +
* [[:Category: Logging and Auditing Vulnerability]]
  
==Related Threats==
+
==Related [[Controls]]==
 +
* [[:Category: Logging]]
 +
* [[:Category: Access Control]]
  
==Related Attacks==
+
==References==
 +
* http://capec.mitre.org/data/definitions/93.html - Log Injection-Tampering-Forging
  
==Related Vulnerabilities==
 
  
==Related Countermeasures==
+
[[Category:Resource Manipulation]]
  
 
[[Category:Attack]]
 
[[Category:Attack]]

Revision as of 13:29, 27 May 2009

This is an Attack. To view all attacks, please see the Attack Category page.




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


Description

A repudiation attack happens when an application or system does not adopt controls to properly track and log users' actions, thus permitting malicious manipulation or forging the identification of new actions. This attack can be used to change the authoring information of actions executed by a malicious user in order to log wrong data to log files. Its usage can be extended to general data manipulation in the name of others, in a similar manner as spoofing mail messages. If this attack takes place, the data stored on log files can be considered invalid or misleading.

Risk Factors

TBD


Examples

Consider a web application that makes access control and authorization based on SESSIONID, but registers user actions based on a user parameter defined on the Cookie header, as follows:

 POST http://someserver/Upload_file.jsp HTTP/1.1
 Host: tequila:8443
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4)   
 Gecko/20070515 Firefox/2.0.0.4
 Accept:
 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 Accept-Language: en-us,en;q=0.5
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive: 300
 Connection: keep-alive
 Referer: http://someserver/uploads.jsp
 Cookie: JSESSIONID=EE3BD1E764CD6EED280426128201131C;  
 user=leonardo
 Content-Type: multipart/form-data; boundary=--------------------------- 
 263152394310685
 Content-Length: 321

And the log file is composed by:

Date, Time, Source IP, Source port, Request, User

Once user information is acquired from user parameter on HTTP header, a malicious user could make use of a local proxy (eg:paros) and change it by a known or unknown username.

Related Threat Agents

Related Attacks

Related Vulnerabilities

Related Controls

References