Webservice Security

[bob]

Hi,
Please forgive the Off-topic
We have a hand help app that consumes a web service.
Currently this is internal to the organisation.
We now want to expose this externally so the Handhelds can consume it
anywhere.
The IT staff are looking to us for answers on the security risk of
this.
My uninformed opinion is that the worst case is someone could discern
the protocol and pretend to be a Handheld and consume the webservice.
They wouldn't be able to hack in and destroy the corporate database
etc.
If anyone has some real world experience and lnowledge on this and
could comment it would be appreciated.
thanks
Bob

 

[Arne Vajhøj]

We have a hand help app that consumes a web service.
Currently this is internal to the organisation.
We now want to expose this externally so the Handhelds can consume it
anywhere.
The IT staff are looking to us for answers on the security risk of
this.
My uninformed opinion is that the worst case is someone could discern
the protocol and pretend to be a Handheld and consume the webservice.
They wouldn't be able to hack in and destroy the corporate database
etc.
If anyone has some real world experience and lnowledge on this and
could comment it would be appreciated.

Sometimes it is good to be paranoid.

I will suggest:

- require authentications (either login or client
certificate)
- HTTPS only
- Network with DMZ like:
---firewal---server with no data---firwall---server with data
- strict validation of everything in the web service itself
- appropriate logging and monitoring

Arne

 

[Mr. Arnold]

Hi,
Please forgive the Off-topic
We have a hand help app that consumes a web service.
Currently this is internal to the organisation.
We now want to expose this externally so the Handhelds can consume it
anywhere.
The IT staff are looking to us for answers on the security risk of
this.
My uninformed opinion is that the worst case is someone could discern
the protocol and pretend to be a Handheld and consume the webservice.
They wouldn't be able to hack in and destroy the corporate database
etc.
If anyone has some real world experience and lnowledge on this and
could comment it would be appreciated.
thanks
Bob

The Web service should be using HTTPS with authentication and certificate.

I don't know about the hand held and its ability to use SOAP authentication
of User-ID and PSW it must present to the Web service that uses SOAP
authentication.

 

[Marc Gravell]

... is that the worst case is someone could discern

the protocol ...

Your biggest problem is probably malicious peope *with* access;
internal attacks are (in some ways) more common than external apps.

I always start web-service design under the premise that the protocol
(/api) is open, since it is trivial for people with access to a
genuine client to find out (even with metadata/discovery disabled).
Either by reverse-engineering your client (reflector), or by
installing the debug versions of the http libraries (available in the
platform SDK) that allow you to inspect the internals of ssl sessions
happening locally (at the client).

So since you must assume that the API is known (otherwise it is
[in]security through obscurity), the golden rule is never, ever, trust
the client; it is pretty easy to stick *any* home-built client on the
end of a web-service to which the user has geninue, legitimate access
- but which bypasses your normal process; submit an order for minus-
two-hundred PCs? No problem [big refund coming to someone]... Perform
a bulk update on 14,000 records? Sure...

Any security checks, business rule checks, and sanity checks *must* be
done at the server. You should also do them at the client, but this is
usually just a courtesy, and it makes the client more responsive if
you can immediately show an error message, rather than waiting on
latency for the server to say the same thing.

There are other scenarios relating to external attacks, but these are
much harder; Arne's points go some way to limiting your exposure here.
The only thing I can add is a good password policy (regular changes,
no repeats, strength-tested) so that people can't do something framing
"Jo whose password everyone knows is his kid's name". I know several
IT departments who actively and deliberately run some easily obtained
(and rather dubious) password cracking software on their corporate
networks: the aim being to ensure that your password can't be easily
cracked (by dictionary attacks etc). But good to see that even the
most nefarious tools can have legitimate uses!

Marc
Marc

 

[Marc Gravell]

Oh; on the subject of strong passwords: physical tokens (such as RSA's
SecurID) are a very good idea; this means that not even *you* know
your password (or not all of it, at least). So even if you use a
device that has a key-logger installed, they can't use your password
later. However, this doesn't always play nicely with web-service
logins - so our client apps use a regular html login page (with
SecurID); when the user has successfully logged in (over SSL), our
client app detects a generated token on the page and uses that token
(time-limited, crypto-hashed) to talk to the web-service.

And if somebody drops their SecurID; fine... any passer by isn't going
to know the other half of the credentials (but cancel the token
anyway!). This leaves malicious misuse, and things like combined theft
(for the SecurID) and key logging / threat (to get the username/
password). And, well, then things get hard to guard against... I'll
let you decide (based on your industry) what to do there... thankfully
it isn't something I have to worry about in my line, but if you aer
working in high-finance / security / military, well... I'm sure they'd
have their own guidelines.

Marc

 

[bob]

Hi All,
Thank you for your replies,
It seems there is a case to answer.
Pardon me if my questions seem naive but I spend my time doing back
room design.

The Web Service only exposes one function which takes in a specialized
XML document and spits back an output string once the back room app
has parsed the doc and made its decisions.

There is no gain or loss if the Web service function is fooled by a
black hat. Its a bit like a remote stock take function except there is
not even any Jelly Beans to make fraud worthwhile.

It doesn't even really matter if the black hat trashes this apps
database, mildly inconvenient but thats all.

The only real concern I have got is:
Can a single function web service such as this act as a portal for
further network malevolence?

The machine housing this apps database would be on the corporate
network and further distruction would be serious.

From your replies so far I am thinking;

1) https
2) Maybe the backend app and database live in the DMZ?

Thanks again,
Bob

 

[Marc Gravell]

2) Maybe the backend app and database live in the DMZ?

If the db is throwaway and doesn't have anything priveleged, then
maybe... I try to protect mine a bit more, though.

Re acting as a portal : as long as you don't do anything daft like
open yourself to SQL injection attacks, or execute random shell
commands for the client, or run as sysadmin (or an even /remotely/
priveleged account), then you should be pretty safe.

Marc

 

[bob]

Hi Marc,
Thanks again.
regards
Bob

If the db is throwaway and doesn't have anything priveleged, then
maybe... I try to protect mine a bit more, though.

Re acting as a portal : as long as you don't do anything daft like
open yourself to SQL injection attacks, or execute random shell
commands for the client, or run as sysadmin (or an even /remotely/
priveleged account), then you should be pretty safe.

Marc

 

[Arne Vajhøj]

The Web Service only exposes one function which takes in a specialized
XML document and spits back an output string once the back room app
has parsed the doc and made its decisions.

There is no gain or loss if the Web service function is fooled by a
black hat. Its a bit like a remote stock take function except there is
not even any Jelly Beans to make fraud worthwhile.

It doesn't even really matter if the black hat trashes this apps
database, mildly inconvenient but thats all.

The only real concern I have got is:
Can a single function web service such as this act as a portal for
further network malevolence?

Yes, which is why it is common practice to put a box in a DMZ
with a firewall on both sides.

The machine housing this apps database would be on the corporate
network and further distruction would be serious.

From your replies so far I am thinking;

1) https
2) Maybe the backend app and database live in the DMZ?

I am a bit skeptical about having the database out in the DMZ.

But if it is readonly data and they are stored on a CD disk, then
maybe ...



Arne