REST API and security

(Rocky Lhotka) #1

I suppose this might not be a “bug”, but it is a serious issue.

Last night I started playing with the REST API, making calls against a non-public forum. I found that once I had the API key from Discourse I needed a username to make any call - which makes sense since the forum is private.

But I found that I can use any username from any user and it works. So once someone has the API key they can impersonate any user in the forum? No need to authenticate that user’s credentials - all you need to know is their username.

Is this not a major gaping security hole?

(cpradio) #2

Did you use the Master API Key or one assigned to a specific user?

(Rocky Lhotka) #3

My intent is to create an app that can be used by all my employees, so I used the master key.

If I create per-user keys I’d need to create a key for every user and then come up with a way to get the right key to the right user’s client device at runtime right? That seems impractical - though perhaps that’s the design intent of Discourse?

(cpradio) #4

Well my point was, the master key is designed to be user agnostic. So an app doing things on behalf of the user is really what it is for (I think) – @sam and @eviltrout can speak to that better.

API Keys assigned to a specific user, are for that user to integrate with discourse. We have one setup for our Slack Channel Bot, it is assigned to a specific user so that user can’t do unwanted things, they are limited to the permissions they have in Discourse.

So in reality to depends on 1) who has access to your app, 2) who has access to the key, and 3) what your app needs to be capable of doing.

(Rocky Lhotka) #5

It sounds like the API is not (at least today) designed to support the creation of mobile apps or system tray notification apps (which is what I’m trying to create).

(Sam Saffron) #6

For push notifications we are looking at implementing some sort of service that publishes a payload to a designated external endpoint.

Still working out the details on it but we already have desktop notifications and this would be an extension of that.

(Sam Saffron) #7

Also, curious, why are you looking at building a systray notification app when its already built-in to Discourse?

(Rocky Lhotka) #8

Only if you use Chrome right? No notifications for Edge users on Windows 10.

Or is there something I’m missing?

Also, I’m using this to learn the API as we evaluate replacing yammer with Discourse. We have a number of integrations in yammer with our internal business systems and apps, so I’m trying to see if the Discourse API can support those same integrations.

(Kane York) #9

The API keys are admin-only right now.

You need to maintain a cookie jar and go through the login flow if you’re shipping code to users.

(Rocky Lhotka) #10

I’m afraid I don’t know the term ‘cookie jar’ in this context?

(Sam Saffron) #11

I follow, this integration is doable but a bit hairy.

The issue is that end users need some way of asserting their identity. If you have a way of getting the authorization cookie in the desktop app (maybe wrap a browser for login) then you can use the message bus direct to grab the messages.

All the desktop notifications are posted on a secure channel.

The message-bus protocol is quite simple and now clients are implemented in both js and ruby.

(Kane York) #12

Sorry, that means a persistent store for cookies. Or you could just do what @sam said and use a WebView and grab out the _t cookie. (Still need to store it somewhere, :stuck_out_tongue: )

(Sam Saffron) #13

A very belated reply, but these days we have a mobile app and a proper protocol for user api keys and pushing notifications.