Hi all, I have some web services with the following requirements:
- Ability to receive very large attachments (several GB length). - Security provided by WSS4J I am currently using Axis 1.2, and planning to use Axis 2 once a stable release is published. Playing with these services, I have noticed some security limitations/vulnerabilities in Axis, related to the processing of attachments. Having a web service installed on a Tomcat server, I have successfully performed the following attacks with very simple client applications: - I have sent a request with a 10MB file repeated 1024 times with different names. This leads to 10Gb of temp files created in the "attachments" directory. They are correctly deleted after the request is processed, but in the meantime, they are wasting hard disk. - I have performed the previous test in 200 threads, and caused the server disk space to be reduced to 0, and my server to stop responding. For these simple DoS attacks, the client application did not need to send valid authentication data. WS-Security handlers do not start processing until all attachments have been received. I have also noticed that sending a large file with MIME attachments takes almost twice the time needed to receive one. I guess the cause is that Axis attachment implementation uses DataHandlers for accessing the file, and DataHandlers do not have a method for getting the file length. This means that the whole file must be read twice: the first time to get its length, and the second one to actually send it. MIME attachments are the only ones supported by the "Attachments Profile 1.0", and they require each part length to be specified before sending the actual part data. Said this, I would like to know the opinion of other users in this forum about including some features in Axis 2 (or prepare Axis 2 so it is possible to implement them): - Restrict the number of accepted attachments in a per-method basis. If a request arrives with more attachments than allowed, we can directly reject it by closing the connection. - Invoke some kind of handler, or filter, just after receiving the SOAP headers, and before starting to process the message body. This way, the request can be early rejected if it does not have valid credentials. - Create a "KnownLengthDataSource" with a method "getLength(), so when used, the attachments implementation will be able to get the data length without a slow read. - Alternative implementations of the server attachments support. In this case, the idea would be to have a "lazy" implementation that would allow the engine to invoke the service method *before* attachments are actually read. I would love such an implementation, as it would allow me to implement an "attachment forwarding" service without writing and reading (twice) a temporary file. Any comment would be greatly appreciated Regards, Rodrigo Ruiz
