Designing coockie-less login for API

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Designing coockie-less login for API

Yuri Astrakhan
I would like some feedback on the issue of how to allow API users to
prove who they are without using a cookie (some clients simply do not
support them), but instead pass all relevant information in the
URL/POST.

The login api module returns userID, userName, and userToken - all
necessary parts of a cookie. The client should be able to pass those
values in the URL, which should override the browser cookie (or lack
thereof), and instead resume the session specified.

The $_SESSION object gets initialized based on the cookie before the
php code starts. In order to resume the session, I could set
$_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken']
to the URL values, and set $wgUser = User::newFromSession() before any
other operations.

Does this introduce any security risks? Is there another way to solve this?

Thanks!

_______________________________________________
Mediawiki-api mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: Designing coockie-less login for API

madman bum and angel
Yuri Astrakhan wrote:

> I would like some feedback on the issue of how to allow API users to
> prove who they are without using a cookie (some clients simply do not
> support them), but instead pass all relevant information in the
> URL/POST.
>
> The login api module returns userID, userName, and userToken - all
> necessary parts of a cookie. The client should be able to pass those
> values in the URL, which should override the browser cookie (or lack
> thereof), and instead resume the session specified.
>
> The $_SESSION object gets initialized based on the cookie before the
> php code starts. In order to resume the session, I could set
> $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken']
> to the URL values, and set $wgUser = User::newFromSession() before any
> other operations.
>
> Does this introduce any security risks? Is there another way to solve this?
>
> Thanks!

This makes sense to me.  Passing the ?PHPSESSID= query string should be
a perfectly acceptable alternative to cookies; that's for what it was
made.  As for Jonathan mentioned, though: You might want to include the
$_SERVER['REMOTE_ADDR'] in $_SESSION and then check it when
authenticating the user.  Bots' IP addresses should not be changing in
the middle of a run, and it could prevent replay attacks like those he
describes.

-madman bum and angel


_______________________________________________
Mediawiki-api mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: [Wikitech-l] Designing coockie-less login for API

Merlijn van Deen
In reply to this post by Yuri Astrakhan
> In my humble opinion, passing session information in a URL is a bad
> idea. This could lead to social engineering attacks "paste your
> address to me" where people can then get the Session ID and thus
> manipulate the user's login. This is why cookies are the default.
In general, you are right. However, I doubt if this api use will happen
often: the api is an advanced *programming* interface, and not meant for
general client use ;). I assume Yuri wants to introduce it because many
simple (and even many more advanced) http client libraries do not support
cookies.

> POST would probably work okay, though. But then, you'd have to use
> buttons to go anywhere on your site, and the code just starts becoming
> unmaintainable.
Well, again, no. For api use this could be used, as the client can just
add post data. It's not necessary to browse the entire wiki using this
system, only api.php has to accept it :)

--valhallasw


_______________________________________________
Mediawiki-api mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: Designing coockie-less login for API

Platonides
In reply to this post by Yuri Astrakhan
Yuri Astrakhan wrote:

> I would like some feedback on the issue of how to allow API users to
> prove who they are without using a cookie (some clients simply do not
> support them), but instead pass all relevant information in the
> URL/POST.
>
> The login api module returns userID, userName, and userToken - all
> necessary parts of a cookie. The client should be able to pass those
> values in the URL, which should override the browser cookie (or lack
> thereof), and instead resume the session specified.
>
> The $_SESSION object gets initialized based on the cookie before the
> php code starts. In order to resume the session, I could set
> $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken']
> to the URL values, and set $wgUser = User::newFromSession() before any
> other operations.
>
> Does this introduce any security risks? Is there another way to solve this?
>
> Thanks!

Passing them as GET is always dangerous (having wsToken you can log in
without the password).

I don't see how would that help cookie-less clients, which anyway would
be rare (some example of them?) as you still need the session cookie (at
least for editing). I had to add a dummy edit-request to my code to get it.
I'm not so sure that you can _resume_ sessions without the session-id.
Maybe add a login action wich outputs the session instead? (and add a
parameter to treat as a cookie).

_______________________________________________
Mediawiki-api mailing list
[hidden email]
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api