Progress and some thoughts

[Richard 'toast' Russo]

On Wed, 22 Jun 2005, meepbear * wrote:

>> Regardless of all this, I don't really see how it can be avoided. The
>> impact should be minimal anyway.
> I was just considering the implications of connecting to a user supplied URL 
> that you can't possibly know is legitimate or not and two things came to mind 
> which was either feed it URLs that perform an action on behalf of the user, 
> or repeatedly POST stalling URLs. Even if the script instances aren't doing 
> anything, they still need memory to run, but it is obscure I agree with that 
> :).
>
> The first worries me a lot more than the second anyway. Even if I keep 
> consumer logs and regularly check for any suspicious claimed id URLs, I'd 
> have to tell my host about it since their server's IP will be showing up on 
> the attacked site and I doubt they'd allow me to keep it running for it to 
> happen a second time.
>

If you're really paranoid, you can keep a per domain success/fail counter, 
and refuse to accept domains that fail too often.  This would still let 
malicious agents supply evil urls, but at least you would not hit them 
that often.

If fetchhing a url can do bad things without any authentication, I don't 
think that's OpenID's fault.  You could included X-Forwarded-For headers 
in the consumer, so the administrator of an attacked site could have 
something else to go on.

For those running this on bigger sites, it's probably worth mentioning 
that the consumer should likely be expressly prohibited from accessing 
'internal' sites, possibly by placing the consumer machines on a different 
network segment.


-- 
Success! You are foaf http://openid.enslaves.us/