Testing for AJAX: introduction - Revision history

KirstenS at 00:09, 16 December 2008

2008-12-16T00:09:35Z

KirstenS at 00:06, 16 December 2008

2008-12-16T00:06:09Z

Namn at 06:27, 31 August 2008

2008-08-31T06:27:10Z

Mmeucci at 11:38, 23 August 2008

2008-08-23T11:38:53Z

Mmeucci at 11:37, 23 August 2008

2008-08-23T11:37:29Z

Mmeucci: Testing for AJAX moved to Testing for AJAX: introduction

2006-12-30T15:14:01Z

Testing for AJAX moved to Testing for AJAX: introduction

Mmeucci: AJAX Testing AoC moved to Testing for AJAX: naming convention

2006-12-30T15:12:17Z

AJAX Testing AoC moved to Testing for AJAX: naming convention

Katie.mcdowell: /* 4.9 AJAX Testing */

2006-11-27T02:18:34Z

‎4.9 AJAX Testing

Mmeucci at 12:51, 24 November 2006

2006-11-24T12:51:49Z

Mmeucci: /* 4.9 AJAX Testing */

2006-11-07T11:51:07Z

‎4.9 AJAX Testing

@@ Line 16: / Line 16: @@
 In this section, we will visit these topics:<br>
-[[Testing for AJAX Vulnerabilities (OWASP-AJ-001)|4.11.1 AJAX Vulnerabilities ]]<br>
+[[Testing for AJAX Vulnerabilities (OWASP-AJ-001)|4.11.1 AJAX Vulnerabilities (OWASP-AJ-001) ]]<br>
-[[Testing for AJAX|4.11.2 How to test AJAX ]]<br>
+[[Testing for AJAX  (OWASP-AJ-002)|4.11.2 How to test AJAX  (OWASP-AJ-002) ]]<br>

@@ Line 16: / Line 16: @@
 In this section, we will visit these topics:<br>
-[[Testing for AJAX Vulnerabilities |4.11.1 AJAX Vulnerabilities ]]<br>
+[[Testing for AJAX Vulnerabilities (OWASP-AJ-001)|4.11.1 AJAX Vulnerabilities ]]<br>
 [[Testing for AJAX|4.11.2 How to test AJAX ]]<br>

@@ Line 14: / Line 14: @@
 <br>
-In this section we describe the following:<br>
+In this section, we will visit these topics:<br>
 [[Testing for AJAX Vulnerabilities |4.11.1 AJAX Vulnerabilities ]]<br>
 [[Testing for AJAX|4.11.2 How to test AJAX ]]<br>

← Older revision		Revision as of 11:38, 23 August 2008
Line 2:		Line 2:


−	~~===~~ 4.11 AJAX Testing ~~===~~	+	'''4.11 AJAX Testing'''
	----		----

@@ Line 1: / Line 1: @@
-[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+{{Template:OWASP Testing Guide v3}}
-=== 4.9 AJAX Testing ===
+=== 4.11 AJAX Testing ===
 ----
@@ Line 17: / Line 16: @@
 In this section we describe the following:<br>
-[[AJAX Vulnerabilities AoC |4.9.1 AJAX Vulnerabilities ]]<br>
+[[Testing for AJAX Vulnerabilities |4.11.1 AJAX Vulnerabilities ]]<br>
-[[AJAX How to test AoC|4.9.2 How to test AJAX ]]<br>
+[[Testing for AJAX|4.11.2 How to test AJAX ]]<br>

← Older revision	Revision as of 15:14, 30 December 2006
(No difference)

← Older revision	Revision as of 15:12, 30 December 2006
(No difference)

@@ Line 8: / Line 8: @@
 AJAX, an acronym for Asynchronous JavaScript and XML, is a web development technique used to create more responsive web applications.  It uses a combination of technologies in order to provide an experience that is more like using a desktop application.  This is accomplished by using the XMLHttpRequest object and JavaScript to make asynchronous requests to the web server, parsing the responses and then updating the page DOM HTML and CSS.
-Utilizing AJAX techniques can have tremendous usability benefits for web applications.  From a security standpoint, however, AJAX applications have a greater attack surface than normal web applications and they are often developed with a focus on what can be done rather than what should be done.  Also, AJAX applications are more complicated because processing is done on both the client side and the server side.  The use of frameworks to hide this complexity can help to reduce development headaches, but can also result in situations where developers do not fully understand where the code they are writing will execute.  This can lead to situations where it is difficult to properly assess the risk associated with particular applications or features.
+Utilizing AJAX techniques can have tremendous usability benefits for web applications.  From a security standpoint, however, AJAX applications have a greater attack surface than normal web applications, and they are often developed with a focus on what can be done rather than what should be done.  Also, AJAX applications are more complicated because processing is done on both the client side and the server side.  The use of frameworks to hide this complexity can help to reduce development headaches, but can also result in situations where developers do not fully understand where the code they are writing will execute.  This can lead to situations where it is difficult to properly assess the risk associated with particular applications or features.
-AJAX applications are vulnerable to the full range of traditional web application vulnerabilities.  Insecure coding practices can lead to SQL injection vulnerabilities, misplaced trust in user-supplied input can lead to parameter tampering vulnerabilities and a failure to require proper authentication and authorization can lead to problems with confidentiality and integrity.  In addition, AJAX applications can be vulnerable to new classes of attack such as Cross Site Request Forgery (XSRF).
+AJAX applications are vulnerable to the full range of traditional web application vulnerabilities.  Insecure coding practices can lead to SQL injection vulnerabilities, misplaced trust in user-supplied input can lead to parameter tampering vulnerabilities, and a failure to require proper authentication and authorization can lead to problems with confidentiality and integrity.  In addition, AJAX applications can be vulnerable to new classes of attack such as Cross Site Request Forgery (XSRF).
-Testing AJAX applications can be challenging because developers are given a tremendous amount of freedom in how they communicate between the client and the server.  In traditional web applications, standard HTML forms submitted via GET or POST requests have an easy to understand format and it is therefore easy to modify or create new well-formed requests.  AJAX applications often use different encoding or serialization schemes to submit POST data making it difficult for testing tools to reliably create automated test requests.  The use of web proxy tools is extremely valuable for observing behind the scenes asynchronous traffic and ultimately modifying this traffic to properly test the AJAX-enabled application.
+Testing AJAX applications can be challenging because developers are given a tremendous amount of freedom in how they communicate between the client and the server.  In traditional web applications, standard HTML forms submitted via GET or POST requests have an easy-to-understand format, and it is therefore easy to modify or create new well-formed requests.  AJAX applications often use different encoding or serialization schemes to submit POST data making it difficult for testing tools to reliably create automated test requests.  The use of web proxy tools is extremely valuable for observing behind-the-scenes asynchronous traffic and for ultimately modifying this traffic to properly test the AJAX-enabled application.
 <br>

← Older revision		Revision as of 12:51, 24 November 2006
Line 1:		Line 1:
−	~~{{Template:OWASP Testing Guide v2}}~~
	[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>		[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
	{{Template:OWASP Testing Guide v2}}		{{Template:OWASP Testing Guide v2}}