On 8/16/06, John Wilander <[EMAIL PROTECTED]> wrote: > Thanks for all the replies so far! I would just like to comment on > Holger Peine's and Mike Hines' viewpoints. > > [EMAIL PROTECTED] wrote: > > I don't see a conflict here: A web service (just as any > > network-accessible > > service, no matter whether programmed using sockets, Java RMI, SOAP or > > whatever) is _intended_ to provide some function to the outside world, > > so you have to open _some_ door into your system. The advice about > > minimizing the attack surface is about not opening any doors you don't > > really need (or worse, didn't even intend to open). > > As you say, any kind of system is _intended_ to provide some function. > But security bugs often hide in unintended, undocumented or unknown > functionality. By increasing the attack surface you also increase the > risk of adding unknown functions. > > Mike Hines commented on web services running everything through port 80 > (HTTP) as negating "... any value of firewalls and most likely intrusion > detection systems". Indeed, web services tunnel a lot of functionality > through port 80, effectively hiding it from many system monitoring > defense measures. The security will rely on validating SOAP envelopes > and prevention at the application/run-time system level. It seems to me > like a huge burden.
A huge burden or a huge benefit? You can validate everything in one spot, and maybe even solve problems in one spot. Imagine if everything went into the same system; thereby suggesting that all attacks would be similar (i.e. all attacks against the soap parsers of various apps, or something). If it all goes in one hole, you can fix it once with your IDS, or whatever acronym you have installed. You seem to be saying that any given app i want to write, and have publically accessible, I should write to accept connections on another port, or find another channel to operate on (maybe through a website app dll calls, or something). But then, if we do that, we have to re-write everything each time. Doesn't make alot of sense ... > Regards, John -- mic _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
