https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Meddington 2026-05-09T06:51:05Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=25475 2008-02-17T00:12:11Z

<p>Meddington: /* Downloading */</p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://canoodle.googlecode.com/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://canoodle.googlecode.com/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> The latest code is now being maintained in a [http://code.google.com/p/canoodle/ Google Code repository].<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> === Methods of Use ===<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> &lt;h3&gt;Attributes&lt;/h3&gt;<br /> &lt;p&gt;[&lt;strong&gt;Validation&lt;/strong&gt;]&lt;/p&gt;<br /> &lt;p&gt;Mark web method for validation against schemas&lt;/p&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchemaFolder&lt;/strong&gt;(string relativeFolder)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add folders that contain schemas to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The relativeFolder parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;relativeFolder&lt;/em&gt; -- Folder of schemas to load and cache.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchema&lt;/strong&gt;(string schemaFile)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add schema files to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The schemaFile parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;schemaFile&lt;/em&gt; -- Schema file to load.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule)]&lt;br&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule, string description)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add an XPath&amp;nbsp;validation expression to a web method.&amp;nbsp; The XPath expression must evaluate to true.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;rule&lt;/em&gt; -- XPath validation expression.&amp;nbsp; Must evaluate to true. <br /> &lt;li&gt;&lt;em&gt;description&lt;/em&gt; -- [optional] Description of assertion rule.&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;AssertNamespaceBinding&lt;/strong&gt;(string prefix, string ns)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Specifies namespace bindings used by assert xpath's.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;prefix&lt;/em&gt; -- namespace prefix <br /> &lt;li&gt;&lt;em&gt;ns&lt;/em&gt; -- namespace to map to&lt;/li&gt;&lt;/ul&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Web.config Changes&lt;/h3&gt;<br /> &lt;p&gt;First two extensions must be registered by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;<br /> <br /> &lt;p&gt;&lt;/p&gt;<br /> &lt;p&gt;&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtensionReflector, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;serviceDescriptionFormatExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationFormatExtension, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/serviceDescriptionFormatExtensionTypes&amp;gt; <br /> &lt;/pre&gt;<br /> &lt;p&gt;Next, POST and GET protocols must be disabled by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;protocols&amp;gt;<br /> <br /> &amp;lt;remove name=&quot;HttpPost&quot; /&amp;gt;<br /> &amp;lt;remove name=&quot;HttpGet&quot; /&amp;gt;<br /> &amp;lt;/protocols&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;p&gt;Finally, if you want to force all web methods to be validated with out using the [Validation] attribute add the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtension, SoapValidation&quot; priority=&quot;1&quot; group=&quot;0&quot; /&amp;gt;<br /> <br /> &amp;lt;/soapExtensionTypes&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Validation&lt;/h3&gt;<br /> &lt;p&gt;Here is a basic example that will cause validation to be run:&lt;/p&gt;&lt;pre&gt;[WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]public&quot;&gt;http://example.org/geometry&quot;)]<br /> public&lt;/a&gt; class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }&lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Assertions&lt;/h3&gt;<br /> <br /> &lt;p&gt;Here is an example of using assertions to verify business rules in a way schema's fall short.&lt;/p&gt;&lt;pre&gt;[AssertNamespaceBinding(&quot;t&quot;, &quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> [WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> public class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> [Assert(&quot;(//t:length * //t:width) &amp;gt; 100&quot;, &quot;Area must be greater than 100&quot;)]<br /> [Assert(&quot;(//t:length div //t:width) = 2&quot;, &quot;Length must be exactly twice width&quot;)]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> &lt;p&gt;&amp;nbsp;&lt;/p&gt;<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP .NET Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> [[Category:OWASP Validation Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=25387 2008-02-14T21:17:49Z

<p>Meddington: /* Credit */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> 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.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings. This will help mitigate so called &quot;JavaScript Hijacking&quot; as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> Last updated 02/13/2008<br /> <br /> Created on 12/12/2006<br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=25386 2008-02-14T21:17:37Z

<p>Meddington: /* Credit */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> 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.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings. This will help mitigate so called &quot;JavaScript Hijacking&quot; as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> Last updated 02/13/2008<br /> Created on 12/12/2006<br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=25385 2008-02-14T21:15:31Z

<p>Meddington: /* Never transmit secrets to the client */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> 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.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings. This will help mitigate so called &quot;JavaScript Hijacking&quot; as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> Last updated 02/13/2008<br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=25384 2008-02-14T21:15:08Z

