William Vambenepe's blog

There is a new WSDL validation tool on IBM’s AlphaWorks site: the Web Services Interface Definition for Intrusion Defense. This is an Eclipse plug-in that checks out your WSDL and flags “any interface feature that could open a door to hacker attacks”. What does it mean in practice? Well, it flags any usage of xsd:any (or xsd:anyType or xsd:anySimpleType) anywhere in your schemas. It also complains if you have elements with maxOccurs=”unbounded”. And more of the same. The result is that this excludes pretty much any existing schema definition. And most of the useful ones one can think of.

The payload of XML messages should reflect the business logic of the service and not the convenience of the implementer. Go tell the line of business manager that the “checkout” operation should be modified so that the number of items in the shopping cart has a hard-coded limit. Go tell the print shop that they can’t accept XHTML documents as input. It is the implementer’s job (and by that I include the runtime, IDE and tools) to make sure the message processing code (be it at the plumbing level or the business level) doesn’t expose security holes.

Eager to prove wrong those who have a hard time picturing a January face to face meeting in Australia as little more than an excuse for some scuba diving, the WS-A working group is cranking through its issues list. One of the outcomes is that issue #8 is now resolved. The issue is about identifying which headers in a SOAP message are there because the EPR used to address the SOAP message required it. This problem is familiar to anyone who has ever been the victim of the common joke that consists in tricking someone who doesn’t speak a certain language into memorizing and later repeating a sentence in that language while misleading them on the meaning of the sentence. And waiting for them to embarrass themselves in public at the worst time.

The group closed this issue by introducing an attribute that can be added to these headers (wsa:type). Yes, the world really needed another type of “type”. BTW, the resolution will need to be tweaked as a result of another decision: issue #1 was resolved by getting rid of reference properties, leaving only reference parameters. More on this in a future post, but at least this gives an opportunity to replace wsa:type=”parameter” with wsa:parameter=”true” and avoid yet-another-type.

Going back to issue #8, I am glad the group somewhat acknowledged the problem but this doesn’t solve it. For two reasons:

1. The schema of the header element might not allow this attribute to be added
2. Even if the attribute is present, the recipient of the SOAP message can pretend to not understand it (”I don’t care about this attribute and all the other WS-A crap, all I know is that you sent me the ‘I owe you $1,000′ header and you signed it so now pay up!”)

The way to solve both of these problems was to create one additional SOAP header (in the WS-A namespace) that could be marked mustUnderstand=”true” and points to all the headers in the message that are there because “the EPR told me so”. I proposed this (the wsa:CoverMyRearside approach) in the one and only message I have sent to the WS-A WG, but obviously I wasn’t very convincing. Since I don’t participate in the WG I might never understand what is wrong with this approach. What really surprises me is that it wasn’t even considered. The issues list shows only 3 proposals but the minutes of the face to face show that there was a 4th option considered, which comes a bit closer. Basically, it is the same as the adopted solution with the addition of a WS-A-defined header (that could be marked mustUnderstand=”true”) which states that “by processing this header you agree that you understand the wsa:type attribute when present in other headers”. This is not very elegant in my mind and doesn’t solve (1) but it does solve (2).

Interestingly, even though the wsa:CoverMyRearside header approach was not chosen by the WG, nothing stops me from using this approach: I can defined and use a header in my namespace that I’ll mark mustUnderstand=”true” and that will point to the headers that are there only because “the EPR told me so”. The problem of course is that my namespace is not going to be nearly as well-known as the WS-A namespace and most people will fail on processing my messages because it contains a mustUnderstand=”true” header they do not understand. So in practice I can’t do this. That being said, I wouldn’t be surprised if some spec somewhere one day decided that the mechanism in WS-Addressing is not good enough and that they should take on the task to define such a header because they need this protection.

A packaged was shipped to me through UPS. As usual, I received an email message informing me that it had shipped and giving me a URI to track its progress. This is what the URI looked like (after changing the tracking number and inserting a few line breaks):

http://wwwapps.ups.com/WebTracking
/processRequest?HTMLVersion=5.0&Requester=NES
&AgreeToTermsAndConditions=yes&loc=en_US
&tracknum=123123123123

The interesting thing to notice, is that there is a parameter in the URI, called “AgreeToTermsAndConditions” and its value is set to “yes”. If you do a GET on this URI, you will receive, as expected, the description of the status of the shipment. On the other hand, if you go to the UPS Web site armed with just the tracking number you have to check a box that reads “By selecting this box and the ‘Track’ button, I agree to these Terms and Conditions” before you can track the shipment. It seems pretty clear that the “AgreeToTermsAndConditions” parameter is in the URI in order to plug into the same Web application from the email link as from the Web page and this application was designed to check that the parameter is present and set to “yes”.

This has several similarities with some of the discussions around WS-Addressing. First, it illustrates the need to plug into an application in a place where the application might not have been designed to allow you to do so. In this case, we can imagine that the tracking application was designed with the assumption that people would only invoke it from the UPS web site. One day UPS decided it would be nice to send in email a link that takes people directly to the status of a particular shipment rather than just tell them to “go to ups.com and enter your tracking ID in the tracking form”. One important reason for pushing back on the idea of wrapping reference properties is that it would prevent such a scenario in a SOAP world. For this reason I agree that a wrapper for reference properties is a bad idea and if reference properties remain in WS-Addressing the way to fix this mechanism is to leave them as SOAP headers but add a WS-Addressing-defined SOAP header to list headers that were added to a message only because an EPR requires it, with no implication that the sender stands behind any semantic that might be attached to them.

