471,325 Members | 1,755 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

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
Aug 4 '08 #1
7 1196
bob wrote:
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
Aug 4 '08 #2

"bob" <st**************@cutthis.adriley.co.nzwrote in message
news:mq********************************@4ax.com...
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.

Aug 4 '08 #3
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
Aug 4 '08 #4
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
Aug 4 '08 #5
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

Aug 4 '08 #6
bob

Hi Marc,
Thanks again.
regards
Bob
On Mon, 4 Aug 2008 01:52:45 -0700 (PDT), Marc Gravell
<ma**********@gmail.comwrote:
>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
Aug 4 '08 #7
bob wrote:
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
Aug 4 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Davie | last post: by
4 posts views Thread by Rajesh.V | last post: by
5 posts views Thread by AliR | last post: by
reply views Thread by Daniel Knöpfel | last post: by
5 posts views Thread by VictorG | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.