Shulou(Shulou.com)06/01 Report--

How to use Webhook to bypass payment requests, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Words written in the front

In order to gain an in-depth understanding of the security vulnerabilities in the vulnerability reward program, we often need to look for features that are invisible to users. Payment Webhook is a typical example, and payment service providers such as Stripe or Braintree use this technology to inform the website of the details of the user's order. Importantly, the user does not interact with these Webhook nodes at all, and all communication is done between the payment provider and the server. This means that many vulnerabilities Hunter may never think of testing Webhook functionality, which will miss many potentially high-risk vulnerabilities.

Loophole discovery

When I was testing a website that offered a monthly subscription service, I happened to get the development documentation of the site's internal API. One of the nodes caught my attention, and this node (/ api/webhooks/stripe) could receive PUT requests, and based on my previous experience in security testing with payment providers, I thought that if I could send a fake request to this node and make the website think that I had completed the payment.

I first sent an empty JSON request, and then the server returned an error message. After analyzing the Stripe format used by the site's Webhook, I sent a JSON request containing the following content (body):

{"payment": {"status": "success", "provider": "stripe"}, "id": "."

At this point, the response message returned by the server displays a status of "successful":

{"id": "...", "amount": 1, "status": "success", "provider": "stripe"}

In this way, my account authorization was successful and showed that I had successfully paid for the subscription service. This makes me wonder: how many websites still have such loopholes? How can payment service providers prevent this loophole?

Solution

In fact, payment providers have the ability to prevent such vulnerabilities, so I am surprised that these nodes are not protected accordingly. The implementation of Braintree is correct: the user must parse the incoming Webhook data through the Braintree code, which automatically verifies the validity of the request and extracts the JSON body. In this way, the Webhook node is very secure and will not be deceived by the attacker's bogus requests.

Stripe, the payment service provider used by the site, cannot guarantee "foolproof" in the face of Webhook security problems. While Stripe does mention verifying Webhook's signature, it's just a security recommendation, and they don't emphasize how important it is to the overall security of Webhook security. In addition, the code sample given in the API document does not contain any Webhook signature authentication, but parses the JSON request directly.

Webhook is unsafe by default, which is tricky. When developing integrated payment services, users tend to adopt the least "resistance" implementation approach, so this means that many websites do not verify the signature of the input request.

Recurly, another subscription payment service provider, uses HTTP basic authentication to share a key between servers. Now someone may ask again, isn't it troublesome to verify the shared key? In addition, Recurly provides a list of IP addresses, and only Webhook requests from this list of IP addresses are considered valid. But this is far from enough. For example, an attacker can create a separate Recurly account and then send a valid but malicious Webhook request, which can also cause security problems.

Vulnerability clue

When testing Webhook vulnerabilities related to payments, we can first analyze the websites that provide monthly subscription services, which is a very effective clue, because the vast majority of payment service providers do not have enough effective security against Webhook.

Here are several ways to find Webhook nodes:

1. Search for JavaScript files related to "Webhook" or "payment". Many payment websites may directly expose internal nodes.

two。 Search the target organization's GitHub code base or related documents for relevant references to Webhook

3. Most Webhook nodes may have similar data formats, so we can try to visit different API nodes to find Webhook nodes, such as / api/stripe/webhook, / api/payments/webhook, or / api/stripeWebhook.

There is no doubt that if the payment site wants to detect any suspicious web behavior, then verifying the payment Webhook request is absolutely the default. Although some payment providers will provide users with ways to prevent such attacks, this still requires the joint efforts of providers and customers.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.