Using /sessions endpoint not creating restricted session tokens

[stevestencil]

Issue Description

When using the REST api to create a new session token as documented here the tokens are not set as restricted.

Steps to reproduce

Follow the instructions in the REST API Guide to create a restricted session token

Expected Results

A new session token should be created with restricted = true

Actual Outcome

A new session token is created with restricted = false

Versions

Parse-Server - 4.2.0
Parse-SDK-JS - 2.13.0

[EricNetsch]

@flovilmart @dplewis Yes, this is a major issue here among other related issues I will not disclose here

[EricNetsch]

@stevestencil Let us know which version of parse-server you are running?

[stevestencil]

@EricNetsch I updated my description with the versions

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[davimacedo]

Hi guys. I've searched all the code base and also this issue and I believe that the restricted flag existed in parse.com but was never implemented in the Parse Server open source. It means that setting restricted to true or false has no effect. And that's why the guide steps are also not working. So, we have three options here:
1 - remove this feature from docs
2 - implement the feature
3 - 1, then 2

@dplewis @TomWFox @mtrezza thoughts?

[mtrezza]

This issue and the linked issue seem to be a vulnerability disclosure, should we redact it?

I think it makes sense to remove the feature of restricted sessions, because:

• From the docs I understand that restricted sessions is mainly a Parse IoT feature. The Parse Arduino SDK is retired and the Embedded C SDK shows limited activity, last relevant activity in 2016. There seem to be no active contributors nor experts for Parse IoT around. Some authors expressed interest in maintaining the SDK years ago, but it's questionable whether one maintainer would even be enough to keep it up-to-date. The danger with keeping this not-maintained SDK that is apparently not much in use either is what we are facing now: a fundamental security flaw that stays unnoticed for years.

• It seems to be a half-baked feature, maybe even obsolete considering the advancements of ACL, because a restricted session can still read in User, Role and Session (except for unrestricted sessions), and can read/write data in any other class just like a normal session. Even the docs are somewhat contradictory:

Restricted Sessions are useful for “Parse for IoT” devices (e.g Arduino or Embedded C) that may run in a less-trusted physical environment than mobile apps. However, please keep in mind that restricted sessions can still read data on User, Session, and Role classes, and can read/write data in any other class just like a normal session. So it is still important for IoT devices to be in a safe physical environment and ideally use encrypted storage to store the session token.

Use restricted sessions in a "less-trusted physical environment" but use them in a "safe physical environment" doesn't make much sense to me. The more effective approach seems to be to store tokens on the IoT device in a secure storage and recommend a distinct user/role for the IoT.

Unless there is another use case (maybe we can hear from someone using the IoT SDK?) I would go for:

• Remove the feature from code
• Remove the feature from the docs and recommend to store the session token in a secure storage and use distinct users/roles for IoT
• Retire Embedded C SDK and maybe start a call to actively look for maintainers on the Parse Server issue site for better visibility

[davimacedo]

This issue and the linked issue seem to be a vulnerability disclosure, should we redact it?

Technically yes, but, since the other issue is public for 2 years, I believe that it is better to keep it public for reference and we use this current thread to discuss the future of the feature.

[ggkitsas]

Hi,

I am contacting you on behalf of Snyk Security team. We would like to ask if you have a timeline for fixing this issue.

Best,
Snyk Security Team