Skip to content

security: Unsafe payment creation via API and frontend#2441

Merged
jhawthorn merged 3 commits into
solidusio:masterfrom
jhawthorn:payment_method_security
Dec 12, 2017
Merged

security: Unsafe payment creation via API and frontend#2441
jhawthorn merged 3 commits into
solidusio:masterfrom
jhawthorn:payment_method_security

Conversation

@jhawthorn

Copy link
Copy Markdown
Contributor

See https://groups.google.com/forum/#!topic/solidus-security/oU2K7WJ5H5E

This has already been merged to our v1.0 through v2.4 branches

Versions Affected:  All version of Solidus
                    All version of Spree
Not affected:       NONE
Fixed Versions:     2.4.1, 2.3.1, 2.2.2, 2.1.1, 2.0.3, 1.4.2, 1.3.2,
                    1.2.3, 1.1.4, 1.0.7


Impact
------
Using various endpoints from the API and frontend, a malicious user could
craft a request to create payments using payment methods they shouldn't
have access to.

This may include:
* Payment methods with available_to_users=false (called display_on before
  Solidus 2.1)
* Soft-deleted payment methods
* Payment methods intended only for certain stores
  (a Solidus 1.1+ feature)
* Specifying no payment method (results in payment_method being nil)

Additionally, if a malicious user can obtain an API key, they may be able
to use the Api::Orders#create endpoint to create a completed payment
without going through the proper auth/capture process.

All users of should upgrade to a fixed version as soon as possible.

Releases
--------
The fixed releases are available on rubygems and on github.

In the fixed releases RecordNotFound is raised if a payment method is
not permitted for users.

The Api::Orders#create endpoint, when used by a non-admin, now takes the
same arguments as Api::Orders#update. It no longer allows creating
completed payments.

If you have any questions or concerns please don't hesitate to bring it
up in the Solidus Slack, or get in contact with me (@jhawthorn) or one of
the other Solidus core team members.

Workarounds
-----------

If upgrading to a fixed release isn't feasible, we've prepared a
workaround which can be installed as an initializer.

https://gist.github.com/jhawthorn/fca20fdb096e377ef030cf9f7bb3c63d

John Hawthorn added 2 commits December 11, 2017 13:41
Any user with an API key has access to the Api::Orders#create endpoint.
This exposed some functionality from Importer::Order.import that should
not be exposed to regular users.

This commit changes Api::Order#create to only use Importer::Order.import
on requests from admin users. For users without the :admin permission on
orders, it will use OrderUpdateAttributes, and take the same parameters
as the Api::Order#update endpoint.
Previously a malicious user could craft a request to use payment methods
that were not intended to be available. This includes:
* Payment methods with available_to_users=false (called display_on
  before Solidus 2.1)
* Soft-deleted payment methods
* Payment methods intended only for certain stores (a Solidus 1.1+
  feature)
* Specifying no payment method (results in payment_method being nil)

This has been mitigated by validating the payment method specified by
the user, and raising RecordNotFound if the payment method shouldn't be
accessible.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra blank line detected.

@jhawthorn jhawthorn changed the title Unsafe payment creation via API and frontend security: Unsafe payment creation via API and frontend Dec 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants