Security: SOAP server security from untrusted scripts, a proposal

[Ray Whitmer <ra...@xmission.com>]

This is a long message.  At the end I propose a standard SOAP header which
would eventually be supported by SOAP servers.  I need some opinions on
this so that I can advance the SOAP support in the Mozilla project to
be part of the default build.

First the problem:

Browser scripts can endanger services that are supposed to be protected
behind a firewall, because an unsuspecting user loads a page which now
has access to services behind a firewall and can send data back home.

The common solution is allow the user to designate domains which are
trusted and should be permitted to generally make such calls.  If the
script is already trusted enough, it may be permitted to ask the user to
grant it the necessary privileges to make such a call.  But this approach
seems deeply flawed:

1.  These security schemes rely on a configured browser that knows the
difference between trusted and untrusted sites.  Security needs to work
well in the absence of an intelligent user to make such configurations,
much like a Java sandbox does.

2.  Pages which should be permitted to make calls to other sites outside
of a firewall should not be able to make calls to other sites inside the
firewall, but mechanisms do not seem to distinguish at present.

3.  Placing the responsibility on the user of the browser is wrong,
because the client likely does not even know that he might be
endangering important services, which do not directly belong to him.
He is likely not to even really understand the purpose of the firewall,
know which domains are behind the firewall, or what type of calls might
place these things at risk.

4.  Even for the providers of services not behind a firewall, this makes
the services less available to browser users, because browser suppliers
are forced to place very draconian checks with dire warnings on the
SOAP mechanisms, because the user who disables them for a particular
domain with pages he needs risks compromising services behind the
firewall, even though al the suppliers and services involved may be
quite legitimate.

I have coded basic SOAP support for Mozilla, available from Javascript
inside web pages, which will be available in an upcoming Netscape release,
but I find myself in the position of having to make its use very
inconvenient to use, yet at the same time still quite insecure once
someone does give consent to make SOAP calls from a particular web page.

Now the proposal:

I propose that some of the responsibility be delegated to servers by
introduction of a new header: "foo:untrustedSource", which contains
the URI of the page making the request (also the company name in the
case of a script with a verifiable signature).

The reason I am bringing this up in this forum is that I feel I need
some kind of unofficial agreement from server folks before proceeding.
My time frame for releasing the client is pretty short, since I'd
like to see it in Mozilla 1.0 (no guarantees).  The time frame for
actually mulling over details and going from such an abstract
discussion to a more concrete plan for the server I expect to take
much longer, but that does not seem to be a problem since the
ability to ignore or object to mandatory headers seems to already
be present in Apache SOAP.  I believe I could ultimately help contribute
whatever parts might be needed for the Axis package or others was
to properly support this, which we expect to become common after the
release of Mozilla, Netscape, etc.

Here is how it works:

For legacy purposes, we keep in place in Mozilla the existing ability to
express complete faith in a domain and permit scripts within that domain
to make all the SOAP calls they want to.  But as always, we discourage its
use especially for general internet domains.

When a script wants to make calls but does not fall under this clumsy/
insecure exemption, then the implementation adds a header to the message
called "untrustedSource", with mustUnderstand="true", to make the security
opt-out instead of opt-in.  This header also contains the URI (and company
name if it is verifiably signed) of the source of the script.

How this affects Servers:

As long as the server checks mustUnderstand, existing services reject the
call, preserving their own security.  If a service wants to accept all
calls regardless of source (i.e. it is already available outside of the
firewall), it can be modified to ignore the header.  If a server wants to
discriminate between untrusted sources, it has the information in the
packet to do so.  This permits the server to say that no pages loaded
from untrusted domains except domains it trusts may call it.  This is
obviously usefull for protecting services within a firewall, and I could
also imagine it might be useful for dealing with potential DOS attacks
set up by getting unsuspecting hordes of users to load a particular
page.

Please note that this does not divulge in any way the identity of the user,
but only the URI of the page that invoked the service which is likely to
be in another domain (which is the whole point, because if the user only
created his own pages, they would all be trusted enough to not need this).
It is no security against a vicious user who compromizes services within
his own firewall, but only against user ignorance causing them to
compromise security or not be able to legitimately use web pages which
access SOAP services (even if they have no firewall).

What I get out of it is that by widely documenting this header and
eventually enabling services to allow it and filter messages based
upon it, I make it possible for the masses to use pages which access
these services where appropriate with little risk or inconvenience.

FWIW, I participate in the W3C XML Protocols WG, but I don't think it is
the type of issue they are dealing with there at present.

Thanks,

Ray Whitmer
ray@xmission.com
rayw@netscape.com

Re: Security: SOAP server security from untrusted scripts, a proposal

[Jan Alexander <al...@systinet.com>]

See my comments inlined.

>
> > I'm afraid the proposed solution to this issue will solve nearly nothing
> > because what does prevent the code inside the page to produce the SOAP
> > message itself and then send it using HTTP without invoking the SOAP
stack
> > implementation inside the browser, thus preventing it to insert the SOAP
> > Header with the origin of the page. The server will then have no input
how
> > to decide whether it should accept the request or not.
>
> The security model prevents this from happening, except that the way
things
> are controlled today, the client will be asked to lower that security
model
> in situation where on the surface there is nothing harmful going on.  But
> this would guarantee that when the client lowered the security protection,
> that at least the header would always be added.  Certainly the client can
> always force a message.  The client was already trusted, or the problem
could
> not arise.

OK, if and only if you can ensure, that the only possible way how to make
SOAP requests without explicit user intervention is via controlled SOAP
Client API, where this SOAP Header is inserted and this cannot be turned off
by the script itself and assuming that the client is trusted on the server
side (being behind the firewall or being authenticated by other mechanism
not important to this discussion) this proposed solution would work.

But should the client side fail in some of the assumptions mentioned in
previous paragraph, the presence/absence of this header will say nothing
relevant to the SOAP service being called.

>
> > I think that the only possible solution is to decide on the server from
> > which clients the calls are to be accepted and from which not. The
identity
> > of the client should be determined using some reasonable authentication
> > mechanism (like Kerberos, etc.). Because the script inside the page has
no
> > access to the client credentials, it must use the browser implementation
of
> > the communication protocol, whatever it is (e.g. SOAP stack), otherwise
the
> > call will not be authenticated and thus not trusted by the server.
>
> The identity of the client is not in question here.  I believe that in the
> future, we can allow client authentication through HTTPS, but the script
> cannot be blindly given access to a client's credentials, whereas the
client
> can somewhat-more-blindly permit SOAP calls if he has the guarantee that
> the mustUnderstand header is always being inserted.
>
> It would be a big mistake to have the server trust the client just because
> the script executed using his credentials.

I agree.

>
> The biggest benefactor of this model will be services which do not care
> whether they are called from untrusted scripts, so that they can release
the
> browser from the otherwise-draconian-yet-risky security model without
> endangering the user and the company whose firewall he is behind.  So we
can
> support a safer (verified by header) mode and an unsafe mode for allowing
> SOAP calls from scripts.

Yes, you are correct. The web needs something like this to allow making
inter-domain calls without client user intervention from a script running
inside a browser.

> >
> > Sincerely,
> >
> > Jan Alexander
> > alex@systinet.com
>
> Thanks for your thoughtful response,
>
> Ray Whitmer
> rayw@netscape.com
> ray@xmission.com
>

Thank you for throughout explanation of what exactly you are trying to solve
with this proposal.

Jan Alexander
alex@systinet.com

Re: Security: SOAP server security from untrusted scripts, a proposal

[Ray Whitmer <ra...@xmission.com>]

The security model prevents it from doing so.  Setting a flag to add the
header permits the client to make a call under an alternative security model,
which he would otherwise be unable to do.

Remember in this case, the client is not the hostile party we are trying to
authenticate.  The client's credentials have no bearing on the problem
whatsoever.  The client is already himself behind the firewall, so all he
would have to do is run any program or script and make whatever calls he
wants to soap services.  Certainly there need to be security mechanisms to
protect services against hostile clients (in some cases) but that is not at
all what makes the browser unique in this case.

