----- Original Message ----- From: "Ricky Ho" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, January 28, 2003 11:24 Subject: RE: Web Service Model - Security Issues
> I think we should separate "security" from "DOS" attacks. The current web > services standards has sufficient "technical" coverage in security, it is a > matter of rate of adoption. > > DOS attack is different. In fact, by looking at the complexity in security > processing, the hacker doesn't need to simulate many clients to bring down > a web services site. > mmm, DOS defence is hard. I dont think axis is massively extra vulnerable compared to a web site built with JSP pages that also works with XML, but it depends on what you get up to. looking at Axis, we have various vulnerabilities -XML processing. With SAX processing Axis, this may not need to be done till it gets to the destination, so we need to verify the caller before getting to any point where the service is vulnerable to complex XML requests. Axis 1.1 is not vulnerable to entity expansion attacks, or to xsd:include attacks to get at files. -SoapHeaders: could expose bugs in their implementation, or be vulnerable to complex XML attacks -the endpoint itself, in processing XML or in the functionality -Attachments. If these arent cleaned up (Axis1.0 for example), then you can do a disk space attack. CVS_HEAD axis should clean up... -Log files: can these be overloaded? It depends on your log4j configuration. I like rolling files in their own disk partition. -Spoofed IP address of sender to get past router/filter. If the router is smart about where the trusted callers come from (VPN only), this risk is reduced. -GET calls that create CPU load. I'd worry that we may regenerate the WSDL info every GET; if this is the case then that is a vulnerability of its own. Plus there is the GET to SOAP mapping, which perhaps should become a configurable option. -cross site scripting. A fix for an instance that went in two weeks ago, it was in an obscure area *and* standalone axis doesnt have any data to steal. If anyone has time on their hands, experiments and code walkthroughs on the various header handlers would be a good activity to find issues before someone else does. Any vulnerability in Axis could be duplicated across installations, which is a bad thing... -steve ps. I dont advise making happyaxis.jsp public either, as then people can find your service on google, whether you want them to or not: http://www.dde.adsl.dk/hitcounterdemo/happyaxis.jsp http://jbs.cs.unc.edu:8888/axis/happyaxis.jsp http://63.195.86.146:8080/axis/happyaxis.jsp
