A Meteor project i’ve been working on has recently gone in for a security audit at the company I work for; an issue has been flagged which could potentially be an issue for us all.
Below are the descriptions of each issue:
The issue is titled: No Session Management
Basically, after authenticating, Meteor is making XHR requests (if web sockets are disabled or unavailable) to retrieve data which appear to not contain any session identifier. The tester was able to take one of these requests and call it directly using curl and get back data, effectively totally unauthenticated.
As an addendum to the previous note the tester says:
To exploit this particular instance of this issue, there needs to be context for the attacker’s HTTP request to work - if a regular user is browsing the app, an attacker would need to win a race condition against user’s browsing to exploit this particular instance. In addition, the attacker would have to guess the random ID passed in the sockjs URL to retrieve the data. Even though this makes the attacker harder, this shows that the authentication problem is still there. The URL random ID shouldn’t be considered as an auth token in this case, as it is not necessarily considered secure (visible on the screen, remains in logs, opens questions on whether its generated using a secure crypto random number generator).
The request looked something like this:
POST /sockjs/753/a6mm0hqo/xhr HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
Accept-Encoding: gzip, deflate, br