I think that whether an application communicates using SOAP, CGI or a custom protocol doesn't affect the security of the server directly. The only difference is in the encoding.
But a client can carry out attacks against any code that they can cause to be executed. And more complicated protocols allow the client to exercise more code, so they are less secure. More code = more bugs = more security problems = more time and money spent finding, testing and installing patches. The biggest security risk for people trying to secure systems is the marketers who make their livings selling developers new software that they don't need. Why is: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";> <SOAP-ENV:Body> <m:GetLastTradePrice xlmns:m="something"> <symbol>CSCO</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> inherently better than: http://server.com/GetLastTradePrice?symbol=CSCO Jason Renard wrote: >I've heard lots of scary stories about SOAP, in particular because it has some form >of RPC functionality and doesn't have its own built-in security, but I've not seem >much detailing the real risks. After all, with HTTP connections to back-end >applications you can do a lot of damage too (especially with some ASP pages or with >CGI scripts). I get the feeling that allowing RPC (for example on Unix systems) is a >'system exposure', but I'm wondering whether allowing SOAP is just an 'application >exposure' in which case what's the difference between that and parameter-driven CGI >scripts? And how about allowing SOAP for the purposes of 'Web services' together with >SAML or some other authentication mechanism? I, too, am wary of SOAP but I'd like to >try and put the risks in context so any pointers to good reading material would be >appreciated! > >Jason > _______________________________________________ ISSforum mailing list [EMAIL PROTECTED]