The browser is unique because it is a friendly client, and trusted browser
application, who already has access to a service by virtue of being behind
a firewall.  But the problem is that he is loading untrusted applications in
the form of Javascript applications that may act against his best interests
and the best interests of services behind the firewall which use the firewall
as their primary means of security that no inappropriate persons will access
the information.

It would be counterproductive to give the script access to ther client's
credentials, because it leaves us with exactly the same problem, that if
an untrusted script such as is executed on many web pages can gain access
to a client's resources of trust, it can act against the clients best
interests and compromise his information or the information he has been
trusted to not abuse.

Even the answer that browsers have today -- force the client to make a
judgement call on each script -- is better than exposing the client's
credentials, but it is still a big problem because assigning trust for a
domain to make cross-domain SOAP calls may be justified for some domains
and not for others.  It is not a question that even I can answer reliably
because I probabl want domains to be make cross-domain calls, but just not
ones which exploit services behind my firewall.

This is why the better answer seems to be to show the service the credentials
of the source of the script, in one of two forms:  1) The URI of the page
from which the script was retrieved, 2) If it was a signed script, the name
of the company which signed the script, as verified by the client's
certificates of authentication.  Neither of these need to be securely
transmitted to be effective, because the client is trusted.  If the client
is worried about interception en-route, a hostile party who had the ability
to do that could just as easily send his own message, and https can be used
to reduce the likelyhood of that occurring.

The message of the header is:  "I am a trusted client [this is implicit
with the assumption that if there are issues of client trust they will be
handled other ways] using an untrusted script to send messages.  If you
have reason to believe that the source of the script should not be directing
messages to you, then please reject the message.  I am setting the message
mustUnderstand so that if you are not able to explicitly make this judgement
call, the default is to reject the message."

We cannot realistically rely on certificates for the majority of cases because
most web developers have exhibited an aversion to signed scripts, but we
do not prevent people from using signed scripts -- it is up to the writer of
the service which chooses to accept messages with this header whether he wants
to allow URIs or only signed identities.  We expect the most common acceptance
of this header will be by SOAP services which live outside of the firewall and,
hence, choose to ignore it because anyone outside the firewall, trusted or
untrusted can call them anyway.  By ignoring the header, they permit browsers
to effectively release scripts which want to use the service from the
draconian security models that browsers usually have to prevent usurping of
services (bridging) behind a firewall, but just for that particular service,
not harming the security of other services which may still need protection
because they are behind a firewall, even if they happen to be called by
scripts loaded from the same domain.

For example, given today's "security", someone would write the latest and
greatest unified SEARCH page which makes soap calls to lots of different
SOAP services in different domains such as google, altavista, etc, assuming
they all made available their services as SOAP services.  But once they had
"tricked" the user into permitting cross-domain SOAP calls for the purpose of
this enhanced searching capability, they could use the same privilege to look
for and call services behind the client's firewall and silently abuse the
service and /or send information to the home server, or deposit it at some
anonymous location.

With the new header, the user can permit SOAP calls in his browser without
opening up such huge holes as today's browsers foster, because he can be
assured that every SOAP service called will have this extra header identifying
that the call was from a browser that happened to be loaded from a particular
location and / or signed by a particular company.  Then the service must
explicitly choose to accept such calls from untrusted sources.

On Mon, 11 Feb 2002, Jan Alexander wrote:

> I'm afraid the proposed solution to this issue will solve nearly nothing
> because what does prevent the code inside the page to produce the SOAP
> message itself and then send it using HTTP without invoking the SOAP stack
> implementation inside the browser, thus preventing it to insert the SOAP
> Header with the origin of the page. The server will then have no input how
> to decide whether it should accept the request or not.

The security model prevents this from happening, except that the way things
are controlled today, the client will be asked to lower that security model
in situation where on the surface there is nothing harmful going on.  But
this would guarantee that when the client lowered the security protection,
that at least the header would always be added.  Certainly the client can
always force a message.  The client was already trusted, or the problem could
not arise.