<p>Meddington: /* Avoid writing serialization code */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> 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.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings. This will help mitigate so called &quot;JavaScript Hijacking&quot; as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> Last updated 02/13/2008<br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=25383 2008-02-14T21:11:20Z

<p>Meddington: </p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> 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.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings. This will help mitigate so called &quot;JavaScript Hijacking&quot; as talked about in [http://www.fortifysoftware.com/servlet/downloads/public/JavaScript_Hijacking.pdf this paper].<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> Last updated 02/13/2008<br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=25332 2008-02-13T21:46:12Z

<p>Meddington: </p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == JSON ==<br /> <br /> === Never send JSON via Querystring ===<br /> <br /> 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 it will be executed.<br /> <br /> === Always return JSON with an Object on the outside ===<br /> <br /> Always have the outside primitive be an object for JSON strings.<br /> <br /> '''Explotable:'''<br /> &lt;pre&gt;<br /> [{&quot;object&quot;: &quot;inside an array&quot;}]<br /> &lt;/pre&gt;<br /> <br /> '''Not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;object&quot;: &quot;not inside an array&quot;}<br /> &lt;/pre&gt;<br /> <br /> '''Also not exploitable:'''<br /> &lt;pre&gt;<br /> {&quot;result&quot;: [{&quot;object&quot;: &quot;inside an array&quot;}]}<br /> &lt;/pre&gt;<br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing framework ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> Last updated 02/13/2008<br /> <br /> [[Category:OWASP AJAX Security Project]]<br /> [[Category:AJAX]]</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=22870 2007-11-03T09:30:08Z

<p>Meddington: </p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://canoodle.googlecode.com/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://canoodle.googlecode.com/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> === Methods of Use ===<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> &lt;h3&gt;Attributes&lt;/h3&gt;<br /> &lt;p&gt;[&lt;strong&gt;Validation&lt;/strong&gt;]&lt;/p&gt;<br /> &lt;p&gt;Mark web method for validation against schemas&lt;/p&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchemaFolder&lt;/strong&gt;(string relativeFolder)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add folders that contain schemas to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The relativeFolder parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;relativeFolder&lt;/em&gt; -- Folder of schemas to load and cache.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchema&lt;/strong&gt;(string schemaFile)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add schema files to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The schemaFile parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;schemaFile&lt;/em&gt; -- Schema file to load.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule)]&lt;br&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule, string description)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add an XPath&amp;nbsp;validation expression to a web method.&amp;nbsp; The XPath expression must evaluate to true.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;rule&lt;/em&gt; -- XPath validation expression.&amp;nbsp; Must evaluate to true. <br /> &lt;li&gt;&lt;em&gt;description&lt;/em&gt; -- [optional] Description of assertion rule.&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;AssertNamespaceBinding&lt;/strong&gt;(string prefix, string ns)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Specifies namespace bindings used by assert xpath's.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;prefix&lt;/em&gt; -- namespace prefix <br /> &lt;li&gt;&lt;em&gt;ns&lt;/em&gt; -- namespace to map to&lt;/li&gt;&lt;/ul&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Web.config Changes&lt;/h3&gt;<br /> &lt;p&gt;First two extensions must be registered by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;<br /> <br /> &lt;p&gt;&lt;/p&gt;<br /> &lt;p&gt;&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtensionReflector, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;serviceDescriptionFormatExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationFormatExtension, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/serviceDescriptionFormatExtensionTypes&amp;gt; <br /> &lt;/pre&gt;<br /> &lt;p&gt;Next, POST and GET protocols must be disabled by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;protocols&amp;gt;<br /> <br /> &amp;lt;remove name=&quot;HttpPost&quot; /&amp;gt;<br /> &amp;lt;remove name=&quot;HttpGet&quot; /&amp;gt;<br /> &amp;lt;/protocols&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;p&gt;Finally, if you want to force all web methods to be validated with out using the [Validation] attribute add the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtension, SoapValidation&quot; priority=&quot;1&quot; group=&quot;0&quot; /&amp;gt;<br /> <br /> &amp;lt;/soapExtensionTypes&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Validation&lt;/h3&gt;<br /> &lt;p&gt;Here is a basic example that will cause validation to be run:&lt;/p&gt;&lt;pre&gt;[WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]public&quot;&gt;http://example.org/geometry&quot;)]<br /> public&lt;/a&gt; class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }&lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Assertions&lt;/h3&gt;<br /> <br /> &lt;p&gt;Here is an example of using assertions to verify business rules in a way schema's fall short.&lt;/p&gt;&lt;pre&gt;[AssertNamespaceBinding(&quot;t&quot;, &quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> [WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> public class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> [Assert(&quot;(//t:length * //t:width) &amp;gt; 100&quot;, &quot;Area must be greater than 100&quot;)]<br /> [Assert(&quot;(//t:length div //t:width) = 2&quot;, &quot;Length must be exactly twice width&quot;)]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> &lt;p&gt;&amp;nbsp;&lt;/p&gt;<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP .NET Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> [[Category:OWASP Validation Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=18641 2007-05-14T19:13:37Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. The Reform library provides a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://reform.googlecode.com/files/Reform-0.12.zip Reform-0.12.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> * Full xUnit style test cases<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> <br /> __NOTOC__</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=16504 2007-02-17T01:18:14Z

<p>Meddington: /* Overview */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. The Reform library provides a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.12.zip Reform-0.12.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> * Full xUnit style test cases<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> <br /> __NOTOC__</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=14218 2006-12-12T05:05:08Z

<p>Meddington: /* Features */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.12.zip Reform-0.12.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> * Full xUnit style test cases<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> <br /> __NOTOC__</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14217 2006-12-12T05:00:44Z

<p>Meddington: /* Web service calls are not schema verified */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [[:.NET_Web_Service_Validation|Check out OWASP .NET Web Service Validation.]]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14216 2006-12-12T05:00:36Z

<p>Meddington: /* Avoid building XML dynamically */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [http://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14215 2006-12-12T04:59:46Z

<p>Meddington: /* Avoid building XML dynamically */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [http://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14214 2006-12-12T04:59:02Z

<p>Meddington: /* Canonicalize data to consumer (read: encode before use) */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [[:Category:OWASP_Encoding_Project|Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [http://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14213 2006-12-12T04:55:24Z

<p>Meddington: /* Canonicalize data to consumer (read: encode before use) */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [http://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14212 2006-12-12T04:55:10Z

<p>Meddington: /* Avoid building XML dynamically */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [http://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14211 2006-12-12T04:54:05Z

<p>Meddington: /* Web service calls are not schema verified */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [http://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14210 2006-12-12T04:52:39Z

<p>Meddington: /* Avoid building JSON by hand, use an existing frameworl */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [https://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get right. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=14209 2006-12-12T04:38:08Z

<p>Meddington: </p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> === Methods of Use ===<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> &lt;h3&gt;Attributes&lt;/h3&gt;<br /> &lt;p&gt;[&lt;strong&gt;Validation&lt;/strong&gt;]&lt;/p&gt;<br /> &lt;p&gt;Mark web method for validation against schemas&lt;/p&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchemaFolder&lt;/strong&gt;(string relativeFolder)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add folders that contain schemas to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The relativeFolder parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;relativeFolder&lt;/em&gt; -- Folder of schemas to load and cache.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchema&lt;/strong&gt;(string schemaFile)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add schema files to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The schemaFile parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;schemaFile&lt;/em&gt; -- Schema file to load.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule)]&lt;br&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule, string description)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add an XPath&amp;nbsp;validation expression to a web method.&amp;nbsp; The XPath expression must evaluate to true.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;rule&lt;/em&gt; -- XPath validation expression.&amp;nbsp; Must evaluate to true. <br /> &lt;li&gt;&lt;em&gt;description&lt;/em&gt; -- [optional] Description of assertion rule.&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;AssertNamespaceBinding&lt;/strong&gt;(string prefix, string ns)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Specifies namespace bindings used by assert xpath's.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;prefix&lt;/em&gt; -- namespace prefix <br /> &lt;li&gt;&lt;em&gt;ns&lt;/em&gt; -- namespace to map to&lt;/li&gt;&lt;/ul&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Web.config Changes&lt;/h3&gt;<br /> &lt;p&gt;First two extensions must be registered by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;<br /> <br /> &lt;p&gt;&lt;/p&gt;<br /> &lt;p&gt;&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtensionReflector, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;serviceDescriptionFormatExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationFormatExtension, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/serviceDescriptionFormatExtensionTypes&amp;gt; <br /> &lt;/pre&gt;<br /> &lt;p&gt;Next, POST and GET protocols must be disabled by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;protocols&amp;gt;<br /> <br /> &amp;lt;remove name=&quot;HttpPost&quot; /&amp;gt;<br /> &amp;lt;remove name=&quot;HttpGet&quot; /&amp;gt;<br /> &amp;lt;/protocols&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;p&gt;Finally, if you want to force all web methods to be validated with out using the [Validation] attribute add the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtension, SoapValidation&quot; priority=&quot;1&quot; group=&quot;0&quot; /&amp;gt;<br /> <br /> &amp;lt;/soapExtensionTypes&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Validation&lt;/h3&gt;<br /> &lt;p&gt;Here is a basic example that will cause validation to be run:&lt;/p&gt;&lt;pre&gt;[WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]public&quot;&gt;http://example.org/geometry&quot;)]<br /> public&lt;/a&gt; class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }&lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Assertions&lt;/h3&gt;<br /> <br /> &lt;p&gt;Here is an example of using assertions to verify business rules in a way schema's fall short.&lt;/p&gt;&lt;pre&gt;[AssertNamespaceBinding(&quot;t&quot;, &quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> [WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> public class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> [Assert(&quot;(//t:length * //t:width) &amp;gt; 100&quot;, &quot;Area must be greater than 100&quot;)]<br /> [Assert(&quot;(//t:length div //t:width) = 2&quot;, &quot;Length must be exactly twice width&quot;)]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> &lt;p&gt;&amp;nbsp;&lt;/p&gt;<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP .NET Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14208 2006-12-12T04:34:32Z

<p>Meddington: </p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [https://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> == Credit ==<br /> <br /> This content was created by [http://phed.org Michael Eddington] of [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> <br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14207 2006-12-12T04:17:17Z

<p>Meddington: /* Web service calls are not schema verified */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> [https://www.owasp.org/index.php/.NET_Web_Service_Validation Check out OWASP .NET Web Service Validation.]<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=14206 2006-12-12T04:16:48Z

<p>Meddington: </p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> === Methods of Use ===<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> &lt;h3&gt;Attributes&lt;/h3&gt;<br /> &lt;p&gt;[&lt;strong&gt;Validation&lt;/strong&gt;]&lt;/p&gt;<br /> &lt;p&gt;Mark web method for validation against schemas&lt;/p&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchemaFolder&lt;/strong&gt;(string relativeFolder)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add folders that contain schemas to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The relativeFolder parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;relativeFolder&lt;/em&gt; -- Folder of schemas to load and cache.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchema&lt;/strong&gt;(string schemaFile)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add schema files to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The schemaFile parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;schemaFile&lt;/em&gt; -- Schema file to load.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule)]&lt;br&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule, string description)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add an XPath&amp;nbsp;validation expression to a web method.&amp;nbsp; The XPath expression must evaluate to true.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;rule&lt;/em&gt; -- XPath validation expression.&amp;nbsp; Must evaluate to true. <br /> &lt;li&gt;&lt;em&gt;description&lt;/em&gt; -- [optional] Description of assertion rule.&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;AssertNamespaceBinding&lt;/strong&gt;(string prefix, string ns)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Specifies namespace bindings used by assert xpath's.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;prefix&lt;/em&gt; -- namespace prefix <br /> &lt;li&gt;&lt;em&gt;ns&lt;/em&gt; -- namespace to map to&lt;/li&gt;&lt;/ul&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Web.config Changes&lt;/h3&gt;<br /> &lt;p&gt;First two extensions must be registered by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;<br /> <br /> &lt;p&gt;&lt;/p&gt;<br /> &lt;p&gt;&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtensionReflector, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;serviceDescriptionFormatExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationFormatExtension, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/serviceDescriptionFormatExtensionTypes&amp;gt; <br /> &lt;/pre&gt;<br /> &lt;p&gt;Next, POST and GET protocols must be disabled by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;protocols&amp;gt;<br /> <br /> &amp;lt;remove name=&quot;HttpPost&quot; /&amp;gt;<br /> &amp;lt;remove name=&quot;HttpGet&quot; /&amp;gt;<br /> &amp;lt;/protocols&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;p&gt;Finally, if you want to force all web methods to be validated with out using the [Validation] attribute add the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtension, SoapValidation&quot; priority=&quot;1&quot; group=&quot;0&quot; /&amp;gt;<br /> <br /> &amp;lt;/soapExtensionTypes&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Validation&lt;/h3&gt;<br /> &lt;p&gt;Here is a basic example that will cause validation to be run:&lt;/p&gt;&lt;pre&gt;[WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]public&quot;&gt;http://example.org/geometry&quot;)]<br /> public&lt;/a&gt; class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }&lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Assertions&lt;/h3&gt;<br /> <br /> &lt;p&gt;Here is an example of using assertions to verify business rules in a way schema's fall short.&lt;/p&gt;&lt;pre&gt;[AssertNamespaceBinding(&quot;t&quot;, &quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> [WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> public class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> [Assert(&quot;(//t:length * //t:width) &amp;gt; 100&quot;, &quot;Area must be greater than 100&quot;)]<br /> [Assert(&quot;(//t:length div //t:width) = 2&quot;, &quot;Length must be exactly twice width&quot;)]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> &lt;p&gt;&amp;nbsp;&lt;/p&gt;<br /> <br /> [[Category:OWASP .NET Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14205 2006-12-12T04:06:16Z

<p>Meddington: /* Canonicalize data (read: encode before use) */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data to consumer (read: encode before use) ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14204 2006-12-12T03:52:36Z

<p>Meddington: /* Avoid building XML dynamically */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14203 2006-12-12T03:51:53Z

<p>Meddington: /* Canonicalize data (read: encode before use) */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [https://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [/Category:OWASP_Encoding_Project&amp;action=edit Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14202 2006-12-12T03:50:51Z

<p>Meddington: </p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [/Category:OWASP_Encoding_Project&amp;action=edit Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14201 2006-12-12T03:49:57Z

<p>Meddington: /* Avoid building XML dynamically */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [[Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [[Category:OWASP_Encoding_Project&amp;action=edit Check out the OWASP Encoding Project.]]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14200 2006-12-12T03:48:51Z

<p>Meddington: /* Avoid building XML dynamically */</p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> [Category:OWASP_Encoding_Project&amp;action=edit Check out the OWASP Encoding Project.]<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14199 2006-12-12T03:47:01Z

<p>Meddington: </p> <hr /> <div>= AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> Check out the OWASP Encoding Project.<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...<br /> <br /> <br /> = Project Contributors =<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> = Project Sponsor =<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> [[Category:OWASP AJAX Security Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=OWASP_AJAX_Security_Guidelines&diff=14198 2006-12-12T03:39:21Z

<p>Meddington: </p> <hr /> <div><br /> = AJAX Security Guidelines =<br /> <br /> 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.<br /> <br /> == Client Side (Javascript) ==<br /> <br /> === Use .innerText instead of .innerHtml ===<br /> <br /> The use of .innerText will prevent most XSS problems as it will automatically encode the text. Only use innerHtml when you are displaying HTML.<br /> <br /> === Don't use eval ===<br /> <br /> Eval is evil, never use it. Needing to use eval usually indicates a problem in your design.<br /> <br /> === Canonicalize data (read: encode before use) ===<br /> <br /> When using data to build HTML, script, css, XML, Jason, etc. make sure you take into account canonicalization. Data should be properly encoded before used to prevent injection style issues. <br /> <br /> [http://www.owasp.org/index.php/Category:OWASP_Encoding_Project Check out the OWASP Encoding Project.]<br /> <br /> === Don't rely on client logic for security ===<br /> <br /> 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.<br /> <br /> === Don't rely on client business logic ===<br /> <br /> 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.<br /> <br /> === Avoid writing serialization code ===<br /> <br /> 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 JSON page for links.<br /> <br /> === Avoid building XML dynamically ===<br /> <br /> 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.<br /> <br /> Check out the OWASP Encoding Project.<br /> <br /> === Never transmit secrets to the client ===<br /> <br /> I hope this is a &quot;duh&quot; item. Anything the client knows the user will also know, so keep all that secret stuff on the server please.<br /> <br /> === Don't perform encryption in client side code ===<br /> <br /> Use SSL and encrypt on the server!<br /> <br /> === Don't perform security impacting logic on client side ===<br /> <br /> This is the overall one that gets me out of trouble in case I missed something :) <br /> <br /> == ASP.NET ==<br /> <br /> <br /> === Avoid writing serialization code. Remember ref vs. value types! ===<br /> <br /> 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.<br /> <br /> === Services can be called by users directly ===<br /> <br /> 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!).<br /> <br /> === Web service calls are not schema verified ===<br /> <br /> You need to use a 3rd party library to validate web services. <br /> <br /> Check out OWASP .NET Web Service Validation.<br /> <br /> === Avoid building XML by hand, use the framework ===<br /> <br /> Use the framework and be safe, do it by hand and have security issues. Simple.<br /> <br /> === Avoid building JSON by hand, use an existing frameworl ===<br /> <br /> This is to hard to get wrong. Use existing code for this. Check out the JSON site for information.<br /> <br /> == Java ==<br /> <br /> Coming soon....maybe...</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=13903 2006-12-01T19:34:48Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.12.zip Reform-0.12.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP (Unicode issues)<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> <br /> __NOTOC__</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=13391 2006-11-20T04:04:58Z

<p>Meddington: </p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> === Methods of Use ===<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> &lt;h3&gt;Attributes&lt;/h3&gt;<br /> &lt;p&gt;[&lt;strong&gt;Validation&lt;/strong&gt;]&lt;/p&gt;<br /> &lt;p&gt;Mark web method for validation against schemas&lt;/p&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchemaFolder&lt;/strong&gt;(string relativeFolder)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add folders that contain schemas to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The relativeFolder parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;relativeFolder&lt;/em&gt; -- Folder of schemas to load and cache.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;ValidationSchema&lt;/strong&gt;(string schemaFile)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add schema files to load and cache.&amp;nbsp; This attribute is only valid for classes.&amp;nbsp; The schemaFile parameter is relative to the vroot.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;schemaFile&lt;/em&gt; -- Schema file to load.&amp;nbsp; Relative to the virtual root (vroot).&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule)]&lt;br&gt;[&lt;strong&gt;Assert&lt;/strong&gt;(string rule, string description)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Used to add an XPath&amp;nbsp;validation expression to a web method.&amp;nbsp; The XPath expression must evaluate to true.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;rule&lt;/em&gt; -- XPath validation expression.&amp;nbsp; Must evaluate to true. <br /> &lt;li&gt;&lt;em&gt;description&lt;/em&gt; -- [optional] Description of assertion rule.&lt;/li&gt;&lt;/ul&gt;<br /> &lt;p&gt;[&lt;strong&gt;AssertNamespaceBinding&lt;/strong&gt;(string prefix, string ns)]&lt;/p&gt;<br /> <br /> &lt;p&gt;Specifies namespace bindings used by assert xpath's.&lt;/p&gt;<br /> &lt;ul&gt;<br /> &lt;li&gt;&lt;em&gt;prefix&lt;/em&gt; -- namespace prefix <br /> &lt;li&gt;&lt;em&gt;ns&lt;/em&gt; -- namespace to map to&lt;/li&gt;&lt;/ul&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Web.config Changes&lt;/h3&gt;<br /> &lt;p&gt;First two extensions must be registered by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;<br /> <br /> &lt;p&gt;&lt;/p&gt;<br /> &lt;p&gt;&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtensionReflector, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/soapExtensionReflectorTypes&amp;gt;<br /> &amp;lt;serviceDescriptionFormatExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationFormatExtension, SoapValidation&quot;/&amp;gt;<br /> &amp;lt;/serviceDescriptionFormatExtensionTypes&amp;gt; <br /> &lt;/pre&gt;<br /> &lt;p&gt;Next, POST and GET protocols must be disabled by adding the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;protocols&amp;gt;<br /> <br /> &amp;lt;remove name=&quot;HttpPost&quot; /&amp;gt;<br /> &amp;lt;remove name=&quot;HttpGet&quot; /&amp;gt;<br /> &amp;lt;/protocols&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;p&gt;Finally, if you want to force all web methods to be validated with out using the [Validation] attribute add the following inside of the &amp;lt;webServices&amp;gt; node:&lt;/p&gt;&lt;pre&gt;&amp;lt;soapExtensionTypes&amp;gt;<br /> &amp;lt;add type=&quot;SoapValidation.ValidationExtension, SoapValidation&quot; priority=&quot;1&quot; group=&quot;0&quot; /&amp;gt;<br /> <br /> &amp;lt;/soapExtensionTypes&amp;gt;<br /> &lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Validation&lt;/h3&gt;<br /> &lt;p&gt;Here is a basic example that will cause validation to be run:&lt;/p&gt;&lt;pre&gt;[WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]public&quot;&gt;http://example.org/geometry&quot;)]<br /> public&lt;/a&gt; class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }&lt;/pre&gt;<br /> &lt;hr&gt;<br /> <br /> &lt;h3&gt;Using Assertions&lt;/h3&gt;<br /> <br /> &lt;p&gt;Here is an example of using assertions to verify business rules in a way schema's fall short.&lt;/p&gt;&lt;pre&gt;[AssertNamespaceBinding(&quot;t&quot;, &quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> [WebService(Namespace=&quot;&lt;a href=&quot;http://example.org/geometry&amp;quot;)]&quot;&gt;http://example.org/geometry&quot;)]&lt;/a&gt;<br /> public class SimpleTests : System.Web.Services.WebService<br /> { <br /> [WebMethod]<br /> [Validation]<br /> [Assert(&quot;(//t:length * //t:width) &amp;gt; 100&quot;, &quot;Area must be greater than 100&quot;)]<br /> [Assert(&quot;(//t:length div //t:width) = 2&quot;, &quot;Length must be exactly twice width&quot;)]<br /> public double CalcArea2(double length, double width)<br /> {<br /> return length * width;<br /> }<br /> }<br /> &lt;/pre&gt;<br /> &lt;p&gt;&amp;nbsp;&lt;/p&gt;<br /> <br /> [[Category:OWASP .NET Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=13390 2006-11-20T03:57:37Z

<p>Meddington: </p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> === Methods of Use ===<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> <br /> <br /> [[Category:OWASP .NET Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=13385 2006-11-20T03:18:31Z

<p>Meddington: </p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Methods of Use ==<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.<br /> <br /> [[Category:OWASP .NET Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=13383 2006-11-20T03:15:32Z

<p>Meddington: /* .NET Web Service Validation */</p> <hr /> <div>There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> == Performance Penalties ==<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> == Downloading ==<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> <br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> == Installation ==<br /> <br /> Download the installer and run. Easy :)<br /> <br /> == Methods of Use ==<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> == Use ==<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> == Reporting Bugs ==<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.</div>

Meddington https://wiki.owasp.org/index.php?title=.NET_Web_Service_Validation&diff=13382 2006-11-20T03:14:18Z

<p>Meddington: </p> <hr /> <div><br /> == .NET Web Service Validation ==<br /> <br /> There was a great article on MSDN a while back (years at this point) that showed the creation of a SOAP extension that would verify incoming requests against a schema, something .NET does not support out of the box (even in 2.0). Additionally there was quasi support for [http://www.schematron.com/ schematron] via Assert attributes. This allows for a very powerful input validation of web services.<br /> <br /> This is a project to provide continued support for this extension. There have been some updates to the original code, including moving to the .NET Framework v2.0.<br /> <br /> The original article is available [http://msdn.microsoft.com/msdnmag/issues/03/07/XMLSchemaValidation/ here].<br /> <br /> '''Performance Penalties'''<br /> <br /> To add in XML schema validation we must parse the soap packet ourselves. This of course will incur an additional performance hit outside of simply turning on validation. Unfortunately there is no method (that I'm aware of) to enable schema validation in .NET currently.<br /> <br /> '''Downloading'''<br /> <br /> [http://phed.org/files/SoapValidation-0.5.msi SoapValidation-0.5.msi] - Assembly, documentation, samples<br /> [http://phed.org/files/SoapValidation-0.5-src.zip SoapValidation-0.5-src.zip] - Source, documentation, samples<br /> <br /> '''Installation'''<br /> <br /> Download the installer and run. Easy :)<br /> <br /> '''Methods of Use'''<br /> <br /> There are two methods for using the validator. First you can force all web methods to be validated using the web.config file. Second you can mark methods using [Validation] attribute.<br /> <br /> '''Use'''<br /> <br /> Add a reference to SoapValidator.dll from your web service project. Modify your web.config to include the required settings and add attributes to classes and/or methods. See examples later.<br /> <br /> '''Reporting Bugs'''<br /> <br /> Report bugs to Michael Eddington @ meddington@phed.org.</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=13379 2006-11-20T03:08:33Z

<p>Meddington: /* Project Contributors */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.11.zip Reform-0.11.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP (Unicode issues)<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> [http://phed.org Michael Eddington]<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]<br /> [[Category:OWASP Download]]<br /> [[Category:OWASP Tool]]<br /> <br /> __NOTOC__</div>

Meddington https://wiki.owasp.org/index.php?title=Talk:Preventing_LDAP_Injection_in_Java&diff=12627 2006-11-14T22:47:52Z

<p>Meddington: </p> <hr /> <div>Question - would it be better to encode using a whitelist approach? I.e. encode everything that is not in a limited set of safe characters? Jeff Williams - 11:54, 14 August 2006 (EDT) <br /> <br /> :My only concern with that approach is that we'll be breaking the spec- some LDAP implementations may not handle escaped characters that are not meta-characters properly. [[User:Stephendv|Stephendv]] 07:23, 11 September 2006 (EDT)<br /> <br /> ::Then perhaps a rule that only allows a limited set of characters AND encodes any of those that are meta-characters would work [[User:Jeff Williams|Jeff Williams]] 15:33, 11 September 2006 (EDT)<br /> <br /> While for DN there is some provision for specifying a byte encoding (\XX) there is by spec only certain characters that should be encoded: , (comma), = (equals), + (plus), &lt; (less than), &gt; (greater than), # (number sign), ; (semicolon), \ (backslash), and &quot; (quotation mark, ASCII 34)<br /> <br /> Method 1: Escape chars, only , = + &lt; &gt; # ; \ are valid to be escaped:<br /> <br /> CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB<br /> <br /> Method 2: Replace with hex digits, unknown if all LDAP servers limit to just valid chars to escape:<br /> <br /> CN=L. Eagle,O=Sue\2C Grabbit and Runn,C=GB<br /> <br /> Method 3: Quote attribute and escape \ or &quot;:<br /> <br /> &quot;you need to escape a single backslash this way \\&quot;</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12363 2006-11-12T10:12:16Z

<p>Meddington: /* Features */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.11.zip Reform-0.11.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP (Unicode issues)<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12362 2006-11-12T10:11:53Z

<p>Meddington: /* Features */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.11.zip Reform-0.11.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP (Unicode support broken)<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> ** ASP<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12361 2006-11-12T10:11:25Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.11.zip Reform-0.11.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12360 2006-11-12T10:11:10Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.11.zip Reform-0.11.zip] (stable)<br /> [http://phed.org/files/Reform-0.10.zip Reform-0.10.zip]<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12255 2006-11-11T00:52:25Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> [http://phed.org/files/Reform-0.10.zip Reform-0.10.zip] (stable)<br /> <br /> The latest code is now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12254 2006-11-11T00:48:24Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> The most recent released version of Reform can be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=149309].<br /> <br /> The latest code is also now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12086 2006-11-09T02:02:19Z

<p>Meddington: /* Download */</p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> The most recent released version of Reform can be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=149309].<br /> <br /> The latest code is also now being maintained in a Google Code repository [http://code.google.com/p/reform/] (well, we are moving things over. check out sf.net for now)<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington https://wiki.owasp.org/index.php?title=Category:OWASP_Encoding_Project&diff=12085 2006-11-09T01:58:58Z

<p>Meddington: </p> <hr /> <div>== Overview ==<br /> <br /> Web applications face any number of threats; one of them is cross-site scripting and related injection attacks. 90% of all web applications contain cross-site scripting attacks because they are easy to introduce, and the proper tools are not always available to prevent them. There is no good single library that provides all the functions required by developers to incorporate a fix into there code that will stand up to the test of time and continual research in the field. The Reform library attempts to provide a solid set of functions for encoding output for the most common context targets in web applications (e.g. HTML, XML, JavaScript, etc). The library also takes a conservative view of what are allowable characters based on historical vulnerabilities, and current injection techniques.<br /> <br /> == Goals ==<br /> <br /> * Provide tools needed by developers to mitigate canonicalization issues in web technologies.<br /> * Provide a solution that will not need to be patched (no security patches since release in 2004, private implementations in use since 2002).<br /> <br /> == Download ==<br /> <br /> The most recent released version of Reform can be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=149309].<br /> <br /> The latest code is also now being maintained in a Google Code repository [http://code.google.com/p/reform/]<br /> <br /> == Features ==<br /> <br /> * Unicode support<br /> * Context specific functions (HTML, XML, JavaScript, etc)<br /> * Many supported languages<br /> ** Java<br /> ** .NET v1/v2<br /> ** PHP<br /> ** Python<br /> ** Perl<br /> ** JavaScript<br /> * Support for AJAX<br /> * Conservative approach<br /> * Solves all current XSS techniques<br /> <br /> == Future Development ==<br /> <br /> * Ruby support<br /> * Java framework support<br /> * LDAP encoding functions<br /> * Add documentation on resolving XPath issues<br /> <br /> == News ==<br /> <br /> '''OWASP Encoding Project Adopts Reform - 10:01, 8 November 2006 (EST)'''<br /> <br /> OWASP is adopting the Reform Encoding Library as an OWASP project. We are currently in the process of moving over the source, downloads, and documentation.<br /> <br /> '''OWASP Encoding Project Created! - 10:01, 8 November 2006 (EST)'''<br /> <br /> The Open Web Application Security Project is proud to announce the OWASP Encoding Project!<br /> <br /> == Feedback and Participation: ==<br /> <br /> We hope you find the OWASP Encoding Project useful. Please contribute to the Project by volunteering for one of the tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Encoding Project mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-encoding subscription page.]<br /> <br /> == Project Contributors ==<br /> <br /> Michael Eddington<br /> <br /> == Project Sponsor ==<br /> <br /> [http://leviathansecurity.com Leviathan Security Group, Inc.]<br /> <br /> [[Category:OWASP Project]]</div>

Meddington