This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for JavaScript Execution (OTG-CLIENT-002)"

From OWASP
Jump to: navigation, search
(Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == a == Description of the Issue == a The first hypothetical example uses the following client side code: <script>...")
 
m (→‎How to Test)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:OWASP Testing Guide v4}}
 
{{Template:OWASP Testing Guide v4}}
  
−
== Brief Summary ==
+
== Summary ==
−
a
+
A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim's browser. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior.
  
−
== Description of the Issue ==
 
−
a
 
−
 
−
The first hypothetical example uses the following client side code:
 
−
 
−
<script>
 
−
aaa
 
−
</script>
 
  
 +
== How to Test ==
 +
Such a vulnerability occurs when the application lacks proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occurs during this content processing phase and consequently affects the victim.
  
  
−
== Black Box testing and example ==
+
When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki.
−
Blackbox testing for  JavaScript Execution is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>
 
  
−
== Gray Box testing and example ==  
+
 
−
'''Testing for JavaScript Execution vulnerabilities:'''<br>
+
The following script does not perform any validation of the variable rr that contains the user supplied input via the query string and additionally does not apply any form of encoding:
−
a
+
 
 +
<pre>
 +
var rr = location.search.substring(1);
 +
if(rr)
 +
  window.location=decodeURIComponent(rr);
 +
</pre>
 +
 
 +
This implies that an attacker could inject JavaScript code simply by submitting the following query string: <nowiki>''www.victim.com/?javascript:alert(1)''</nowiki>.
 +
 
 +
 
 +
=== Black Box testing ===
 +
Black box testing for  JavaScript Execution is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>
 +
 
 +
 
 +
=== Gray Box testing ===
 +
'''Testing for JavaScript Execution vulnerabilities:'''
 +
 
 +
For example, looking at the following URL:
 +
http://www.domxss.com/domxss/01_Basics/04_eval.html
 +
 
 +
 
 +
The page contains the following scripts:
  
 
<pre>
 
<pre>
 
<script>
 
<script>
−
aaa
+
function loadObj(){
 +
var cc=eval('('+aMess+')');
 +
document.getElementById('mess').textContent=cc.message;
 +
}
 +
 
 +
if(window.location.hash.indexOf('message')==-1)
 +
  var aMess="({\"message\":\"Hello User!\"})";
 +
else
 +
  var aMess=location.hash.substr(window.location.hash.indexOf('message=')+8);
 
</script>
 
</script>
 
</pre>
 
</pre>
−
 
  
 +
 +
The above code contains a source 'location.hash' that is controlled by the attacker that can inject directly in the 'message' value a JavaScript Code to take the control of the user browser.
  
 
== References ==
 
== References ==
 
'''OWASP Resources'''
 
'''OWASP Resources'''
 
* [[DOM based XSS Prevention Cheat Sheet]]
 
* [[DOM based XSS Prevention Cheat Sheet]]
−
* DOMXSS.com - http://domxss.com
+
* DOMXSS.com - http://www.domxss.com
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
−
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
+
** i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc.

Latest revision as of 19:39, 1 December 2014

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Summary

A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim's browser. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior.


How to Test

Such a vulnerability occurs when the application lacks proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occurs during this content processing phase and consequently affects the victim.


When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki.


The following script does not perform any validation of the variable rr that contains the user supplied input via the query string and additionally does not apply any form of encoding: 

var rr = location.search.substring(1);
if(rr)
  window.location=decodeURIComponent(rr);

This implies that an attacker could inject JavaScript code simply by submitting the following query string: ''www.victim.com/?javascript:alert(1)''.


Black Box testing

Black box testing for JavaScript Execution is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.


Gray Box testing

Testing for JavaScript Execution vulnerabilities:

For example, looking at the following URL: http://www.domxss.com/domxss/01_Basics/04_eval.html


The page contains the following scripts: 

<script>
function loadObj(){
 var cc=eval('('+aMess+')');
 document.getElementById('mess').textContent=cc.message;
}

if(window.location.hash.indexOf('message')==-1)
  var aMess="({\"message\":\"Hello User!\"})";
else
  var aMess=location.hash.substr(window.location.hash.indexOf('message=')+8);
</script>


The above code contains a source 'location.hash' that is controlled by the attacker that can inject directly in the 'message' value a JavaScript Code to take the control of the user browser.

References

OWASP Resources

Whitepapers

Retrieved from "https://wiki.owasp.org/index.php?title=Testing_for_JavaScript_Execution_(OTG-CLIENT-002)&oldid=186324"