> I think that the only possible solution is to decide on the server from
> which clients the calls are to be accepted and from which not. The identity
> of the client should be determined using some reasonable authentication
> mechanism (like Kerberos, etc.). Because the script inside the page has no
> access to the client credentials, it must use the browser implementation of
> the communication protocol, whatever it is (e.g. SOAP stack), otherwise the
> call will not be authenticated and thus not trusted by the server.

The identity of the client is not in question here.  I believe that in the
future, we can allow client authentication through HTTPS, but the script
cannot be blindly given access to a client's credentials, whereas the client
can somewhat-more-blindly permit SOAP calls if he has the guarantee that
the mustUnderstand header is always being inserted.

It would be a big mistake to have the server trust the client just because
the script executed using his credentials.

> Relying on the client, that he or she will insert something into the message
> and trust this information without even knowing from where it came, because
> there is nothing, where the server could ensure the authenticity of the
> information inside the header will never work.

We are not relying on the client user to insert something.  We are relying
on the client browser application.  The client user delegates to the browser
permission to exchange SOAP messages if and only if this header is always
added.  As long as the client only grants permission based upon the guarantee
that the header will be inserted, then he can rest assured that it will
always be added for those cases.  The untrusted script does not have the
ability to send it without the header (unless he can convince the user to
to not rely on this verification header and just grant blanket permission
to make cross-domain SOAP calls, but that is exactly the scenario we are trying
to avoid by introducing the header).

The biggest benefactor of this model will be services which do not care
whether they are called from untrusted scripts, so that they can release the
browser from the otherwise-draconian-yet-risky security model without
endangering the user and the company whose firewall he is behind.  So we can
support a safer (verified by header) mode and an unsafe mode for allowing
SOAP calls from scripts.
>
> Sincerely,
>
> Jan Alexander
> alex@systinet.com

Thanks for your thoughtful response,

Ray Whitmer
rayw@netscape.com
ray@xmission.com

Re: Security: SOAP server security from untrusted scripts, a proposal

[Jan Alexander <al...@systinet.com>]

I'm afraid the proposed solution to this issue will solve nearly nothing
because what does prevent the code inside the page to produce the SOAP
message itself and then send it using HTTP without invoking the SOAP stack
implementation inside the browser, thus preventing it to insert the SOAP
Header with the origin of the page. The server will then have no input how
to decide whether it should accept the request or not.

I think that the only possible solution is to decide on the server from
which clients the calls are to be accepted and from which not. The identity
of the client should be determined using some reasonable authentication
mechanism (like Kerberos, etc.). Because the script inside the page has no
access to the client credentials, it must use the browser implementation of
the communication protocol, whatever it is (e.g. SOAP stack), otherwise the
call will not be authenticated and thus not trusted by the server.

Relying on the client, that he or she will insert something into the message
and trust this information without even knowing from where it came, because
there is nothing, where the server could ensure the authenticity of the
information inside the header will never work.

Sincerely,

Jan Alexander
alex@systinet.com


----- Original Message -----
From: "Ray Whitmer" <ra...@xmission.com>
To: <ax...@xml.apache.org>
Sent: Friday, 08 February, 2002 16:51
Subject: Security: SOAP server security from untrusted scripts, a proposal


