Secure Coding mailing list archives
Web Services vs. Minimizing Attack Surface
From: nash at solace.net (Nash)
Date: Tue, 15 Aug 2006 10:48:09 -0400
Thinking about "attackable surface area" is a good metaphor, but I think it's breaking down on you. Think about a classic forms-driven (MVC) web application. If it's at all complex, it'll contain a variety of form processing programs that are all interlinked with a complex state-sharing mechanism. Such an application might be hosted on just a single "port" or "service", but it has huge surface area. It's also devilishly difficult to verify the code. On the other hand, many web services look like lots and lots of "services", but each of them has extremely limited surface area on its own. WS programs are typically smaller than their forms-processing cousins-- even with all the automagic frameworks for MVC. Web services tend to be specified syntactically as opposed to semantically. In other words, the behavior of the RPC service is defined by how you've structured your requests and is often not based upon the content of an server-internal state sharing mechanism. This is a huge advantage for security because it means that the scope of a WS service is narrowly limited to its syntactic function. It shouldn't tend to bleed out into other functional areas. Finally, because web services are smaller and easier to write, they should be (much) easier to verify for correctness. Many WS frameworks also provide really nice abstractions of authentication and authorization, so that you can check those separately without even having to look at business logic in the process. So, point being that I think that claiming that WS/SOA architectures have greater "surface area" is ignoring the big picture. Our notion of surface area needs to become more sophisticated to account for the architectural differences between WS and classic-MVC apps. If web developers want to use web services, I can't see why shouldn't do so immediately. It shouldn't be THAT difficult for WS/SOA to make a net positive impact on security. Security folks shouldn't be scared of WS/SOA, we should be welcoming it. It's a great opportunity to reintegrate seurity in a way that we just never had with the Web 1.0 universe. -nash On Tue, Aug 15, 2006 at 10:03:07AM +0200, John Wilander wrote:
Hi! The security principle of minimizing your attack surface (Writing Secure Code, 2nd Ed.) is all about minimizing open sockets, rpc endpoints, named pipes etc. that facilitate network communication between applications. Web services and Service Oriented Architecture on the other hand are all about exposing functionality to offer interoperability. Have any of you had discussions on the seemingly obvious conflict between these things? I would be very happy to hear your conclusions and opinions! Regards, John ____________________________ John Wilander, PhD student Computer and Information Sc. Linkoping University, Sweden http://www.ida.liu.se/~johwi _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
-- Please do not mock other religons in your quest for the Spaghetti god. - anonymous
Current thread:
- Web Services vs. Minimizing Attack Surface John Wilander (Aug 15)
- Web Services vs. Minimizing Attack Surface Gunnar Peterson (Aug 15)
- Web Services vs. Minimizing Attack Surface Nash (Aug 15)
- <Possible follow-ups>
- Web Services vs. Minimizing Attack Surface Holger.Peine at iese.fraunhofer.de (Aug 15)
- Web Services vs. Minimizing Attack Surface Gadi Evron (Aug 15)
- Web Services vs. Minimizing Attack Surface John Wilander (Aug 16)
- Web Services vs. Minimizing Attack Surface mikeiscool (Aug 16)
- Web Services vs. Minimizing Attack Surface Gadi Evron (Aug 16)
- Web Services vs. Minimizing Attack Surface Gunnar Peterson (Aug 16)
- secure integer library Robert C. Seacord (Aug 17)
- secure integer library Pascal Meunier (Aug 17)
- secure integer library Robert C. Seacord (Aug 17)