On Thu, 04 Nov 2004 16:03:14 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
> Joe Gregorio wrote:
> >
> > Ok, I think, after 6 or 7 follow-ups I think I finally see a problem.
> > Here is a scenario:
> >
> > Malicious user X produces an Atom feed served with an
> > X-Atom-Error header.
> >
> > Malicious user X could change their X-Atom-Error header to point
> > to someone elses URI (it could be /their/ Error URI or it could
> > be a completely different service). Either way Malicious user
> > X then intentionally forces their Atom feed to be invalid, thus
> > causing all the subscribers to X Atom's feed to hit that
> > unrelated service.
> >
> > Am I understanding the scenario correctly?
> >
>
> Yes, and the effect of hitting that unrelated service is unknowable. The
> operation must be idempotent to be implemented responsibly.
Thank you. Now that I understand the point you are trying
to make I agree that using POST for this is inappropriate.
Actually, just a minor correction on your nomenclature,
the term you should use is 'safe', not 'idempotent', when
describing the effect:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1
I did read Tim Bray's response that it won't be that many
hits and that the culprit would soon be found out, but that
assumes a pretty dumb Malicious user X. What if the feed is
only served intermittently with bad X-Atom-Error header? Or
only served that way to certain aggregators? And don't tell
me no one would ever do that, I've actually done something
similar myself by serving a different RSS file based on the
User Agent. Not for malicious reasons mind you, but it
was very easy to do.
You will note that it is still possible, if PaceSericeError
is adopted today, that mischief will still be possible
since I can still get *your* server to be pinged as having
an invalid feed by *me* tweaking my X-Atom-Error header
and then intentionally invalidating my own feed.
What can we do?
The only solution that I can see right now that avoids all
of these problems is that the ERROR method be used
and that it only be used on the URI of the feed itself.
I.e. if you get any of the error conditions in the Pace
then the client sends the ERROR method back to the
URI from which is retrieved the Atom feed.
Benefits:
1. Very simple.
2. Obviates the need for the X-Atom-Header completely.
3. Can't be used in any of the malicious ways outlined above.
4. Since we aren't worried about cross-site usage we can
go back and add in a request body that describes the
problem in more detail.
Disadvantages:
1. A whole new method.
2. More difficult to implement on the server side depending
on how your site is implemented. I.e. it /is/ possible to
accept an ERROR method on a statically served file
and redirect it to a CGI to handle the request,
but that requires some mod_rewite magic in your
.htaccess file.
This is the only workable solution I can see
right now that avoids the above problems. I hope
someone else has a better idea because I'm
not terribly fond of the idea based on the difficulty
that may be faced in implementing it. Also, inventing
new HTTP methods makes me slightly squeamish.
If we do this then I think it should be written
as an I-D outside of this WG.
-joe
--
Joe Gregorio http://bitworking.org