> This is a long message.  At the end I propose a standard SOAP header which
> would eventually be supported by SOAP servers.  I need some opinions on
> this so that I can advance the SOAP support in the Mozilla project to
> be part of the default build.
>
> First the problem:
>
> Browser scripts can endanger services that are supposed to be protected
> behind a firewall, because an unsuspecting user loads a page which now
> has access to services behind a firewall and can send data back home.
>
> The common solution is allow the user to designate domains which are
> trusted and should be permitted to generally make such calls.  If the
> script is already trusted enough, it may be permitted to ask the user to
> grant it the necessary privileges to make such a call.  But this approach
> seems deeply flawed:
>
> 1.  These security schemes rely on a configured browser that knows the
> difference between trusted and untrusted sites.  Security needs to work
> well in the absence of an intelligent user to make such configurations,
> much like a Java sandbox does.
>
> 2.  Pages which should be permitted to make calls to other sites outside
> of a firewall should not be able to make calls to other sites inside the
> firewall, but mechanisms do not seem to distinguish at present.
>
> 3.  Placing the responsibility on the user of the browser is wrong,
> because the client likely does not even know that he might be
> endangering important services, which do not directly belong to him.
> He is likely not to even really understand the purpose of the firewall,
> know which domains are behind the firewall, or what type of calls might
> place these things at risk.
>
> 4.  Even for the providers of services not behind a firewall, this makes
> the services less available to browser users, because browser suppliers
> are forced to place very draconian checks with dire warnings on the
> SOAP mechanisms, because the user who disables them for a particular
> domain with pages he needs risks compromising services behind the
> firewall, even though al the suppliers and services involved may be
> quite legitimate.
>
> I have coded basic SOAP support for Mozilla, available from Javascript
> inside web pages, which will be available in an upcoming Netscape release,
> but I find myself in the position of having to make its use very
> inconvenient to use, yet at the same time still quite insecure once
> someone does give consent to make SOAP calls from a particular web page.
>
> Now the proposal:
>
> I propose that some of the responsibility be delegated to servers by
> introduction of a new header: "foo:untrustedSource", which contains
> the URI of the page making the request (also the company name in the
> case of a script with a verifiable signature).
>
> The reason I am bringing this up in this forum is that I feel I need
> some kind of unofficial agreement from server folks before proceeding.
> My time frame for releasing the client is pretty short, since I'd
> like to see it in Mozilla 1.0 (no guarantees).  The time frame for
> actually mulling over details and going from such an abstract
> discussion to a more concrete plan for the server I expect to take
> much longer, but that does not seem to be a problem since the
> ability to ignore or object to mandatory headers seems to already
> be present in Apache SOAP.  I believe I could ultimately help contribute
> whatever parts might be needed for the Axis package or others was
> to properly support this, which we expect to become common after the
> release of Mozilla, Netscape, etc.
>
> Here is how it works:
>
> For legacy purposes, we keep in place in Mozilla the existing ability to
> express complete faith in a domain and permit scripts within that domain
> to make all the SOAP calls they want to.  But as always, we discourage its
> use especially for general internet domains.
>
> When a script wants to make calls but does not fall under this clumsy/
> insecure exemption, then the implementation adds a header to the message
> called "untrustedSource", with mustUnderstand="true", to make the security
> opt-out instead of opt-in.  This header also contains the URI (and company
> name if it is verifiably signed) of the source of the script.
>
> How this affects Servers:
>
> As long as the server checks mustUnderstand, existing services reject the
> call, preserving their own security.  If a service wants to accept all
> calls regardless of source (i.e. it is already available outside of the
> firewall), it can be modified to ignore the header.  If a server wants to
> discriminate between untrusted sources, it has the information in the
> packet to do so.  This permits the server to say that no pages loaded
> from untrusted domains except domains it trusts may call it.  This is
> obviously usefull for protecting services within a firewall, and I could
> also imagine it might be useful for dealing with potential DOS attacks
> set up by getting unsuspecting hordes of users to load a particular
> page.
>
> Please note that this does not divulge in any way the identity of the
user,
> but only the URI of the page that invoked the service which is likely to
> be in another domain (which is the whole point, because if the user only
> created his own pages, they would all be trusted enough to not need this).
> It is no security against a vicious user who compromizes services within
> his own firewall, but only against user ignorance causing them to
> compromise security or not be able to legitimately use web pages which
> access SOAP services (even if they have no firewall).
>
> What I get out of it is that by widely documenting this header and
> eventually enabling services to allow it and filter messages based
> upon it, I make it possible for the masses to use pages which access
> these services where appropriate with little risk or inconvenience.
>
> FWIW, I participate in the W3C XML Protocols WG, but I don't think it is
> the type of issue they are dealing with there at present.
>
> Thanks,
>
> Ray Whitmer
> ray@xmission.com
> rayw@netscape.com
>