----- Original Message ----- From: "Benjamin Tomasini" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 28, 2003 11:12 Subject: RE: Web Service Model - Security Issues
> I would think that a session-scoped service would be a much greater > risk. Like an induced memory leak. > > I would also think that typically, most of the consumed resources in a > "well-formed" DOS would be in the parsing of the XML, and the > serialization / deserialization. So the application code, db .. etc, > may have somewhat of a break. Unlike a website, where you would see > your db pool have problems, etc ... > > Ben Current thinking in Axis is documented here: http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/security.htm l XML parsing is a weak point: if the payload is malicious XML then by the time you get to validating the message the damage is done. So smart routers and servlet filters to validate IP addresses are an essential part of a production system. Once the payload is validated, I am not convinced that the load of creating new objects for each call is the real load issue; not unless that object is particularly heavyweight. Why worry about the load of instantiating a new endpoint object when AxisServlet has already created a couple of strings? What is a security risk is what your endpoint does; if a malicious packet can cause your endpoints to spin, do long database searches, etc, then you have a problem. There is nothing like an aggressive join of two or three tables to bring an entire DB cluster to its kness. Every web service endpoint must be as paranoid as a cgi-bin script. real anecdote from "When web services go bad" We worked out that on a component we were given for image processing wasnt validating input and so an malformed url (with left pixel column param > right pixel colum param or something) would crash IIS, because it caused an access violation inside the COM object the ASP page was calling (no isolation, see). We called this the 'URL of Death', and had to modify the ASP code to add validation. Fortunately we found it before anyone else did; this shows why devious people on the team are good. And why legacy C/C++ is a dangerous language for web services, SQL databases, etc, despite the performance boost. > But what about mal-formed requests to an Axis service? It would be > interesting to stress test Axis with a combination of well-formed and > mal-formed requests, to see how the Exception handling releases > resources, etc ... > yes it would; feel free to do so. Anything you find in the axis core we can fix before axis1.1 would be beneficial. I am worried about how well Axis compares the content-length of an incoming request versus what it is parsing; we could be vulnerable to very-large XML messages, especially ones with complex graphs. -steve
