User Tools

Site Tools


projects:policy_discussion

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
projects:policy_discussion [2010/05/15 16:08]
disnet
projects:policy_discussion [2010/05/25 15:49] (current)
cormac
Line 2: Line 2:
  
 ===== Information Flow Channels ===== ===== Information Flow Channels =====
-In this section we are trying to highlight various fields in JavaScript that an attacker can use to transmit information. We distinguish between immediate channels ​were modifying this fields sends information to an attacker and delayed channels were no information is sent to the attacker until the user performs some action.+In this section we  highlight various fields in JavaScript that an attacker can use to transmit information. We distinguish between immediate channels ​where modifying this fields sends information to an attacker and delayed channels were no information is sent to the attacker until the user performs some action.
  
-====== Delayed Channels ​====== +==== Delayed Channels ==== 
-* href attribute of links (<​a>​) +  * href attribute of links (<​a>​) 
-* form submission (elements of the form)+  * form submission (elements of the form) 
 +==== Immediate Channels ==== 
 +  * cross-site loading tags (in the DOM) 
 +    * script (src attribute) 
 +    * link (href attribute), for stylesheets 
 +    * img (src attribute) 
 +    * video (src attribute or source elements) 
 +    * audio (src attribute or source elements) 
 +    * object/​embed (flash, java applets, etc.) 
 +    * ifame (src attribute) 
 +  * XmlHttpRequest (XHR) 
 +  * form.submit 
 +  * postMessage
  
-===== Immediate Channels ===== 
-* cross-site loading tags (in the DOM) 
-  * script.src (src attribute) 
-  * link.href (src attribute) 
-  * img (src attribute) 
-  * video (src attribute or source elements) 
-  * audio (src attribute or source elements) 
-  * object/​embed (flash, java applets, etc.) 
-  * ifame (src attribute) 
-* XmlHttpRequest (XHR) 
-* form.submit 
-* postMessage 
  
 +===== Storage =====
 +For storage channels data is not directly transmitted to an outside source. ​ However, any security labels need to be persisted along with the data or these need to be treated like delayed channels.
 +  * cookies
 +  * window.name
 +  * sessionStorage (html5 web storage)
 +  * localStorage (html5 web storage)
 +  * persistence mechanisms for flash (or other plugins)
  
-=== Storage ​=== +===== Security Lattice ===== 
-For storage channels data is not directly transmitted to an outside sourcehowever any security labels need to be persisted along with the data or these need to be delayed channels.+For confidentialitywe assume that each origin may be its own security principal.  
 +We note that '​http://​ucsc.edu'​ and '​http://​soe.ucsc.edu'​ are different principals,​ 
 +as are '​http://​ucsc.edu'​ and '​https://​ucsc.edu'​. 
 +In addition we have a LOCAL_ONLY principal for data that should never leave the client
  
-* cookies +In order to safely handle exfiltration attacks, we will also need a notion of integrity For all data, we will need to track which principals have influenced the data.  ​(Note that without declassification,​ the moment that more than one principal have affected any confidential data item, it becomes LOCAL_ONLY).
-* window.name +
-* sessionStorage ​(html5 web storage) +
-* localStorage (html5 web storage) +
-* persistence mechanisms for flash (or other plugins)+
  
-== Security Lattice ​== +===== Confidential Fields ===== 
-We assume that each origin ​may be its own security ​principal. ​In addition we have a LOCAL_ONLY ​label for data that should never leave the client+  * passwords -- allow sending to submission ​origin ​but only if not influenced by another ​principal. ​Perhaps also restrict output channels to form submission and XHR? 
 +  * geolocation -- LOCAL_ONLY, unless the user authorizes its release (this would allow us to possibly securely loosen the current restrictions on geolocation). 
 +  * HTML elements/​attributes marked as confidential by the website'​s developers.
  
-== Confidential Fields ​== +====XHR =====
-* passwords -- allow sending to submission origin but only if not influenced by another principal. Perhaps also restrict output channels to form submission and XHR+
-* geolocation -- LOCAL_ONLY, unless the user authorizes its release (this would allow us to possibly securely loosen the current restrictions on geolocation). +
-* HTML elements/​attributes marked as confidential by the website'​s developers. +
- +
-== XHR ==+
 Since XHR can be used to pull sensitive data from different pages we need to handle its results with some care. Since XHR can be used to pull sensitive data from different pages we need to handle its results with some care.
-* By default SSL secured resources are treated as confidential to the origin. +  ​* By default SSL secured resources are treated as confidential to the origin. 
-* By default other results from XHR are treated as public +  * By default other results from XHR are treated as public 
-* Both of the above cases may be changed by the developer via HTTP headers+  * Both of the above cases may be changed by the developer via HTTP headers
  
-== DOM ==+===== DOM =====
 In this section we discuss a possible approach to limit a scripts access to the DOM. In this section we discuss a possible approach to limit a scripts access to the DOM.
-* an external configuration file specifies which external scripts have access to which DOM elements +  ​* an external configuration file specifies which external scripts have access to which DOM elements 
-* local script files and inline JavaScript have no restriction to the DOM +  * local script files and inline JavaScript have no restriction to the DOM 
-  * note that this will not stop all forms of XSS attacks but might limit the number of characters available to write the attacking script (e.g. the DB fields with size limits)+    * note that this will not stop all forms of XSS attacks but might limit the number of characters available to write the attacking script (e.g. the DB fields with size limits
 + 
 +===== Mashup Use-Cases ===== 
 +  * analytics -- do not need access to the DOM? 
 +  * most advertisements -- need only modify/​select specific DOM elements 
 +  * embedded maps, videos, etc. -- generally only modify specific DIV/SPAN elements 
 +  * target-word adds -- need extensive access to the DOM (example can be seen at: http://​www.tomshardware.com/​reviews/​core-i3-530-overclock-lga-1156,​2626-4.html)
  
-== Mashup Use-Cases ​== +===== Exfiltration ===== 
-* analytics -- do not need access ​to the DOM? +Exfiltration attacks present a significant threat ​to confidentiality for information flow analysis. ​ In shortexfiltration attacks involve sending confidential information back to its originbut to another account.  ​(For example, ​an attacker might send someone else's confidential information from Facebook back to his own Facebook account).
-* most advertisements -- need only modify/​select specific DOM elements +
-* embedded mapsvideosetc. -- generally only modify specific DIV/SPAN elements +
-* target-word adds -- need extensive access ​to the DOM (example ​can be seen at: http://​www.tomshardware.com/​reviews/​core-i3-530-overclock-lga-1156,2626-4.html)+
  
-== Exfiltration == +In order to defend against these attacks, we will need to add a notion of integrity. ​ Confidential data can only be sent back to its origin if the decision to do so was not influenced by any other principal. ​ (This solution is one proposed for safe declassification).
-TODO+
  
 +We note that cross-site loading tags (e.g. image tags) might not require this restriction,​ since it does not seem likely that a site would use these tags to pass information between accounts.
projects/policy_discussion.1273964881.txt.gz · Last modified: 2010/05/15 16:08 by disnet