Context
XBlocks have enabled JWT authentication via its own custom code here:
https://github.com/openedx/edx-platform/blob/0b3e4d73b6fb6f41ae87cf2b77bca12052ee1ac8/lms/djangoapps/courseware/block_render.py#L752-L775
This code does not respect JWT scopes, and someone with a JWT with more limited scopes could call this endpoint when they are not supposed to.
Our JWT scope code is somewhat brittle. It relies on this middleware code to add a scope related permission class if no other scope related permission class is found. It then relies on DRF permissions to enforce this permission.
A solution might be to have custom code that makes use of that permission as well.
Ideally, our auth code (which is quite complex) would all live in edx-drf-extensions and this custom code for enabling JWT authentication (or DRF Authentication and permissions) on a Django request, would live with the rest of the other auth code so individual services don't implement custom solutions.
Aside: this custom code happened to cause an unexpected bug because it is authenticating using a Django request object, rather than a DRF request object.
Impact
Someone with a JWT with more limited scopes could call this endpoint when they are not supposed to.
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Context
XBlocks have enabled JWT authentication via its own custom code here:
https://github.com/openedx/edx-platform/blob/0b3e4d73b6fb6f41ae87cf2b77bca12052ee1ac8/lms/djangoapps/courseware/block_render.py#L752-L775
This code does not respect JWT scopes, and someone with a JWT with more limited scopes could call this endpoint when they are not supposed to.
Our JWT scope code is somewhat brittle. It relies on this middleware code to add a scope related permission class if no other scope related permission class is found. It then relies on DRF permissions to enforce this permission.
A solution might be to have custom code that makes use of that permission as well.
Ideally, our auth code (which is quite complex) would all live in edx-drf-extensions and this custom code for enabling JWT authentication (or DRF Authentication and permissions) on a Django request, would live with the rest of the other auth code so individual services don't implement custom solutions.
Aside: this custom code happened to cause an unexpected bug because it is authenticating using a Django request object, rather than a DRF request object.
Impact
Someone with a JWT with more limited scopes could call this endpoint when they are not supposed to.
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References