There seems to be a lot of gaps in this writeup, but to the best of my understanding the bug a straight forward XSS but only in the MCS Webview giving access to the window.GalaxyStore
object to download or open any application from the store.
Getting the page displayed does not require any tricky but can be accessed through a deeplink like: samsungapps://MCSLaunch?action=each_event&url={{url}}
. Pointing the URL at the vulnerable https://us.mcsvc.samsung.com/mcp25/devops/redirect.html
page.
This page when displayed inside the MCS Webview will craft a number of intent://
links that will reflect parameters from the current page into the generated URLs. This is done without any escaping leading to XSS.
For more fun, once XSS is achieved it is possible to access the window.GalaxyStore
object which has two methods downloadApp
and openApp
which can be used to download and open applications.
Facebook’s SMS Captcha page would as you might expect, display a captcha, the user fills it out, and then it makes a POST request to the next page including the anti-CSRF token. The problem being that the next location was determined by the next
url parameter which was entirely attacker controlled, and could be pointed to sensitive GraphQL endpoints.
Straight forward IDOR, but the vulnerable feature is somewhat hidden. Within Google Data Studio you have an option to create a template and then perhaps add that template to the report, it is the process of persisting that template in a report that is vulnerable to IDOR.
When you go to add the new/temporary template to a report a request to /persistTempReport
will be made with a sourceReportId
. This identifer does not have any authorization checks and can point to any report.
Improper handling of multi-line header values, specifically in handling the Transfer-Encoding
header Node would parse the value up to the first new-line and not include the remaining content.
Transfer-Encoding: chunked
, identity
The value of the header should be chunked , identity
, with identity
indicating the body is 0
bytes. However Node will parse it as chunked
so may incorrectly parse a body to the request.