To this day, even though I can easily pay for all those software licenses, I keep the proxy running because it makes it easy to visualize outbound network traffic and block unwanted HTTP requests from all the apps I use.įor example, how do you know that the setting to disable telemetry in that app you just installed actually disables telemetry? Even with a firewall like Little Snitch you can only allow/block domains/hostnames/ports but not individual API endpoints. A couple of years ago, Paddle implemented a newer version of their API (v3) that uses SSL certificates and HTTP signatures to improve the security of their SDK, but I quickly found another way to bypass that protection. I tried to report this “vulnerability” (if we can call it that) to both Paddle and Setapp the same year I discovered them, but they never bothered to reply nor fix the problem. The proxy allowed me to use over 200 apps for free over the years. I built that proxy server years ago and created fake responses for multiple licensing APIs provided by companies like Paddle, Setapp, MacPaw, Devmate, MacRabbit, GitTower, Gumroad, OmniGroup, among several others. Ditto for altering the number of uses of a product in case there is a limit there too. > I guess it would be an interesting experiment to create a proxy that captures any values going out to gumroad's license verification api endpoint and change all server responses to be true instead of false. Why couldn't they have just verified that the entity that owns the license key also owns the ? It feels like Gumroad just chose the fix that minimized work on their end while pushing a lot of work onto their API consumers and those consumers' clients. I obviously don't know about Gumroad's internals, but nothing about the original API semantics seems inherently insecure to me. Given this, Gumroad breaking all their clients with only two weeks' notice over the holidays and offering only a $500 bounty feels pretty disrespectful. Then I checked the Wayback Machine for the documentation at the time the exploit was discovered, and those parameters were documented, so the author was relying on documented, supported behavior.
I checked Gumroad's API documentation and found that the product_ and increment_uses_count parameters weren't documented. That would explain why Gumroad was so cavalier about breaking existing clients who relied on this method. One thing that confused me was that the author talks about using "Good Boy Ninja’s method for talking to Gumroad’s API," which I thought meant that they were relying on undocumented behavior of the API.
0 kommentar(er)
