POSTs for non-idempotent requests

[Alex Payne]

All,

We're responding to an urgent vulnerability, and as part of our
response we're ensuring that all non-idempotent requests are made as
POSTs. This means that if you were creating favorites or friendships
with GET requests, your applications will receive an error 400 with
explanatory text that the request must be a POST. While it's always
been encouraged that your applications perform these requests as
POSTs, it's only been enforced programmatically on a couple of methods
(/statuses/update, for example).

The deploy for this is, unfortunately, going out in the next couple of
hours. I know that's an entirely inadequate amount of advance notice,
but we're forced to pushed this out to protect our users' security and
privacy. Thanks for your understanding.

--
Alex Payne
http://twitter.com/al3x

[Rob Iles]

Hi Alex,

I'm sure you'll get flack for this - responding to vulnerabilities in a timely manner, whilst making significant changes to core functionality, is never fun to manage.

Out of interest, once you've patched, will you be able / willing to discuss the "urgent vulnerability" that has forced the need for this update?

Good luck :)

Rob

2008/8/1 Alex Payne <al...@twitter.com>:

--


Rob Iles

RMIDevelopment

Web: http://www.rob-iles.co.uk/rmidevelopment
Twitter: http://twitter.com/Rob_Iles
Skype: rob_iles

[Stut]

Simple script tag with the src attribute pointed at the URL to add someone as a friend. Anyone who visits the site and is logged in to Twitter ends up with a new friend without realizing it.

This is a common vulnerability and I'm a bit surprised the have ever allowed this to happen, but at least they're fixing it now.

-Stut

[MatthiasG]

Yeah, twitpwn is a really useful guy :-).
OK, can someone help me please? I try this:

curl -u username:password http://twitter.com/friendships/create/ -d
id=bob&format=xml

The response I get:

"403 Forbidden: The server understood the request, but is refusing to
fulfill it."

What am I doing wrong?

[Kevin Tronkowski]

Matthias,

I have just implemented changes to our client by using the URL as
specified in the current API documentation (in your case .../create/
bob.xml)
but also specifying the id parameter as a POST parameter. This would
make
your curl example:

curl -u username:password -d id=bob http://twitter.com/friendship/create/bob.xml

-------------------

I am seeing something in my testing and am wondering if anyone else is
seeing
a similar behavior (or can let me know what I am doing wrong :-) )?

I get error 403 status codes (and error message: "You are not friends
with
the specified user") in my testing for certain combinations
of users when destroying friendships. Even though I am getting the
403
a subsequent call to re-create the friendship, succeeds.

If the first call to destroy the friendship really failed, I would
have
expected the subsequent friendship creation to fail with a 403 and
the error text "Could not follow user: USER is already on your list".

Thanks much,
Kevin

[Julio Biason]

On Mon, Aug 4, 2008 at 1:27 PM, Kevin Tronkowski
<Kevin.Tr...@gmail.com> wrote:
> I get error 403 status codes (and error message: "You are not friends
> with
> the specified user") in my testing for certain combinations
> of users when destroying friendships. Even though I am getting the
> 403
> a subsequent call to re-create the friendship, succeeds.
>
> If the first call to destroy the friendship really failed, I would
> have
> expected the subsequent friendship creation to fail with a 403 and
> the error text "Could not follow user: USER is already on your list".

Why? You try to destroy the connection, but the connection is not
there. So there is nothing to be destroyed.

When you create the connection, it wasn't there to start with, so it works.

Or did I get it wrong?

--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason

[Kevin Tronkowski]

Julio,

Sorry, a poor description on my part... there was an existing
connection.
Here is the sequence again.

1) User A has a existing friendship to user B.
2) User A destroys friendship to User B: 403 error.
3) User A creates friendship to user B: successful.

This scenario does not seem to happen for every user combination that
has
a existing friendship connection. In addition the problem does not
appear to be
temporal in nature: the friendship connection between A and B had
existed for weeks.

Did that help describe what I am seeing a little better?

Kevin

On Aug 3, 11:31 pm, "Julio Biason" <julio.bia...@gmail.com> wrote:
> On Mon, Aug 4, 2008 at 1:27 PM, Kevin Tronkowski
>

> <Kevin.Tronkow...@gmail.com> wrote:
> > I get error 403 status codes (and error message: "You are not friends
> > with
> > the specified user") in my testing for certain combinations
> > of users when destroying friendships. Even though I am getting the
> > 403
> > a subsequent call to re-create the friendship, succeeds.
>
> > If the first call to destroy the friendship really failed, I would
> > have
> > expected the subsequent friendship creation to fail with a 403 and
> > the error text "Could not follow user: USER is already on your list".
>
> Why? You try to destroy the connection, but the connection is not
> there. So there is nothing to be destroyed.
>
> When you create the connection, it wasn't there to start with, so it works.
>
> Or did I get it wrong?
>
> --

> Julio Biason <julio.bia...@gmail.com>
> Twitter:http://twitter.com/juliobiason

[Kevin Tronkowski]

In case anyone was waiting to see how how long it would
take me to discover that the behavior I was seeing was actually
my bug and not Twitter's, wait no longer (it actually didn't take me
since last night to find it... I do have a day job to attend to) ;->

I was actually calling the destroy API twice in quick succession.
Oops.

Kevin


On Aug 3, 11:46 pm, Kevin Tronkowski <Kevin.Tronkow...@gmail.com>
wrote:

> > Twitter:http://twitter.com/juliobiason- Hide quoted text -
>
> - Show quoted text -