This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "AJAX Security Cheat Sheet"
m (Remove wrong CS category) |
Thunder-Son (talk | contribs) (Migration to GitHub) |
||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
− | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div> | + | <div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
+ | Please visit [https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/AJAX_Security_Cheat_Sheet.md AJAX Security Cheat Sheet] to see the latest version of the cheat sheet. | ||
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- | {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- | ||
− | | | + | | style="border-right: 1px dotted gray;padding-right:25px;" valign="top" | |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
− | <br/> | + | <br /> |
__TOC__{{TOC hidden}} | __TOC__{{TOC hidden}} | ||
Line 106: | Line 107: | ||
== Authors and Primary Editors == | == Authors and Primary Editors == | ||
− | Til Mas<br/> | + | Til Mas<br /> |
Michael Eddington | Michael Eddington | ||
Line 114: | Line 115: | ||
[[Category:Cheatsheets]] | [[Category:Cheatsheets]] | ||
[[Category:OWASP AJAX Security Project]] | [[Category:OWASP AJAX Security Project]] | ||
+ | |} |
Revision as of 07:09, 11 February 2019
The Cheat Sheet Series project has been moved to GitHub!Please visit AJAX Security Cheat Sheet to see the latest version of the cheat sheet.
Last revision (mm/dd/yy): 02/11/2019
IntroductionThis document will provide a starting point for AJAX security and will hopefully be updated and expanded reasonably often to provide more detailed information about specific frameworks and technologies. Client Side (Javascript)Use .innerText instead of .innerHtmlThe use of .innerText will prevent most XSS problems as it will automatically encode the text. Don't use evalEval is evil, never use it. Needing to use eval usually indicates a problem in your design. Canonicalize data to consumer (read: encode before use)When using data to build HTML, script, CSS, XML, JSON, etc. make sure you take into account how that data must be presented in a literal sense to keep it's logical meaning. Data should be properly encoded before used in this manner to prevent injection style issues, and to make sure the logical meaning is preserved. Check out the OWASP Encoding Project. Don't rely on client logic for securityLeast ye have forgotten the user controls the client side logic. I can use a number of browser plugging to set breakpoints, skip code, change values, etc. Never rely on client logic. Don't rely on client business logicJust like the security one, make sure any interesting business rules/logic is duplicated on the server side less a user bypass needed logic and do something silly, or worse, costly. Avoid writing serialization codeThis 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. Avoid building XML or JSON dynamicallyJust like building HTML or SQL you will cause XML injection bugs, so stay way from this or at least use an encoding library or safe JSON or XML library to make attributes and element data safe. Never transmit secrets to the clientAnything the client knows the user will also know, so keep all that secret stuff on the server please. Don't perform encryption in client side codeUse TLS/SSL and encrypt on the server! Don't perform security impacting logic on client sideThis is the overall one that gets me out of trouble in case I missed something :) Server SideUse CSRF ProtectionProtect against JSON Hijacking for Older BrowsersReview AngularJS JSON Hijacking Defense MechanismSee "JSON Vulnerability Protection" from https://docs.angularjs.org/api/ng/service/$http Always return JSON with an Object on the outsideAlways have the outside primitive be an object for JSON strings: Exploitable: [{"object": "inside an array"}] Not exploitable: {"object": "not inside an array"} Also not exploitable: {"result": [{"object": "inside an array"}]} Avoid writing serialization code. Remember ref vs. value types!Look for an existing library that has been reviewed. Services can be called by users directlyEven though you only expect your AJAX client side code to call those services the users can too. Make sure you validate inputs and treat them like they are under user control (because they are!). Avoid building XML or JSON by hand, use the frameworkUse the framework and be safe, do it by hand and have security issues. Use JSON And XML Schema for WebservicesYou need to use a 3rd party library to validate web services. Authors and Primary EditorsTil Mas Other Cheatsheets |