What are authentication options for Phoenix/Absinthe

This flag is enabled for our javascript SPAs, indeed, as the javascript app itself does not need to interact with the cookie. So what you mean in that a mobile app is not able to replicate this behaviour because it has to manage the cookie “manually”, unlinke apps running in browsers, thus it is easier to impersonate the “what” ?

Yes, httponly cookies are for browsers, because they handle them without any intervention from the code the server sends to run on the browser. Any other client would need to mimic the browser, and you have a lot of open source libraries that are able to simulate a browser. At some point in my career I used one professionally to be able to scrape the website of one our clients, with their authorization.

The what is always possible to impersonate more easily in APIs then in web backends that use properly cookies and embed on them encrypted info with some fingerprint of the client where it was sent to. So, when the backend receives the cookie again, it will see if the fingerprint for the request matches the fingerprint encrypted inside the cookie, if it doesn’t then it means the cookie was stolen and is being reused.

What is Browser Fingerprinting?

Initially developed for security purposes, browser fingerprinting (also known as device fingerprinting) is a tracking technique capable of identifying individual users based on their browser and device settings. In order for websites to display correctly, your browser makes certain information available about your device, including your screen resolution, operating system, location, and language settings. These details essentially make up the ridges of your digital fingerprint.

You can do light-way browser fingerprint only in the server side or you can go more advanced and use some client side libraries:

2 Likes

Thank you :slight_smile:

1 Like

If I understand you correctly, there is really no stopping a determined and authorized user from using the web API in unexpected way. Cookie can be reused, headers can be sniffed, you really can’t trust that the API calls are from your own applications, be it JAMStack or native.

On a related note, I just did something like that. I need to read some textbook I purchased through McGraw Hill, however the shitty website insist me to read the book through their online reader. So I hit F12, save the cookie, wrote a simple script and scraped the whole book down completely. I consider this fair use.

Had McGraw Hill wised up and used LiveView to stream the book content through web socket to their javascript reader it will be a lot harder though.

4 Likes

No, you can’t, but you can have a moderated degree of confidence for web and mobile apps when several security mechanisms are employed in the server and in the app. Shameless plug to my work product were you can have a very high degree of confidence in mobile apps about what is doing the request, unfortunately we add not time yet to devise a solution for web apps.

If the cookie had an encrypted fingerprint embedded on it you would have an harder time in spoofing the requests.

That’s why I recommend to use LiveView in the top of this thread :wink:

1 Like

Fingerprinting is nice; but I think the right thing is not to trust incoming calls to be from your app and validate everything rigorously, and maybe do some rate limiting to cut down the abuse.

Luckily, they are too cheap for that. Their books are all hosted on and served directly from S3 buckets.

2 Likes

Fingerprinting is exactly for not trusting in the incoming request.

But yes I agree that the most you can check in a request the better. For example when I was an API developer I was very strict with the format of the request, I would reject it if it was malformed, aka not done as it is expected by the specs for that request, like having more or less parameter/fields/arguments then what is expected.

But spoofing a genuine request is easy, you just need to see how the app does them and then replicate it. I am doing in this exact moment several MitM attacks against mobile apps to reverse engineer their APIs and make a Proof of Concept how the the API can be impersonate with request from a normal script that will look exactly as the ones done by the mobile app. Tools like mitmproxy or Burp allow you to capture the request and replay it as many time as you want, and you can even edit them.

Rate limiting is easy to bypass, very easy. Cloudflare makes it trivial to bypass, because they tell in the headers what is the rate limit and how you are in relation to it, but they are not the only ones doing it. Developer convenience over security.

Plus sometimes you just need a call to abuse and make damage or extract what you want.

1 Like

I am not disagreeing with you; my point was: Does the user have a right to make use of the API in unexpected ways? In my lame example I believe I have a right to download the book I’ve already purchased.

From the service provider’s perspective they also have a right to defend against abuse. Here I would define abuse as malicious or excessive accesses, not just accesses from something other than the one single application published by the service provider. If a hacker can impersonate the official client and speak valid requests, using legally obtained credential, not exceeding the rate limit posted by the service provider, I don’t see it as unethical.

If the service provider cut corners and put part of their business logic on the client side without double checking it on the server side, it is their problem if they suffer.

1 Like

Even ethical hacker have been presented to court because of doing so.

Don’t play this game because you can get in trouble. All depends on the company and the laws in that country.