views:

117

answers:

2

It seems that anyone can snoop on incoming/outgoing .NET web service SOAP messages just by dropping in a simple SoapExtension into the bin folder and then plumbing it in using:

<soapExtensionTypes>
  <add type="MyLoggingSoapExtension, SoapLoggingTools" priority="0" group="High" />
<soapExtensionTypes>

Is there a way to prevent SOAP extensions from loading or to be asked in my app (through an event or some such mechanism) whether it's ok to load ?

@Hurst: thanks for the answer. I know about message level encryption/WS-Security and was hoping not to have to go that road. We have classic ASP clients using the service and that opens a small world of pain. There are SSL certs on the site running the web service but I was kinda hoping that I could discourage the client from tinkering with soap extensions as they have developers who have some ability to 'play'.

+2  A: 

I am not sure what you mean by extensions and bin folders (I would guess you are using .NET), so I can't answer about them being loaded etc.

However, note that SOAP is designed to allow intermediaries to read the headers and even to modify them. (Do a search for "SOAP Active Intermediaries"). Judging by that, I expect there to be no reason for a technology to avoid snooping by preventing code from reading the SOAP.

The proper way to protect yourself is to use "message-level security". (This is in contrast to transport-level security, such as SSL, which does not protect from intermediaries). In other words, encrypt your own messages before sending.

One available standard used to implement message-level security mechanisms is the WS-Security protocol. This allows you to target the encryption to the payload and relevant headers regardless of transport. It is more complex, but that is how you would go about restricting access.

hurst
A: 

Totally agree with @Hurst - if you want to prevent others reading your messages you need to use message-level encryption. Otherwise even simple NetMon can crack over the wire traffic.

Of course if someone has access to the machine (given the access to /bin etc.), even cryptography may not be enough to prevent snoopers using debuggers e.g. to read in-memory representations of the message after decrypting.

With physical access to the machine - all bets are off.

stephbu