Authorization Token allows action without login
Discussed in https://github.com/LycheeOrg/Lychee/discussions/2301
Originally posted by agademer February 26, 2024
2/ A user with may_upload=0 can still upload a photo through Photo::add (with the help of the famous API TOKEN).
- Is 2/ a bug that will be solve in the future ? or a normal behavior ?
@agademer
Could you please double check your finding? Especially that:
- users have may_upload=0
- users do not have upload rights to root directory
- users do not have edit rights to shared directory
https://github.com/LycheeOrg/Lychee/blob/57e35039e232fd0ff5aa755ddb3b70a6f4d2002a/app/Http/Requests/Photo/AddPhotoRequest.php#L13-L16
Ensures the Authorization. https://github.com/LycheeOrg/Lychee/blob/57e35039e232fd0ff5aa755ddb3b70a6f4d2002a/app/Http/Requests/Traits/Authorize/AuthorizeCanEditAlbumTrait.php#L13-L20
This calls the policy: https://github.com/LycheeOrg/Lychee/blob/57e35039e232fd0ff5aa755ddb3b70a6f4d2002a/app/Policies/AlbumPolicy.php#L223-L236
I don't see any error in the code or I am missing an edge case. Only thing I could think of is that the token would be giving admin perm instead of user perm which would be seriously worrisome.
Hi Benoit :
Fresh install of lychee with docker
1/ User without upload right
[image: image.png] curl --request POST --url https://MYURL/api/Album::add --header 'Accept: application/json' --header 'Content-Type: application/json' --data '{ "parent_id":"", "title": "agademer_public" }' --header 'Authorization: Rq-fBwVuO1AgAdpjGLW8Xw==' { "message": "Insufficient privileges", "exception": "UnauthorizedException" } curl --request POST --url https://MYURL/api/Photo::add --header 'Accept: application/json' --header 'Content-Type: multipart/form-data' --header 'Authorization: Rq-fBwVuO1AgAdpjGLW8Xw==' --form @.*** --form albumID="" { "message": "Insufficient privileges", "exception": "UnauthorizedException" } 2/ Give the user upload right 3/ The user create an album 4/ Remove the user upload right
$ curl --request POST --url https://MYURL/api/Photo::add --header 'Accept: application/json' --header 'Content-Type: multipart/form-data' --header 'Authorization: Rq-fBwVuO1AgAdpjGLW8Xw==' --form @.*** --form albumID="hK4BrZx1Jb3ZJO8OZ0NMNLeo" {"id":"v2locTGpD1DePOc01rnW0QfS","album_id":"hK4BrZx1Jb3ZJO8OZ0NMNLeo","altitude":null,"aperture":null,"checksum":"c755f9d5b0261713154657767de4a6ce4c3a7198","created_at":"2024-02-28T16:28:00+01:00","description":null,"focal":null,"img_direction":null,"is_starred":false,"iso":null,"latitude":null,"lens":null,"license":"none","live_photo_checksum":null,"live_photo_content_id":null,"live_photo_url":null,"location":null,"longitude":null,"make":null,"model":null,"original_checksum":"c755f9d5b0261713154657767de4a6ce4c3a7198","shutter":null,"size_variants":{"medium":null,"medium2x":null,"original":null,"small":null,"small2x":null,"thumb":null,"thumb2x":null},"tags":[],"taken_at":null,"taken_at_orig_tz":null,"title":"9277d17c8384510afda0691d7c1e","type":"image/jpeg","updated_at":"2024-02-28T16:28:00+01:00","rights":{"can_edit":true,"can_download":true,"can_access_full_photo":true},"next_photo_id":null,"previous_photo_id":null,"preformatted":{"created_at":"Feb 28, 2024, 4:28:00 PM Europe/Paris","taken_at":null,"date_overlay":"Feb 28, 2024, 4:28:00 PM Europe/Paris","shutter":"","aperture":"","iso":"ISO ","lens":"","duration":"0s","fps":" fps","filesize":"0.00 B","resolution":" x ","latitude":null,"longitude":null,"altitude":"0m","license":"","description":""},"precomputed":{"is_video":false,"is_raw":false,"is_livephoto":false,"is_camera_date":false,"has_exif":false,"has_location":false}}
So the problem occurs ONLY if the user had previously the upload right in order to create an album. But removing him upload privilege won't impede him to continue uploading in albums already existing.
Hope this helps,
Kind regards,
On Tue, Feb 27, 2024 at 9:55 AM Benoît Viguier @.***> wrote:
@agademer https://github.com/agademer
Could you please double check your finding? Especially that:
- users have may_upload=0
- users do not have upload rights to root directory
- users do not have edit rights to shared directory
https://github.com/LycheeOrg/Lychee/blob/57e35039e232fd0ff5aa755ddb3b70a6f4d2002a/app/Http/Requests/Photo/AddPhotoRequest.php#L13-L16
Ensures the Authorization.
https://github.com/LycheeOrg/Lychee/blob/57e35039e232fd0ff5aa755ddb3b70a6f4d2002a/app/Http/Requests/Traits/Authorize/AuthorizeCanEditAlbumTrait.php#L13-L20
This calls the policy:
https://github.com/LycheeOrg/Lychee/blob/57e35039e232fd0ff5aa755ddb3b70a6f4d2002a/app/Policies/AlbumPolicy.php#L223-L236
I don't see any error in the code or I am missing an edge case. Only thing I could think of is that the token would be giving admin perm instead of user perm which would be seriously worrisome.
— Reply to this email directly, view it on GitHub https://github.com/LycheeOrg/Lychee/issues/2302#issuecomment-1966068377, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZ27K7IHHVFKVBGHNZ3KWDYVWNRZAVCNFSM6AAAAABD2XDPO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRWGA3DQMZXG4 . You are receiving this because you were mentioned.Message ID: @.***>
Hope this helps,
A LOT! By creating the album the user get ownership, and as a result uploads rights:
$this->isOwner($user, $album)
Hummmm.