When I write about “fixing” reference properties in the previous sentence, I am referring to the fact that the current version of WS-Addressing creates a lot of confusion as to the implications of sending SOAP headers and whether I can be held liable by anything that is in a SOAP header I send (and potentially sign). This is the second thing that this UPS URI illustrates by analogy. As a human I get a sense of what a parameter called “AgreeToTermsAndConditions” corresponds to (even though the URI doesn’t tell me what these terms and conditions are). But what if the parameter name was shortened to its acronym “ATTAC”? In any case, I am not expected to understand the composition of this URI, I should be able to treat it as opaque. Just like resource properties. And for this reason, when I do a GET on the URI I am not bound by whatever the presence of this parameter in the URI is assumed to mean by UPS. This means that I can NEVER be bound by the content of a URI I dereference because how can one prove that I understand the semantic of the URI. Even when I fill a form on a Web site, I don’t know (unless I check the HTML) how the resulting URI (assuming the form uses GET) will come out. There might well be a hidden parameter in the form.

In a SOAP world, this can be fixed by meaningful, agreed-upon, headers. If people agree that by sending (and signing) a SOAP header you are making a statement, then you can build systems that can rely on the ability to make such statements as “I understand and agree to the set of terms and conditions identified by a given QName”. But this breaks down if people are able to say “I didn’t understand I was saying this, I was just echoing what you told me to say”. This is what the current WS-Addressing spec does, and what needs to be fixed. Let’s see how the UPS URI could translate to an endpoint reference. For this, we need to consider two scenarios, both of them equally valid.

Scenario 1: legacy integration

In this scenario, the UPS people decide they do not require the invoker to actually make a statement about the terms and conditions. They just need a SOAP header called “I agree to the terms and conditions” to be set to true because this is how their application is currently programmed (it will fail if it doesn’t see it). In this case, it is perfectly reasonable to put a “I agree to terms and conditions” element as a reference property and this element will be sent as a SOAP header, preventing the application from failing. But in order for SOAP headers to be used to make a statement in some cases, there needs to be a way to expressed when, as in this scenario, the invoker is not making a statement by including it. Thus my earlier proposal of a wsa:CoverMyRearside header (that points to all the headers I include for no reason other than because an EPR asks me to). The other option, as written down by Dims is to add an attribute in each such header. But there are two main drawbacks to this approach: (1) unlike a new SOAP header, I can’t mark an attribute “mustUnderstand=true” (Dims’ initial proposal actually had a SOAP header with “mustUnderstand=true” for this very reason) and (2) some elements might not allow arbitrary attributes to be added at the top level.

Scenario 2: meaningful header

In this second scenario, the UPS people want to make sure, before they return the tracking information, that the invoker has made a statement that it understands and agrees to the terms and conditions. In this case, it makes no sense to put a “”I agree to the terms and conditions” element as a reference property as what is intended is not for such an element to be echoed blindly but to be used to make an explicit statement. In this scenario, the EPR sent by UPS would contain all the opaque elements, those sent for the benefit of the UPS application but by which the invoker is not making a statement (from the look of the URI, this would be “HTMLVersion”, “Requester”, “loc” and “tracknum”). But the “agree to terms and conditions” header would not be specified as a reference property, it would be listed in the WSDL description of the service. And when the invoker sends this header, it would not be included in the wsa:CoverMyRearside header because the invoker is indeed making a statement by sending it.

I am a bit confused about the attempt of the credit report companies to “protect the link” to the new site where one can get free credit reports (see the bottom of this article). I understand the problem of phishing and I agree that this site will be a very tempting target for phishing. The “solution” the people at annualcreditreport.com came up with is that links to their site won’t work unless the link is either on the FTC web site or one of the three credit report companies. For example, try clicking here and it should give you an error. This is presumably done by checking the “Referer” HTTP header. Yes, it’s “referer”, not “referrer”, an example of how authors of Web browsers are normatively required to make spelling mistakes, this should keep all of us spec editors on our toes (which, as a side note, happens to be literally the case for me this week because I slammed my heel on the edge of the swimming pool by doing an aggressive flip turn a bit too close to the wall during a Master’s swimming training session).

Anyway, back to the “protect the link” story. Let’s see how this would work. I have in front of me a hypertext link to their site. If I know that the site has this “protection” then why would I click on it? If it works then it’s a fake and I don’t want to use it and if it’s not a fake then it won’t work. In any case I know I’ll have to enter the URL by hand so I’ll do it right away. And if I am not aware of this behavior then I will click on the link. If it works (because the link is a fake), then I have no reason to suspect anything fishy and I’m in trouble. If it doesn’t work (because the link is real) then I’ll see that I have to enter the URL by hand and I will be out of trouble but I wasn’t in trouble to start with since the link was correct. In either of these four permutations this system doesn’t do any good.

The scary thing is that when people learn about this system, they might actually be more trustful with sites that implement something like this. But what stops a phishing site from doing the exact same thing, giving people an error message unless they type the URL by hand? Nothing. This reminds me of an email I once got from my bank to “educate” me about phishing. With “helpful” advice such as “we will never request personal information from you until after you are logged into our site using your username and password”. Hello? I give them my credentials and this supposedly authenticates them to me?