locked
WCF Data Service Insert and Update Security RRS feed

  • Question

  • I've built a WCF Data Service that is secured by a Simple Web Token (SWT) from Azure ACS which includes a claim like "parentid=100". Let's say my data service has two entity sets exposed: Parents and Children, and my token allows a "parent" to view their Parent entity (based on this claim), and all of their Children records.

    So, let's say I'm a Parent and my ParentID = 100 (which ties back to the token's claim). My question is this... Would it be possible to craft an POST message to data service that adds a new Child entity with foreign key ParentID = 101 that would actually insert a record into my neigbor's Parent data tree? Keep in mind that I have a firm grasp of the SWT token, and I'm not talking about tampering with the token - I understand how the signature protects agains that.

    In other words, to I need to use the ChangeInterceptors to validate that the claim in the token matches the incoming ParentID on the new Child entity? While my example is over simplified, and frankly half-baked, I'm trying to get at the question of whether or not I need to validate incoming inserts, updates, and deletes against token claims to ensure that a user hasn't submitted a malicious POST/MERGE/DELETE message that's trying to affect data outside of their permitted scope.

    I'd love to believe that there's some "magic" built into WCF Data Services somewhere that would avoid this situation, but I'm guessing there's not. And that doing a little extra work to validate incoming Key settings is prudent and not just over-thinking the situation.

    Any thoughs?


    Chris
    Thursday, April 29, 2010 12:25 AM

Answers

  • Hi Chris,

    WCF Data Services does not natively understand the notion of a foreign key. It is possible to craft payloads in which the foreign key does not match the navigation property links, and both will be applied to the underlying provider (in this case as a SetValue and a AddReferenceToCollection/SetReference call on the provider's IUpdatable). It is the responsibility of the data provider to resolve this conflict, and it is typically assumed that the navigation properties, which are applied last, win.

    Now, if there is a query interceptor that prevents you from addressing the other Parent entity (it sounds like there is, correct me if not) then you will not be able to refer to that entity in the payload. So, the only malicious payload that would work is one where the navigation property is valid, but the primitive foreign key is not, and again, the navigation property should win. However, if the navigation is not required (say it has 0..1 multiplicity) then its possible for only the malicious foriegn key to be present, which would get through.

    Long story short, given that this falls into a gray area dependent on provider-specific implementation details, I recommend writing the change interceptor.


    Matt Meehan, WCF Data Services (Astoria)
    Thursday, April 29, 2010 4:24 PM
    Moderator