OWASP AJAX Security Guidelines - Revision history

Jmanico: Redirected page to AJAX Security Cheat Sheet

2016-02-21T18:40:23Z

Redirected page to AJAX Security Cheat Sheet

Jmanico: /* Web service calls are not schema verified */

2016-02-21T18:26:35Z

‎Web service calls are not schema verified

Jmanico: /* Avoid building XML by hand, use the framework */

2016-02-21T18:25:59Z

‎Avoid building XML by hand, use the framework

Till Maas: separate generic and asp server side notes

2013-01-22T13:50:58Z

separate generic and asp server side notes

Till Maas: delete empty section

2013-01-22T13:42:48Z

delete empty section

Till Maas: use capec to explain JSON/JavaScript Hijacking

2013-01-22T13:03:28Z

use capec to explain JSON/JavaScript Hijacking

Till Maas: mention CSRF protection, use a working link for JavaScript Hijacking

2013-01-22T12:54:53Z

mention CSRF protection, use a working link for JavaScript Hijacking

Jmanico: removed bad/confusing advice about JSON and Querystrings

2012-11-25T21:56:39Z

removed bad/confusing advice about JSON and Querystrings

Dan Anderson: spelling

2012-04-13T06:31:05Z

spelling

Deepnov: /* Avoid building JSON by hand, use an existing framework */

2010-06-07T14:58:01Z

‎Avoid building JSON by hand, use an existing framework

