Come to think of this, why do we really need that "callback" test? I
mean: we do expect only services to create policies, right? And only
policies for "their" own resources, right?

Which means that when a certain service requests to have a policy
created for, e.g.

http://serviceA.opentox.org/dataset/B

then the policy SHOULD come from an IP address corresponding to the
serviceA.opentox.org DNS name -- am I wrong in this assumption?
Because, if the assumption is correct, then, bar any IP/DNS spoofing
attempts, we could use only this simple check: whether the DNS name of
the request corresponds to the URL that is requested to be protected.

In other words, if the service gets a request for the resource above
from an address, which reverse-resolves to, say, badguy.aol.com, then
the policy service will reject the request straight away.

Cheers,
Luchesar

P.S. Once SSL/TLS enters, it actually becomes even more hack-proof.
Yes, DNS poisoning and IP spoofing are not unheard of, but if you
actually require also _client_ certificate for any connections to the
policy service (as opposed to OpenSSO, where this would make the
things more complex for the users), then you could actually check the
DNS name from that certificate. Again, it must correspond to the DNS
name of the URL in the policy creation request. Seems simple and
effective. Probably too simple, though, so I'm counting on you to
catch if I'm missing something important.


On Mon, Jun 28, 2010 at 22:08, Nina Jeliazkova <nina at acad.bg> wrote:
> Hi Andreas,
>
> Unless we invent specific query parameter/media type for the
> "reachability test" , this could be quite inefficient.   For example, if
> one happens to try to GET /dataset/{id} ,  for a large dataset , and
> ignore the results , this will be a waste of resources (server, network
> and perhaps client's ).
>
> Regards,
> Nina
>
> chung wrote:
>> Hi Andreas,
>>   Is it possible to allow just web services to create policies prior to
>> resource's actual creation? [I mean
>> using some token of theirs identifying them as web services and not
>> using other users' tokens]
>> If one attempts a DOS attack you can just disable the attacker's account
>> or if one creates policies in an
>> unexpectedly large frequency you can block the account for some time. It
>> would be more convenient if
>> we removed such a restriction.
>>
>> Note: This is not an objection, it would be just easier to me to go
>> without this restriction.
>>
>> Best regards,
>> Pantelis
>>
>>
>> On Mon, 2010-06-28 at 13:28 +0200, Andreas Maunz wrote:
>>
>>
>>> Dear all,
>>>
>>> I propose to make the A&A policy webservice more secure by checking
>>> availability of resource URIs at policy upload time.
>>> This is to tackle the issue of "pre-registration", i.e., to stop an
>>> attacker from registering arbitrary "promising" resource URIs (not under
>>> his control), by enforcing that every URI in a policy is actually reachable.
>>> Being "reachable" means that the webservice at the corresponding URI
>>> reacts by returning an arbitrary return code other than "404 (not found)".
>>> If nothing speaks against that I will add the functionality within the
>>> next few days. Please tell me, if you hold a different view on the issue.
>>>
>>> Best regards
>>> Andreas
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>