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 "AJAX How to test AoC"

From OWASP
Jump to: navigation, search
(Gray Box testing and example)
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
#REDIRECT [[Testing_for_AJAX  (OWASP-AJ-002)]]
{{Template:OWASP Testing Guide v2}}
 
 
 
== Brief Summary ==
 
<br>
 
Because most attacks against AJAX applications are analogs of attacks against traditional web applications, testers should refer to other sections of the testing guide to look for specific parameter manipulations to use in order to discover vulnerabilities.  The challenge with AJAX-enabled applications is often finding the endpoints that are the targets for the asynchronous calls and then determining the proper format for requests.
 
<br>
 
 
 
== Description of the Issue ==
 
<br>
 
...here: Short Description of the Issue: Topic and Explanation
 
<br>
 
== Black Box testing and example ==
 
'''Testing for AJAX Endpoints:''' <br>
 
Before an AJAX-enabled web application can be tested, the call endpoints for the asynchronous calls must be enumerated.  See [[Application_Discovery_AoC]] for more information about how traditional web applications are discovered.  For AJAX applications, there are two main approaches to determining call endpoints: parsing the HTML and JavaScript files and using a proxy to observe traffic.
 
 
 
The advantage of parsing the HTML and JavaScript files in a web application is that it can provide a more comprehensive view of the server-side capabilities that can be accessed from the client side.  The drawback is that manually reviewing HTML and JavaScript content is tedious and more importantly the location and format of server-side URLs available to be accessed by AJAX calls is framework dependent.
 
 
 
The tester should look through HTML and JavaScript files to find URLs of additional application surface exposure.  Searching for use of the XMLHttpRequest object in JavaScript code can help to focus these reviewing efforts.  Also, by knowing the names of included JavaScript files the tester can determine what AJAX frameworks appear to be in use.  Once AJAX endpoints have been identified, the tester should further inspect the code to determine the format required of requests.
 
 
 
[[Image:ExampleAtlasPage.PNG]]
 
 
 
The advantage of using a proxy to observe traffic is that the actual requests demonstrate conclusively where the application is sending requests and what format those requests are in.  The disadvantage is that only the endpoints that the application actually makes calls to will be revealed.  The tester must fully exercise the remote application and even then there could be additional call endpoints that are available but not actively in use.
 
 
 
[[Image:ExampleAtlasRequest.jpg]]
 
<br>
 
<br>
 
'''Result Expected:'''<br>
 
By enumerating the AJAX endpoints available in an application and determining the required request format the tester can set the stage for further analysis of the application.  Once endpoints and proper request formats have been determined, the tester can use a web proxy and standard web application parameter manipulation techniques to look for SQL injection and parameter tampering attacks.<br><br>
 
 
 
== Gray Box testing and example ==
 
'''Testing for Topic X vulnerabilities:'''<br>
 
Access to additional information about the application source code can greatly speed efforts to enumerate AJAX endpoints and the knowledge of what frameworks are in use will help the tester to understand the required format for AJAX requests.
 
<br>
 
'''Result Expected:'''<br>
 
<br><br>
 
 
 
== References ==
 
'''Whitepapers'''<br>
 
...<br>
 
'''Tools'''<br>
 
...<br>
 
 
 
 
 
 
 
{{Category:OWASP Testing Project AoC}}
 

Latest revision as of 19:10, 15 December 2008