← Older revision		Revision as of 18:40, 21 February 2016
Line 1:		Line 1:
−	~~= AJAX Security Guidelines =~~	+	#REDIRECT [[AJAX_Security_Cheat_Sheet]]
−
−	There is a complete lack of guidelines for AJAX. This document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies.
−
−	~~== Client Side (Javascript) ==~~
−
−	~~=== Use .innerText instead of .innerHtml ===~~
−
−	~~The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.~~
−
−	~~=== Don't use eval ===~~
−
−	~~Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.~~
−
−	~~=== Canonicalize data to consumer (read: encode before use) ===~~
−
−	When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning. Data should be properly encoded before used in this manner to prevent injection style issues, and to make sure the logical meaning is preserved.
−
−	[[~~:Category:OWASP_Encoding_Project\|Check out the OWASP Encoding Project.]]~~
−
−	~~=== Don't rely on client logic for security ===~~
−
−	~~Least ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic.~~
−
−	~~=== Don't rely on client business logic ===~~
−
−	~~Just like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly.~~
−
−	~~=== Avoid writing serialization code ===~~
−
−	This is hard and even a small mistake can cause large security issues. There are already a lot of frameworks to provide this functionality. Take a look at the [http://www.json.org/ JSON page] for links.
−
−	~~=== Avoid building XML dynamically ===~~
−
−	~~Just like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library to make attributes and element data safe.~~
−
−	~~[[:Category:OWASP_Encoding_Project\|Check out the OWASP Encoding Project.]]~~
−
−	~~=== Never transmit secrets to the client ===~~
−
−	~~Anything the client knows the user will also know, so keep all that secret stuff on the server please.~~
−
−	~~=== Don't perform encryption in client side code ===~~
−
−	~~Use TSL/SSL and encrypt on the server!~~
−
−	~~=== Don't perform security impacting logic on client side ===~~
−
−	~~This is the overall one that gets me out of trouble in case I missed something :)~~
−
−	~~== Server Side ==~~
−	~~=== Protect against [http://capec.mitre.org/data/definitions/111.html JSON/JavaScript Hijacking] ===~~
−	~~==== Use [[wiki:Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet\|CSRF protection]] ====~~
−	Proper CSRF protection ensures that attackers without access to the same origin as the data returned from the server cannot make the server respond with confidential and use JavaScript Hijacking to access it.
−
−	~~==== Always return JSON with an Object on the outside ====~~
−
−	~~Always have the outside primitive be an object for JSON strings:~~
−
−	~~'''Exploitable:'''~~
−	~~<pre>~~
−	~~[{"object": "inside an array"}]~~
−	~~</pre>~~
−
−	~~'''Not exploitable:'''~~
−	~~<pre>~~
−	~~{"object": "not inside an array"}~~
−	~~</pre>~~
−
−	~~'''Also not exploitable:'''~~
−	~~<pre>~~
−	~~{"result": [{"object": "inside an array"}]}~~
−	~~</pre>~~
−
−
−
−
−	~~=== Avoid writing serialization code. Remember ref vs. value types! ===~~
−
−	~~Look for an existing library that has been reviewed.~~
−
−	~~=== Services can be called by users directly ===~~
−
−	~~Even though you only expect your AJAX client side code to call those services the users can too. Make sure you validate inputs and treat them like they are under user control (because they are!).~~
−
−	~~=== Avoid building XML or JSON by hand, use the framework ===~~
−
−	~~Use the framework and be safe, do it by hand and have security issues.~~
−
−	~~=== Avoid building JSON by hand, use an existing framework ===~~
−
−	~~This is to hard to get right. Use existing code for this. Check out the JSON site for information.~~
−
−	~~== ASP.NET ==~~
−	~~A guide for building a secure AJAX service layer can be found [http://msdn.microsoft.com/en-us/magazine/cc793961.aspx here].~~
−	~~=== Use JSON And XML Schema for Webservices ===~~
−
−	~~You need to use a 3rd party library to validate web services.~~
−
−	~~[[Category:OWASP AJAX Security Project]]~~
−	~~[[Category:AJAX~~]]

@@ Line 94: / Line 94: @@
 == ASP.NET ==
 A guide for building a secure AJAX service layer can be found [http://msdn.microsoft.com/en-us/magazine/cc793961.aspx here].
-=== Web service calls are not schema verified ===
+=== Use JSON And XML Schema for Webservices ===
 You need to use a 3rd party library to validate web services.
 [[Category:OWASP AJAX Security Project]]
 [[Category:AJAX]]

@@ Line 84: / Line 84: @@
 Even though you only expect your AJAX client side code to call those services the users can too.  Make sure you validate inputs and treat them like they are under user control (because they are!).
-=== Avoid building XML by hand, use the framework ===
+=== Avoid building XML or JSON by hand, use the framework ===
 Use the framework and be safe, do it by hand and have security issues.

@@ Line 73: / Line 73: @@
 </pre>
-== ASP.NET ==
 === Avoid writing serialization code. Remember ref vs. value types! ===
-Writing serialization code in .NET seems not to hard and yet everyone gets it wrong.  Look for an existing library that has been reviewed.  I'll post more on that as I eval them.
+Look for an existing library that has been reviewed.
 === Services can be called by users directly ===
@@ Line 84: / Line 84: @@
 Even though you only expect your AJAX client side code to call those services the users can too.  Make sure you validate inputs and treat them like they are under user control (because they are!).
 === Web service calls are not schema verified ===
@@ Line 90: / Line 100: @@
 [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]
 [[Category:OWASP AJAX Security Project]]
 [[Category:AJAX]]

@@ Line 99: / Line 99: @@
 A guide for building a secure AJAX service layer can be found [http://msdn.microsoft.com/en-us/magazine/cc793961.aspx here].
 [[Category:OWASP AJAX Security Project]]
 [[Category:AJAX]]

@@ Line 50: / Line 50: @@
 == Server Side ==
-=== Protect against [http://searchsecurity.techtarget.com/definition/JavaScript-hijacking JavaScript Hijacking] ===
+=== Protect against [http://capec.mitre.org/data/definitions/111.html JSON/JavaScript Hijacking] ===
 ====  Use [[wiki:Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet|CSRF protection]] ====
 Proper CSRF protection ensures that attackers without access to the same origin as the data returned from the server cannot make the server respond with confidential and use JavaScript Hijacking to access it.

@@ Line 43: / Line 43: @@
 === Don't perform encryption in client side code ===
-Use SSL and encrypt on the server!
+Use TSL/SSL and encrypt on the server!
 === Don't perform security impacting logic on client side ===
@@ Line 49: / Line 49: @@
 This is the overall one that gets me out of trouble in case I missed something :)
-== JSON ==
+== Server Side ==
-=== Always return JSON with an Object on the outside ===
+==== Always return JSON with an Object on the outside ====
-Always have the outside primitive be an object for JSON strings.  This will help mitigate so called "JavaScript Hijacking" as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].
+Always have the outside primitive be an object for JSON strings:
-'''Explotable:'''
+'''Exploitable:'''
 <pre>
 [{"object": "inside an array"}]

← Older revision		Revision as of 21:56, 25 November 2012
Line 50:		Line 50:

	== JSON ==		== JSON ==
−
−	~~=== Never send JSON via Querystring ===~~
−
−	Sending JSON over a querystring would typically cause a cross-site scripting vulnerability as JSON strings are eval'd by the Javascript. JSON content should always come from a trusted source as the content body.

	=== Always return JSON with an Object on the outside ===		=== Always return JSON with an Object on the outside ===

@@ Line 15: / Line 15: @@
 === Canonicalize data to consumer (read: encode before use) ===
-When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning.  Data should be properly encoded before used in this manor to prevent injection style issues, and to make sure the logical meaning is preserved.
+When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning.  Data should be properly encoded before used in this manner to prevent injection style issues, and to make sure the logical meaning is preserved.
 [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]

@@ Line 95: / Line 95: @@
 Use the framework and be safe, do it by hand and have security issues.  Simple.
-=== Avoid building JSON by hand, use an existing framework ===
+=== Avoid building JSON by hand, use an existing framework  ===
-This is to hard to get right.  Use existing code for this.  Check out the JSON site for information.
+This is to hard to get right. Use existing code for this. Check out the JSON site for information.
 == Java ==