|
|
| (94 intermediate revisions by 6 users not shown) |
| Line 2: |
Line 2: |
| | <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> |
| | | | |
| − | {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| + | The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| − | | valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
| |
| − | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
| |
| − | <br/>
| |
| − | __TOC__{{TOC hidden}}
| |
| − | = Introduction =
| |
| | | | |
| − | The rationale for third party vendor javascript ('tags') is to provide data from the user's browser DOM to the vendor for some form of marketing analysis. This data can be anything available in the DOM. The data is used for user navigation and clickstream analysis, identification of the user to determine further content to display etc., and various marketing analysis functions.
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html 3rd Party Javascript Management Cheat Sheet] to see the |
| − | | |
| − | The term 'host' refers to the original site the user goes to, such as a shopping or news site, that contains or retrieves and executes third party javascript for marketing analysis of the user actions.
| |
| − | | |
| − | = 3rd Party JavaScript Deployment Architectures =
| |
| − | | |
| − | There are three basic deployment mechanisms for third party vendor javascript, or 'tags'.
| |
| − | | |
| − | == 1. Vendor Javascript on page ==
| |
| − | | |
| − | This is where the vendor provides the host with the javascript and the host puts it on the host page. To be secure the host company must review the code for any vulnerabilities like cross site scripting or malicious actions such as sending sensitive data from the DOM to a malicious site. This is often difficult because the javascript is commonly obfuscated.
| |
| − | | |
| − | == 2. Javascript Request to Vendor ==
| |
| − | | |
| − | There are two mechanisms to request javascript from a third party as your host page is rendering.
| |
| − | | |
| − | [[Direct from the vendor]] - This is where one or a few lines of code on the host page each request a javascript file or URL directly from the vendor site. When the host page is being created, the developer includes the lines of code provided by the vendor that will request the vendor javascript.
| |
| − | Each time the page is accessed the requests are made to the vendor site for the javascript, which then executes on the user browser.
| |
| − | | |
| − | [[Indirect from a tag aggregator or tag manager]] - This is where one or a few lines of code on the host page each request a javascript file or URL from a tag aggregator or tag manager site; not from the javascript vendor site. The tag aggregator or tag manager site returns whatever third party javascript files that the host company has configured to be returned. Each file or URL request to the tag manager site can return lots of other javascript files from multiple vendors.
| |
| − | | |
| − | The actual content that is returned from the aggregator or manager (i.e. the javascript files and exactly what they do) can be dynamically changed by host site employees using a graphical user interface that non-technical users can work with, such as the marketing part of the business. The changes can be either 1. get a different javascript file from the 3rd party vendor for the same request; 2. change what DOM object data is read by the 3rd party vendor javascript to send to the vendor.
| |
| − | | |
| − | This is difficult to make secure because you can only see the code if you proxy the requests or if you get access to the GUI and see what is configured. It is also instantly deployable because each new page request from a browser executes the requests to the aggregator which gets the javascript from the third party vendor. So as soon as any javascript files are changed on the vendor, or modified on the aggregator, the next call for them from any browser will get the changed javascript.
| |
| − | | |
| − | == 3. Server Direct ==
| |
| − | | |
| − | With this mechanism, javascript you (the host site owner) write and put on your page sends the data values to the vendor, or to a tag manager or tag aggregator site which then sends the data to vendors. This the most secure technique because only your javascript executes on your users browser, and only the data you decide on is sent to the vendor.
| |
| − | | |
| − | This requires cooperation between the host, the aggregator or tag manager and the vendors.
| |
| − | | |
| − | The host developers have to work with the vendor in order to know what type of data the vendor needs to do their analysis. Then the host programmer determines what DOM element will have that data.
| |
| − | | |
| − | The host developers have to work with the tag manager or aggregator to agree on the protocol to send the data to the aggregator: what URL, parameters, format etc.
| |
| − | | |
| − | The tag manager or aggregator has to work with the vendor to agree on the protocol to send the data to the vendor: what URL, parameters, format etc. Does the vendor have an API?
| |
| − | | |
| − | | |
| − | = Security Standards =
| |
| − | | |
| − | The server direct mechanism is a good security standard for third party javascript management, deployment and execution. A good practice for the host page is to create a data layer of DOM objects. The data layer is either 1. a DIV object with attribute values that have the marketing or user behavior data that the 3rd party wants. or 2. a set of JSON objects with the same data. Each variable or attribute contains the value of some DOM element. The data layer is the complete set of values that all vendors need for that page.
| |
| − | The data layer can also perform any validation of the values, especially values from DOM objects exposed to the user like URL parameters and input fields, if these are required for the marketing analysis.
| |
| − | | |
| − | An example statement for a corporate standard document is 'The tag javascript can only access values in the host data layer. The tag javascript can never access a URL parameter.'.
| |
| − | | |
| − | You the host page developer have to agree with the 3rd party vendors what attribute in the data layer will have what value so they can create the javascript to read that value.
| |
| − | | |
| − | For indirect requests to tag manager/aggregator sites that offer the GUI to configure the javascript, they may also implement technical controls such as only allowing the javascript to access the data layer values, no other DOM element. The host company should also verify the security practices of the tag manager site such as access controls to the tag configuration for the host company.
| |
| − | | |
| − | Letting the marketing folks decide where to get the data they want can result in XSS because they may get it from a URL parameter and put it into a variable that is in a scriptable location on the page.
| |
| − | | |
| − | = Do it Yourself =
| |
| − | | |
| − | Bringing this features all in house may not be feasible given the number of different 3rd (and 4th and 5th) party scripts used (sometimes more than 50) and the business functions they perform, and the speed with which the business needs to turn on, change and turn off various functions.
| |
| − | | |
| − | = Vendor Agreements =
| |
| − | | |
| − | You can have the agreement with the 3rd parties say that they have to implement and prove secure coding and general corporate security.
| |
| − | | |
| − | == Authors and Primary Editors ==
| |
| − | | |
| − | | |
| − | | |
| − | == Other Cheatsheets ==
| |
| − | | |
| − | {{Cheatsheet_Navigation_Body}}
| |
| − | [[Category:Cheatsheets]]
| |
