extensions/webservices/docs/New_Security_Model.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
   2 <html>
   3 <head>
   4   <title>Securing Untrusted Scripts Behind Firewalls</title>
   5   <meta http-equiv="content-type"
   6  content="text/html; charset=ISO-8859-1">
   7 </head>
   8 <body>
   9 <h1 style="text-align: center;">Securing Resources from Untrusted
  10 Scripts Behind Firewalls<big><span style="font-weight: bold;"></span></big></h1>
  11 <h1 style="text-align: center;"><small><small><big><span
  12  style="font-weight: normal;">by</span></big>&nbsp;</small></small><big><big><span
  13  style="font-weight: bold;"></span></big></big></h1>
  14 <h1 style="text-align: center;"><small style="font-weight: normal;"><a
  15  href="mailto:rayw@netscape.com">Ray Whitmer</a> and <a
  16  href="maiilto:harishd@netscape.com">Harish Dhurvasula</a></small><br>
  17 </h1>
  18 <h2>Introduction<br>
  19 </h2>
  20 This page describes an alternative mechanism which can be used to
  21 protect  all internal resources against requests from sandboxed
  22 scripts. &nbsp;This  should especially be implemented for SOAP calls
  23 by untrusted scripts. &nbsp;When  an attempt is made to access a
  24 resource at a previously-unknown URI, the sandbox reads a file at that
  25 domain with declarations to determine whether access is permitted to
  26 the script. &nbsp;If the file is not there, access is denied.<br>
  27 <h2>The Problem<br>
  28 </h2>
  29 External untrusted scripts loaded behind a firewall are executed in a
  30 sandbox. &nbsp;These scripts may legitimately require access to external
  31 resources, but permitting them to access internal resources permits the
  32 compromise of  these resources that would normally not be available to
  33 applications outside  of the firewall. &nbsp;The sandbox must
  34 distinguish and protect internal resources.<br>
  35 <h2>Client-controlled Solutions</h2>
  36 Several client-controlled solutions have been designed to prevent
  37 sandboxed  applications loaded behind a firewall from compromising
  38 other resources protected  behind the firewall.
  39 <h3> Same Source Restriction.</h3>
  40 By restricting sandboxed scripts to access only resources in the domain
  41 from which they were loaded, any script loaded from one domain into
  42 another  is prevented from accessing &nbsp;resources in the domain
  43 into which it has  been loaded. &nbsp;This policy has generally been
  44 successful in sandboxing  Javascript and Java applets across the web.<br>
  45 <br>
  46 If the sandbox is unable to distinguish the common URI substring of the
  47  domain to be trusted from similar URIs of untrusted domains, then it
  48 could  allow a script loaded from an indistinguishable domain to
  49 exploit firewall-protected  resources.<br>
  50 <br>
  51 Also, this technique prevents the script from accessing many legitimate
  52  external resources not provided in the same domain as the script.
  53 &nbsp;This  prevents a script from accessing web services and data
  54 published from any  domain besides its own.<br>
  55 <h3>White-listing</h3>
  56 By creating a white list of trusted URIs from which scripts are trusted
  57  to not compromise internal resources, it is possible to release domains
  58 from the stricter same-source sandbox. &nbsp;A white list is a good tool
  59 for including  always-trusted domains, but on the web, it is often a
  60 script from a relatively-untrusted  domain that must be granted access
  61 to other untrusted domains, without compromising  internal domains.<br>
  62 <br>
  63 More-complex access lists could be created to try to establish, with
  64 finer  granularity, which domains are to be accessible or permitted
  65 from which other  domains, but this requires extensive management which
  66 at best is quite error-prone  for the end user and easily opens holes
  67 in a firewall that do not directly  hurt the user who reconfigured his
  68 browser to try to access some external  service but hurts the owners of
  69 other services behind the firewall.<br>
  70 <h3>Signed Scripts</h3>
  71 A certain degree of additional trust may be lent to a script by having
  72 the author digitally sign it. &nbsp;But signed scripts have not really
  73 caught  on as they require certificates do not change the basic
  74 problem that some  completely-unknown party has written a script that
  75 might now have access to internal resources.<br>
  76 <h3>Asking the User</h3>
  77 Where the sandbox cannot otherwise determine whether the executing
  78 script  should be permitted access to the resource, a dialog box may
  79 be raised to  ask the user to grant special privileges. &nbsp;This is
  80 currently permitted  for locally-saved scripts and signed scripts.
  81 &nbsp;This could be combined  with the other options above such as
  82 whitelisting, signed scripts, etc. &nbsp;But  the big problem with this
  83 is that the typical browser user really does not  either understand or
  84 pay the consequences if he inadvertently opens a hole  in his company's
  85 firewall. &nbsp;Quite complex settings may be required to  permit the
  86 user to allow access to desired external services without risking
  87 other resources.<br>
  88 <h2>Controlling Resource Access on the Server</h2>
  89 Access by untrusted scripts really needs to be under the control of the
  90  stake holder, which is the resource and server owner -- not the user --
  91 to determine whether a resource should be insulated from web
  92 applications loaded  from outside of the firewall.<br>
  93 <h3>Using a SOAP Header for Verification</h3>
  94 SOAP messages have a distinct processing model allowing a header to be
  95 added that the recipient is required to understand and accept, which
  96 identifies  the untrusted source of a script making a request.
  97 &nbsp;SOAP services which  have not been cleared for access by
  98 untrusted scripts will reject the requests.  &nbsp;This is offered in
  99 the Mozilla implementation of SOAP today.<br>
 100 <br>
 101 Unfortunately, this does not prevent SOAP messages from being sent to
 102 non-SOAP addresses, which is a big enough problem that the verification
 103 cannot stand  alone to guarantee that untrusted service requests are
 104 always properly rejected  by services that should be firewall-protected.<br>
 105 <br>
 106 It may also be inconvenient to modify a SOAP service to ignore the
 107 specific  verification header.<br>
 108 <h3>Using a Declarations File<br>
 109 </h3>
 110 A more robust solution is to rely on getting a file named "<code>web-scripts-access.xml</code>"
 111 in the root directory of the server that the sandboxed script requests
 112 to  communicate with. &nbsp;It should be fairly easy for most
 113 providers of public  resources to create.<br>
 114 <h2>Web Scripts Access Statements<br>
 115 </h2>
 116 The syntax of statements of the access file are as follows.
 117 <pre>&lt;!ELEMENT webScriptAccess (delegate?|allow*)&gt;<br>&lt;!ELEMENT delegate EMPTY&gt;<br>&lt;!ELEMENT allow EMPTY&gt;<br>&lt;!ATTLIST allow type|from CDATA #IMPLIED&gt;.<br></pre>
 118 <h3>The Root Element<br>
 119 </h3>
 120 The first element of the file should be the following:<br>
 121 <code><br>
 122 &lt;wsa:webScriptAccess
 123 xmlns:wsa="http://www.mozilla.org/2002/soap/security</code>"&gt;<br>
 124 <h3>Delegation</h3>
 125 If the &lt;<code>delegate</code>/&gt; element is present then "<code>web-scripts-access.xml</code>"
 126 is required in the subdirectory for URIs which are in a subdirectory.
 127 &nbsp;For  example, if the script in question is "<code>http://www.example.com/foo/bar.xml</code>",
 128 then the declarations file <code>http://www.example.com/web-scripts-access.xml</code>
 129 which contains the "<code>delegate</code>" keyword delegates to <code>http://www.example.com/foo/web-scripts-access.xml</code>.
 130 &nbsp;If the URI is in a subdirectory, and the root directory's access
 131 file  delegated but no access file exists in the subdirectory, then no
 132 access is  granted. &nbsp;If the root's access file did not delegate,
 133 then that access  file also handles all resources in subdirectories.<br>
 134 <br>
 135 Any syntax error in the document will result in the rest of the file to
 136 be ignored. &nbsp;Since the commands only allow access, the order of
 137 processing the "<code>allow</code>" commands that were successfully
 138 parsed is never significant.<br>
 139 <h3>Allowing Web Script Access</h3>
 140 To permit scripts to access the resources of this server, use the
 141 following  command:<br>
 142 <br>
 143 <code>&lt;wsa:allow</code> <code></code>type="&lt;request-type&gt;" <code>from</code>
 144 ="&lt;uri-prefix&gt;"/&gt;<br>
 145 <br>
 146 The type of request, if specified, will be checked against the type of
 147 request being requested by the script, such as <code></code>"<code>soap</code>",
 148 "<code>soapv</code>", or "<code>load</code>". &nbsp;Types must not
 149 contain spaces. &nbsp;Specify "<code>any</code>" as the type to permit
 150 any requested type of access to resources.<br>
 151 <br>
 152 The principle URI of the script will be checked for the specified URI
 153 prefix. &nbsp;If "<code>from</code>" is not specified, then all scripts
 154 will be allowed. <span style="font-weight: bold;">Note:</span> One can
 155 also use wild character(s) in "from" value.<br>
 156 <br>
 157 For example:<br>
 158 <code><br>
 159 &lt;wsa:allow type="soapv" from="http://www.mozilla.org"/&gt;</code><br>
 160 <br>
 161 This command allows SOAP requests with verification headers from
 162 scripts  loaded from the domain www.mozilla.org.<br>
 163 <br>
 164 <code> &lt;wsa:allow type="soapv" from="http://*.mozilla.org"/&gt;<br>
 165 <br>
 166 </code> This command allows SOAP requests with verification headers from
 167 scripts  loaded from the domain with host name containing mozilla.org.
 168 That is, http://www.mozilla.org/, http://lxr.mozilla.org,
 169 http://komodo.mozilla.org, etc. will be granted access.<br>
 170 <h2>Implementation</h2>
 171 <span style="font-weight: bold;">nsIWebScriptsAccessService</span><br>
 172 This interface provides a way to check whether the running script has
 173 access to the server that the script wishes to communicate.<br>
 174 <span style="text-decoration: underline;"></span><span
 175  style="font-style: italic;"></span><span style="font-style: italic;"></span>
 176 <ul>
 177   <li>boolean canAccess(in nsIURI aTransportURI, in AString aType);</li>
 178   <ul>
 179     <li>aTransportURI - The service URI&nbsp;</li>
 180     <li>aType - Type requested &nbsp;by the script ( ex. soapv, soap,
 181 load, etc. )</li>
 182     <li>return PR_TRUE if access granted else PR_FALSE</li>
 183   </ul>
 184   <li> void invalidateCache(in string aTransportURI);</li>
 185   <ul>
 186     <li>Invalidate cached entry for the given transport uri.</li>
 187     <li>Empty the cache by passing in a empty string<br>
 188     </li>
 189   </ul>
 190 </ul>
 191 <ul>
 192   <ul>
 193   </ul>
 194 </ul>
 195 <span style="text-decoration: underline;">nsWebScriptsAccess</span>&nbsp;
 196 ( <span style="font-style: italic;">Implements
 197 nsIWebScriptsAccessService)<br>
 198 </span>Maintains access information, for servers, in an
 199 access-info-cache ( hashtable ). If an entry was not found in the cache
 200 creates one by loading the declaration file ( web-scripts-access.xml )
 201 and extracting information from it ( declaration file ); requested <span
 202  style="font-style: italic;">type</span> and subject princple's <span
 203  style="font-style: italic;">prefix</span> are compared to the allowed
 204 type and prefix in order to determine access. An entry is created if
 205 and only if the declaration file is considered valid ( validation based
 206 on the syntax described above ); an invalid document will result in
 207 access denial. Denies script access in the event of an
 208 xml-wellformedness error, or validation error, or if the declaration
 209 file does not grant access. Reports errors ( validation,
 210 wellformedness, file not found, etc. ) to the&nbsp; console via
 211 nsIConsoleService.<br>
 212 <br>
 213 Note: Script access is checked via declaration file only if the script
 214 security manager denies access.<span style="font-style: italic;"><span
 215  style="font-style: italic;"></span><br>
 216 </span>
 217 <ul>
 218 </ul>
 219 <h2>Summary</h2>
 220 <h3>Advantages</h3>
 221 The proposed declaration file places the server operator, not the
 222 client  in control of access to his server by untrusted scripts.
 223 &nbsp;The access  hole is no bigger than the service in question.
 224 &nbsp;The access is disabled  by default, and there is nothing the
 225 user needs to do to open access, and  nothing that can go wrong to
 226 make a hole in his firewall. &nbsp;It seems fairly easy to drop an
 227 access file into the root directory of the web server to allow access.<br>
 228 <h3>Delegation with Mixed Ownership</h3>
 229 Independent owners of subdirectories cannot grant web script access to
 230 these subdirectories without getting the owner of the root directory to
 231 post a delegating access file. &nbsp;Normally a server will be either
 232 inside or outside of a firewall, so this is not a problem. &nbsp;Where
 233 a server spans multiple owners, the alternative would be to scan all
 234 directories in the path looking for a web scripts access file, which
 235 seems undesirable. &nbsp;On the other hand, perhaps it is not so bad,
 236 since it permits independent management in domains where the top level
 237 owner may not care about providing access to web services.<br>
 238 <h3>Adjustments</h3>
 239 As this new model is applied to SOAP, and potentially document.load or
 240 xml-request, it may be desirable to eliminate the same source security
 241 bypass, because  it is not clear that this is always secure.
 242 &nbsp;Other security adjustments  may be desired as well.<br>
 243 <h2>Feedback?</h2>
 244 Please send me some feedback on this proposal.<br>
 245 </body>
 246 </html>