Author

Topic: Authorization bug (Read 599 times)

copper member
Activity: 786
Merit: 710
Defend Bitcoin and its PoW: bitcoincleanup.com
October 23, 2020, 10:11:42 AM
#4
@suchmoon this should be resolved in the latest release v1.33.2
The user_id should be taken from request headers.

Tried it and the behavior is: once you logout&login in the new tab you would be logged out from initial tab using websockets and would require page hard refresh to get the new session started there also. This is the trade-off for using single page web apps I guess...

A more efficient way will be implemented most likely after some code rewrite due to Angularjs EOL reasons as AdolfinWolf mentioned
... it seems that they're using AngularJS for their front-end framework, which is already on LTS until 31/12/2021, after which it is no longer supported.

Thanks again for catching this and please don't refrain from throwing anything else this way!
legendary
Activity: 3654
Merit: 8909
https://bpip.org
October 22, 2020, 05:38:53 PM
#3
Nice find!
Informed them about this and will be looked into.

Thanks for reporting  Grin

Thanks. Just to make sure - because my OP came out kinda scattered - there are two major issues there:

  • Showing one user profile in the frontend but submitting a different token to the backend. The frontend is getting the new token somehow so it must know the user has logged out and it should refresh the page with the correct identity. Or at the very least API calls should fail when there is a situation like that. It should not execute anything as "admin" when I'm shown as "suchmoon" and vice versa. This seems to affect most APIs. It also displays wrong UI elements, e.g. moderator buttons on posts when I'm not logged in as a moderator.
  • "POST /reports/posts" ignoring the JWT token. Perhaps there are other API calls that do the same thing. "POST /reports/users" also seems suspect - has the same reporter_user_id parameter. If I'm not mistaken this could allow impersonating any user in those API calls. I don't know node.js well enough and not inclined to spend hours debugging it but someone perhaps should audit all APIs for similar holes.
copper member
Activity: 786
Merit: 710
Defend Bitcoin and its PoW: bitcoincleanup.com
October 22, 2020, 04:36:06 PM
#2
Nice find!
Informed them about this and will be looked into.

Thanks for reporting  Grin
legendary
Activity: 3654
Merit: 8909
https://bpip.org
October 22, 2020, 08:24:31 AM
#1
Not sure if we're supposed to have one mega-thread for bug reports but I'll post this a separate thread as this bug seems horrible enough.

I was testing epochtalk moderator functions related to this: https://bitcointalksearch.org/topic/m.55430312

So I logged in as a regular user (let's call the user "suchmoon", complete coincidence of course), opened two browser tabs (using Firefox; as I've reported previously it's impossible to open multiple tabs with the same user in Tor Browser), created a few posts. Then in tab 1 I logged out and logged in as an admin. A few minor things here: can't report my own post and seemingly can't just delete a post without it being reported, but that's not the issue here.

So I'm doing admin things in tab 1. Then switch to tab 2. Still shows me logged in as suchmoon. I click on a thread. I post in the thread. It still shows me logged in as suchmoon but the post's author is admin. I can report the post though so I do. I switch back to tab 1 and in the report queue it shows that the post was created by admin and reported by suchmoon. Keep in mind that both posting and reporting took place in one tab where the logged in user was shown as suchmoon. I have a feeling that there might be some API calls where the backend just trusts whatever user ID is coming through... or maybe not quite as bad, maybe just expired but otherwise valid authentication is being accepted. A bug in either case.

Edit - upon further digging it looks that the frontend sends the correct JWT bearer token in both tabs but the backend uses reporter_user_id from the payload. I don't know why that reporter_user_id is even there.
Jump to: