--
perl -pe "s/\b;([st])/'\1/mg"

I'm not sure if Safe really helps. Suppose you have two subs in your code. Both use open to read some files and return data they have read. First sub should be directly accessiable via SOAP::Lite and second should not. How can Safe help here?

Actuall fix is restrict package and method names that can be called via SOAP::Lite.

--
Ilya Martynov (http://martynov.org/)

Well Safe restricts perlop's *and* namespace access so for that case you might put the second sub in a different package.

--
perl -pe "s/\b;([st])/'\1/mg"

JIK you read the article and are interested, I posted the use Safe; comment there as well (I did not plagarize ;-). However since they use a low resolution timestamp, and an UNobfuscated email address as an indentifier I did not give a valid address.

--
perl -pe "s/\b;([st])/'\1/mg"

However the mistake in the SOAP implementation is different. It is using the dynamic method lookup that Perl uses. This is not catchable with strict. This is an important detail. Someone trying to figure out why things work based on their coding example would be looking to the wrong dispatch mechanism and therefore they would seriously misunderstand what is going wrong.

But the fundamental problem is that SOAP is a poorly designed protocol designed with no eye to security, and built largely for the convenience offered because most firewalls will let through http traffic. This was said pointed out a long time ago by Bruce Schneier, but it is amazing how many people have missed the basic point. The point is that firewalls are retroactive protection for security mistakes in applications. If applications seek new ways around firewalls but continue to make the same basic mistakes then you are guaranteed to get into a situation where firewalls need to retroactively filter a more complicated protocol. Wonderful.

(What I actually want is for Microsoft to build into the OS something that requires SOAP tunnelled directly over https - so that the encryption in https makes it impossible to filter their inevitable security mitakes. When that happens I will have something concrete to stand on to argue for completely removing Microsoft from corporate networks. Remotely exploitable security holes which cannot be blocked and cannot be filtered. Lovely. But I digress...)<p Anyways back to the horrible security hole in Perl SOAP implementations. Well the security hole is obvious, and it is what I pointed out at Re (tilly) 1: Orthogonal Code and Security. The problem is that the SOAP server is using its ability to serve a request as synonymous with its permission to serve that request. Given that anyone can construct any request they desire, this is a huge problem. Given the number of people who seem inclined to follow the latest stupid buzzwords, this guarantees that many will follow the easy path towards a series of obvious mistakes which will give people like myself things to complain about for years to come.

I am positive that SOAP implementations in other languages are going to be making the same mistakes that Perl's do. Just a guaranteed side-effect of having network protocols designed by people without a clue about security implemented by other people who likewise lack clues.

If you want to use SOAP, do as is suggested in the article. Put your functions into a hash. Don't let any function not in that hash be called. And should you need to implement any security model more complex than, "This is publically accessible, that is not", then I wish you luck...