зеркало из https://github.com/mozilla/pjs.git
New security model doc. ** NOT PART OF THE BUID
This commit is contained in:
harishd%netscape.com
Родитель
83708b199e
Коммит
8ab7563456
|
|
@ -0,0 +1,246 @@
|
|||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<title>Securing Untrusted Scripts Behind Firewalls</title>
|
||||
<meta http-equiv="content-type"
|
||||
content="text/html; charset=ISO-8859-1">
|
||||
</head>
|
||||
<body>
|
||||
<h1 style="text-align: center;">Securing Resources from Untrusted
|
||||
Scripts Behind Firewalls<big><span style="font-weight: bold;"></span></big></h1>
|
||||
<h1 style="text-align: center;"><small><small><big><span
|
||||
style="font-weight: normal;">by</span></big> </small></small><big><big><span
|
||||
style="font-weight: bold;"></span></big></big></h1>
|
||||
<h1 style="text-align: center;"><small style="font-weight: normal;"><a
|
||||
href="mailto:rayw@netscape.com">Ray Whitmer</a> and <a
|
||||
href="maiilto:harishd@netscape.com">Harish Dhurvasula</a></small><br>
|
||||
</h1>
|
||||
<h2>Introduction<br>
|
||||
</h2>
|
||||
This page describes an alternative mechanism which can be used to
|
||||
protect all internal resources against requests from sandboxed
|
||||
scripts. This should especially be implemented for SOAP calls
|
||||
by untrusted scripts. When an attempt is made to access a
|
||||
resource at a previously-unknown URI, the sandbox reads a file at that
|
||||
domain with declarations to determine whether access is permitted to
|
||||
the script. If the file is not there, access is denied.<br>
|
||||
<h2>The Problem<br>
|
||||
</h2>
|
||||
External untrusted scripts loaded behind a firewall are executed in a
|
||||
sandbox. These scripts may legitimately require access to external
|
||||
resources, but permitting them to access internal resources permits the
|
||||
compromise of these resources that would normally not be available to
|
||||
applications outside of the firewall. The sandbox must
|
||||
distinguish and protect internal resources.<br>
|
||||
<h2>Client-controlled Solutions</h2>
|
||||
Several client-controlled solutions have been designed to prevent
|
||||
sandboxed applications loaded behind a firewall from compromising
|
||||
other resources protected behind the firewall.
|
||||
<h3> Same Source Restriction.</h3>
|
||||
By restricting sandboxed scripts to access only resources in the domain
|
||||
from which they were loaded, any script loaded from one domain into
|
||||
another is prevented from accessing resources in the domain
|
||||
into which it has been loaded. This policy has generally been
|
||||
successful in sandboxing Javascript and Java applets across the web.<br>
|
||||
<br>
|
||||
If the sandbox is unable to distinguish the common URI substring of the
|
||||
domain to be trusted from similar URIs of untrusted domains, then it
|
||||
could allow a script loaded from an indistinguishable domain to
|
||||
exploit firewall-protected resources.<br>
|
||||
<br>
|
||||
Also, this technique prevents the script from accessing many legitimate
|
||||
external resources not provided in the same domain as the script.
|
||||
This prevents a script from accessing web services and data
|
||||
published from any domain besides its own.<br>
|
||||
<h3>White-listing</h3>
|
||||
By creating a white list of trusted URIs from which scripts are trusted
|
||||
to not compromise internal resources, it is possible to release domains
|
||||
from the stricter same-source sandbox. A white list is a good tool
|
||||
for including always-trusted domains, but on the web, it is often a
|
||||
script from a relatively-untrusted domain that must be granted access
|
||||
to other untrusted domains, without compromising internal domains.<br>
|
||||
<br>
|
||||
More-complex access lists could be created to try to establish, with
|
||||
finer granularity, which domains are to be accessible or permitted
|
||||
from which other domains, but this requires extensive management which
|
||||
at best is quite error-prone for the end user and easily opens holes
|
||||
in a firewall that do not directly hurt the user who reconfigured his
|
||||
browser to try to access some external service but hurts the owners of
|
||||
other services behind the firewall.<br>
|
||||
<h3>Signed Scripts</h3>
|
||||
A certain degree of additional trust may be lent to a script by having
|
||||
the author digitally sign it. But signed scripts have not really
|
||||
caught on as they require certificates do not change the basic
|
||||
problem that some completely-unknown party has written a script that
|
||||
might now have access to internal resources.<br>
|
||||
<h3>Asking the User</h3>
|
||||
Where the sandbox cannot otherwise determine whether the executing
|
||||
script should be permitted access to the resource, a dialog box may
|
||||
be raised to ask the user to grant special privileges. This is
|
||||
currently permitted for locally-saved scripts and signed scripts.
|
||||
This could be combined with the other options above such as
|
||||
whitelisting, signed scripts, etc. But the big problem with this
|
||||
is that the typical browser user really does not either understand or
|
||||
pay the consequences if he inadvertently opens a hole in his company's
|
||||
firewall. Quite complex settings may be required to permit the
|
||||
user to allow access to desired external services without risking
|
||||
other resources.<br>
|
||||
<h2>Controlling Resource Access on the Server</h2>
|
||||
Access by untrusted scripts really needs to be under the control of the
|
||||
stake holder, which is the resource and server owner -- not the user --
|
||||
to determine whether a resource should be insulated from web
|
||||
applications loaded from outside of the firewall.<br>
|
||||
<h3>Using a SOAP Header for Verification</h3>
|
||||
SOAP messages have a distinct processing model allowing a header to be
|
||||
added that the recipient is required to understand and accept, which
|
||||
identifies the untrusted source of a script making a request.
|
||||
SOAP services which have not been cleared for access by
|
||||
untrusted scripts will reject the requests. This is offered in
|
||||
the Mozilla implementation of SOAP today.<br>
|
||||
<br>
|
||||
Unfortunately, this does not prevent SOAP messages from being sent to
|
||||
non-SOAP addresses, which is a big enough problem that the verification
|
||||
cannot stand alone to guarantee that untrusted service requests are
|
||||
always properly rejected by services that should be firewall-protected.<br>
|
||||
<br>
|
||||
It may also be inconvenient to modify a SOAP service to ignore the
|
||||
specific verification header.<br>
|
||||
<h3>Using a Declarations File<br>
|
||||
</h3>
|
||||
A more robust solution is to rely on getting a file named "<code>web-scripts-access.xml</code>"
|
||||
in the root directory of the server that the sandboxed script requests
|
||||
to communicate with. It should be fairly easy for most
|
||||
providers of public resources to create.<br>
|
||||
<h2>Web Scripts Access Statements<br>
|
||||
</h2>
|
||||
The syntax of statements of the access file are as follows.
|
||||
<pre><!ELEMENT webScriptAccess (delegate?|allow*)><br><!ELEMENT delegate EMPTY><br><!ELEMENT allow EMPTY><br><!ATTLIST allow type|from CDATA #IMPLIED>.<br></pre>
|
||||
<h3>The Root Element<br>
|
||||
</h3>
|
||||
The first element of the file should be the following:<br>
|
||||
<code><br>
|
||||
<wsa:webScriptAccess
|
||||
xmlns:wsa="http://www.mozilla.org/2002/soap/security</code>"><br>
|
||||
<h3>Delegation</h3>
|
||||
If the <<code>delegate</code>/> element is present then "<code>web-scripts-access.xml</code>"
|
||||
is required in the subdirectory for URIs which are in a subdirectory.
|
||||
For example, if the script in question is "<code>http://www.example.com/foo/bar.xml</code>",
|
||||
then the declarations file <code>http://www.example.com/web-scripts-access.xml</code>
|
||||
which contains the "<code>delegate</code>" keyword delegates to <code>http://www.example.com/foo/web-scripts-access.xml</code>.
|
||||
If the URI is in a subdirectory, and the root directory's access
|
||||
file delegated but no access file exists in the subdirectory, then no
|
||||
access is granted. If the root's access file did not delegate,
|
||||
then that access file also handles all resources in subdirectories.<br>
|
||||
<br>
|
||||
Any syntax error in the document will result in the rest of the file to
|
||||
be ignored. Since the commands only allow access, the order of
|
||||
processing the "<code>allow</code>" commands that were successfully
|
||||
parsed is never significant.<br>
|
||||
<h3>Allowing Web Script Access</h3>
|
||||
To permit scripts to access the resources of this server, use the
|
||||
following command:<br>
|
||||
<br>
|
||||
<code><wsa:allow</code> <code></code>type="<request-type>" <code>from</code>
|
||||
="<uri-prefix>"/><br>
|
||||
<br>
|
||||
The type of request, if specified, will be checked against the type of
|
||||
request being requested by the script, such as <code></code>"<code>soap</code>",
|
||||
"<code>soapv</code>", or "<code>load</code>". Types must not
|
||||
contain spaces. Specify "<code>any</code>" as the type to permit
|
||||
any requested type of access to resources.<br>
|
||||
<br>
|
||||
The principle URI of the script will be checked for the specified URI
|
||||
prefix. If "<code>from</code>" is not specified, then all scripts
|
||||
will be allowed. <span style="font-weight: bold;">Note:</span> One can
|
||||
also use wild charater(s) in "from" value.<br>
|
||||
<br>
|
||||
For example:<br>
|
||||
<code><br>
|
||||
<wsa:allow type="soapv" from="http://www.mozilla.org"/></code><br>
|
||||
<br>
|
||||
This command allows SOAP requests with verification headers from
|
||||
scripts loaded from the domain www.mozilla.org.<br>
|
||||
<br>
|
||||
<code> <wsa:allow type="soapv" from="http://*.mozilla.org"/><br>
|
||||
<br>
|
||||
</code> This command allows SOAP requests with verification headers from
|
||||
scripts loaded from the domain with host name containing mozilla.org.
|
||||
That is, http://www.mozilla.org/, http://lxr.mozilla.org,
|
||||
http://komodo.mozilla.org, etc. will be granted access.<br>
|
||||
<h2>Implementation</h2>
|
||||
<span style="font-weight: bold;">nsIWebScriptsAccessService</span><br>
|
||||
This interface provides a way to check whether the running script has
|
||||
access to the server that the script wishes to communicate.<br>
|
||||
<span style="text-decoration: underline;"></span><span
|
||||
style="font-style: italic;"></span><span style="font-style: italic;"></span>
|
||||
<ul>
|
||||
<li>boolean canAccess(in nsIURI aTransportURI, in AString aType);</li>
|
||||
<ul>
|
||||
<li>aTransportURI - The service URI </li>
|
||||
<li>aType - Type requested by the script ( ex. soapv, soap,
|
||||
load, etc. )</li>
|
||||
<li>return PR_TRUE if access granted else PR_FALSE</li>
|
||||
</ul>
|
||||
<li> void invalidateCache(in string aTransportURI);</li>
|
||||
<ul>
|
||||
<li>Invalidate cached entry for the given transport uri.</li>
|
||||
<li>Empty the cache by passing in a empty string<br>
|
||||
</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<ul>
|
||||
<ul>
|
||||
</ul>
|
||||
</ul>
|
||||
<span style="text-decoration: underline;">nsWebScriptsAccess</span>
|
||||
( <span style="font-style: italic;">Implements
|
||||
nsIWebScriptsAccessService)<br>
|
||||
</span>Maintains access information, for servers, in an
|
||||
access-info-cache ( hashtable ). If an entry was not found in the cache
|
||||
creates one by loading the declaration file ( web-scripts-access.xml )
|
||||
and extracting information from it ( declaration file ); requested <span
|
||||
style="font-style: italic;">type</span> and subject princple's <span
|
||||
style="font-style: italic;">prefix</span> are compared to the allowed
|
||||
type and prefix in order to determine access. An entry is created if
|
||||
and only if the declaration file is considered valid ( validation based
|
||||
on the syntax described above ); an invalid document will result in
|
||||
access denial. Denies script access in the event of an
|
||||
xml-wellformedness error, or validation error, or if the declaration
|
||||
file does not grant access. Reports errors ( validation,
|
||||
wellformedness, file not found, etc. ) to the console via
|
||||
nsIConsoleService.<br>
|
||||
<br>
|
||||
Note: Script access is checked via declaration file only if the script
|
||||
security manager denies access.<span style="font-style: italic;"><span
|
||||
style="font-style: italic;"></span><br>
|
||||
</span>
|
||||
<ul>
|
||||
</ul>
|
||||
<h2>Summary</h2>
|
||||
<h3>Advantages</h3>
|
||||
The proposed declaration file places the server operator, not the
|
||||
client in control of access to his server by untrusted scripts.
|
||||
The access hole is no bigger than the service in question.
|
||||
The access is disabled by default, and there is nothing the
|
||||
user needs to do to open access, and nothing that can go wrong to
|
||||
make a hole in his firewall. It seems fairly easy to drop an
|
||||
access file into the root directory of the web server to allow access.<br>
|
||||
<h3>Delegation with Mixed Ownership</h3>
|
||||
Independent owners of subdirectories cannot grant web script access to
|
||||
these subdirectories without getting the owner of the root directory to
|
||||
post a delegating access file. Normally a server will be either
|
||||
inside or outside of a firewall, so this is not a problem. Where
|
||||
a server spans multiple owners, the alternative would be to scan all
|
||||
directories in the path looking for a web scripts access file, which
|
||||
seems undesirable. On the other hand, perhaps it is not so bad,
|
||||
since it permits independent management in domains where the top level
|
||||
owner may not care about providing access to web services.<br>
|
||||
<h3>Adjustments</h3>
|
||||
As this new model is applied to SOAP, and potentially document.load or
|
||||
xml-request, it may be desirable to eliminate the same source security
|
||||
bypass, because it is not clear that this is always secure.
|
||||
Other security adjustments may be desired as well.<br>
|
||||
<h2>Feedback?</h2>
|
||||
Please send me some feedback on this proposal.<br>
|
||||
</body>
|
||||
</html>
|
||||
Загрузка…
Ссылка в новой задаче