Improper Authorization in saleor/saleor

Valid

Reported on

Jan 3rd 2022


Title

GraphQL traversal due to missing permission checks

Description

orders and customers fields allow to access each other via nodes edges. However, connections don't check user's permissions, which allows, for instance, a staff with just Customers permissions get full information about the order, though direct access is forbidden.

Steps to reproduce

I will use a "Staff without Orders permission" scenario

  1. 1. As an admin create a staff, add this account to a group with just Customers permission.
  2. 2. As a created staff observe that direct access to the orders is not allowed:
{
  "query":"{ orders(first: 10) { edges { node { id } } } }"
}

This POST query to http://localhost:8000/graphql/ returns You do not have permission to perform this action.

  1. 3. Go to a page of any customer with at least one order and note that UI shows Recent orders with just "No. of Order", "Date", "Status" and "Total" fields. However, if you try to see the full information about an order and click on it , you'll get Ooops!... Something's missing, as you don't have enough permissions.
  2. Now run this query and receive full information about all orders:
{
"query":"{ customers(first: 10) { edges { node { firstName, orders(first: 10) { edges { node { id, trackingClientId, voucher { id }, giftCards { id }, discount { amount }, discountName, customerNote, weight { value }, metadata { key, value }, fulfillments { id, status }, lines { id, productName, quantity }, actions, total { gross { amount } }, isPaid } } } } } } }"
}

The most interesting field here is definitely lines, as it completely leaks the order.

Possible remediation

Though some fields on orders must be visible to a staff with only Customers permission to see the brief info about the last orders, an access to such fields as lines should be restricted.

Impact

This vulnerability is capable of leaking customer's private information.

We are processing your report and will contact the saleor team within 24 hours. 5 months ago
We have contacted a member of the saleor team and are waiting to hear back 5 months ago
We have sent a follow up to the saleor team. We will try again in 7 days. 5 months ago
We have sent a second follow up to the saleor team. We will try again in 10 days. 4 months ago
We have sent a third and final follow up to the saleor team. This report is now considered stale. 4 months ago
saleor/saleor maintainer validated this vulnerability 4 months ago
Scaramouche has been awarded the disclosure bounty
The fix bounty is now up for grabs
We have sent a fix follow up to the saleor team. We will try again in 7 days. 4 months ago
We have sent a second fix follow up to the saleor team. We will try again in 10 days. 4 months ago
We have sent a third and final fix follow up to the saleor team. This report is now considered stale. 3 months ago
Marcin Gębala confirmed that a fix has been merged on 521dfd 3 months ago
The fix bounty has been dropped
Scaramouche
3 months ago

Researcher


Greets, hope you are well and will be able to see this comment. Are you not against assigning a CVE as a maintainer? Huntr will do it all automatically with your agreement. Thanks for the reply in advance!

Scaramouche
3 months ago

Researcher


@admin Hey, sorry for the ping, could you please assign a CVE for this one if maintainer doesn't mind it?

Jamie Slome
3 months ago

Admin


Absolutely, we can assign a CVE for this. Let me just check in with the maintainer to confirm 😀

Jamie Slome
3 months ago

Admin


Left a comment for the maintainer on the commit here.

Scaramouche
3 months ago

Researcher


@admin Thanks, Jamie, really appreciate it!

Patryk Zawadzki
3 months ago

Maintainer


Please go ahead with the CVE assignment 😄

Jamie Slome
3 months ago

Admin


Sorted!

Scaramouche
3 months ago

Researcher


Amazing, thank you both, gentlemen😁

to join this conversation