V5 Users by id change can lead to conflict

API
1

Twitch lets users create user names that conflict with other user’s id. Since the API to access either by user id or user name is the same, this can lead to some very unexpected security issues (e.g. impersonation on services).

For example:

curl -s -H "Client-ID: $CLIENT_ID" https://api.twitch.tv/kraken/users/waneck                                                                                
{"display_name":"waneck","_id":28730891,"name":"waneck","type":"user","bio":null,"created_at":"2012-03-05T02:12:04Z","updated_at":"2017-02-24T14:35:35Z","logo":null,"_links":{"self":"https://api.twitch.tv/kraken/users/waneck"}}

I was able to create a new user called 28730891:

curl -s -H "Client-ID: $CLIENT_ID" https://api.twitch.tv/kraken/users/28730891                                                                              
{"display_name":"28730891","_id":148593651,"name":"28730891","type":"user","bio":null,"created_at":"2017-02-24T14:43:18Z","updated_at":"2017-02-24T14:43:19Z","logo":null,"_links":{"self":"https://api.twitch.tv/kraken/users/28730891"}}

So when we migrate to the new api, we get this:

curl -s -H 'Accept: application/vnd.twitchtv.v5+json' -H "Client-ID: $CLIENT_ID" https://api.twitch.tv/kraken/users/28730891                                
{"display_name":"waneck","_id":"28730891","name":"waneck","type":"user","bio":null,"created_at":"2012-03-05T02:12:04.958217Z","updated_at":"2017-02-24T14:35:35.349913Z","logo":null}

Ideally, the API should have a way to specify whether we want to access a user by id or by name, and it would be nice if numerical user names were reserved so we are sure this can’t be exploited.

2

Honestly, requesting by user id’s is how it should have been done to begin with. But any way, any conflicts would be the fault of the developer and not Twitch so it isn’t really fair to bash the new API. As far as “security issues” go, there isn’t anything that harmful you can request with the API, and anything that is somewhat sensitive information is requested with oauth tokens which wouldn’t lead to conflicts in itself because every token is unique.

3

When you migrate your code to v5, you shouldn’t be requesting by username anymore. That’s an error on the programmer’s part, not the API’s. However, It’s a legitimate concern for next year when v5 is planned to become default.

4

I agree that this can be avoided with careful coding, but the current API makes it somehow easier to allow impersonation. It would be nice to have a specific API to get by name, and by id - unambiguously.

I don’t mean to bash the new api, and agree that’s not a twitch concern by itself, but IMO an API should try to avoid these kinds of conflicts/ambiguity.

5

There will be no ambiguity once v3 is gone.

1 Like
6

So once v3 is gone, https://api.twitch.tv/kraken/users/ will be only accessible through id?

7

You’ll still be able to query via login name by using the ?login= query param, but no ambiguity there.

8

Oh, that sounds good then!

9

Also this is a non-issue if you specify the Accept header (or, alternatively, the api_version get parameter) properly. v3 will only go by user name and v5 will only go by user id on the /users endpoint. Anyone not specifying this is not using the API properly and will have to suffer the consequences. Its so simple to add that 1 extra line of code (or get parameter) there is no excuse.

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.