After a seminar on threat modelling today, I started thinking some more about how XML web services can be secured. The obviously hard part is that things like SOAP are typically run all on port 80. Multiple applications can be running on the same webserver. Sure, SOAP clients/servers can easily be configured to run on different ports, using basic authentication, SSL, or other standard techniques used for securing web sessions. However, the more important issue is that SOAP really falls into the same categories as RPC, Corba, RMI, and so on.
Anyhow, that's my brief rundown on how "simple little innocent applications" can have wider range affects that you don't normally think of. And, even if your program is closed-source, malicious users can still probe it to see what it is capable of. Also, as the simple vulnerabilities are blocked, the cracks/hacks around them just get more and more intelligent. Just as they say "there will always be a better idiot" about testing software for bugs and usability issues, there will always be somebody trying to break in. Again, it comes down to weighing the risk, or the cost/benefit ratio. There is nothing new under the sun.
Ok, so how can XML requests and their XML responses by filtered? With SOAP, there are three key things required in a request:
So, a filtering system (or shall we say, XML filtering?) would need to, at a minimum, look at:
The problem is that it's such a new concept, and has a much higher administrative load to configure this for every single Common Gateway Interface (CGI) based application. And, more processing power is required to do in-depth analysis of the proxied streams.
As a conclusion, using only regular expressions (as used in this http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/acmemail/sparkle/Acmemail/Filter/filterhtml.pl script) is probably not the way to go. Instead, some sort of fast DOM parser would be optimal.
I think I could do something like this... but I'm not sure how streaming HTTP/1.1 XML sessions would happen. For example, Jabber keeps a long running XML connection opening. The final closing XML tag is what tells the server the client has disconnected. Until then, the client just continues to add requests in XML to the socket.
Back to XML