Making WordPress.org

#7010 closed defect (bug) (wontfix)

Unauthorized Swag Ordering via Guest User Checkout

Reported by: ankit-k-gupta's profile Ankit K Gupta Owned by:
Milestone: Priority: high
Component: Swag Store (mercantile.wordpress.org) Keywords: dev-feedback
Cc:

Description

Description:

Contributors of WP received an email informing them about the opportunity to order swag up to $25 by utilizing the coupon code ‘ThanksFor20’ here on this site https://mercantile.wordpress.org/.
However, it has been observed that this coupon allows guest users to check out without requiring them to log in to the store. Consequently, if a person possesses the email ID of another contributor, they can easily order swag on their behalf and have it shipped to their own address while utilizing the coupon code.

https://i.imgur.com/92IpIm4.jpg

Watch this screencast for detailed info: https://screenpal.com/watch/c0hTi4VAmZH

Steps to Reproduce:

  1. Obtain the email ID of a contributor from a WordPress.org profile/Linkedin/Slack/Github profile and any other source.
  2. Visit the WP store website.
  3. Add swag items to the cart.
  4. Proceed to checkout as a guest user.
  5. Enter the email ID of the contributor as the recipient ( as captured from step-1)
  6. Apply the coupon code ‘ThanksFor20’.
  7. Complete the checkout process and add your own address.
  8. Verify that the order is successfully placed without requiring a login.

Expected Behavior:

The coupon code ‘ThanksFor20’ should be restricted to authenticated users only, preventing unauthorized individuals from ordering swag on behalf of other contributors.

Actual Behavior:

The coupon code ‘ThanksFor20’ allows guest users to complete the checkout process without logging in/validating user, enabling them to order swag items for someone else and utilize the coupon code themselves.

Reproducibility:

Consistently reproducible.

Impact:

This bug allows unauthorized individuals to take advantage of the coupon code ‘ThanksFor20’ by ordering swag for other contributors without their consent. It could result in increased expenses and potential misuse of the promotion.
As a result, deserving contributors will not be able to order their swag as the 'ThanksFor20' coupon is valid for single use.

Note: I obtained explicit consent from the person before utilizing her email ID for the purpose of this order and demonstrating the issue in the above video.

Change History (3)

#1 @slash1andy
14 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

Thanks for taking the time to report this.

Basically, I would not consider this an exploit or a bug, but a function of having a coupon code that requires email validation. The only way to pull this off is to know the coupon code (sent out via private email)and then the email of a core contributor.

This is more social engineering than anything, in my opinion.

There's also limitations on order amounts, so by using that coupon code with that email, it cannot be reproduced, as only 1 order is allowed per email.

There is not a way to prevent this without explicitly forbidding guest checkout (not something we are going to do), and also auto creating accounts for all emails that received the coupon.

#2 @5um17
14 months ago

  • Keywords dev-feedback added; 2nd-opinion removed
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Hi @slash1andy

I hate to disagree with this is not social engineering but an authentication flaw.

The only way to pull this off is to know the coupon code (sent out via private email)and then the email of a core contributor.

As far as I understand the coupon code is common for all and it just ThanksFor20 @ankit-k-gupta could you confirm what is your?

Now we know the coupon code we just need an email and email address doesn't need social hacking, It is easily available in our address book also on user's public profile.

IMHO, either coupon code should be unique for each user or there should be email authentication when placing the order to prevent this.

I hope this makes sense and you will reconsider this ticket.

#3 @dd32
14 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Hi @5um17,

While I understand your concerns here, this isn't going to be changed at present as part of the email campaign, thus the wontfix rather than invalid.

This may change for future similar uses though.

Note: See TracTickets for help on using tickets.