...so allow...either?
What's so hard about checking two headers (Authorization: and Cookie:) for the authtoken?
this post was submitted on 12 Dec 2023
246 points (95.9% liked)
Programmer Humor
32453 readers
594 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
It's a security thing. The HttpOnly cookie can't be stolen using XSS or something like that, while a bearer token must be stored somewhere where javascript can see it.
Then again, cookie auth is vulnerable to CSRF. Pick your poison.
Although CSRF protection just adds a minor inconvenience, while there is never a guarantee your code is XSS vulnerability free.
That's assuming the client wants to make a web app. They may need to connect something else to that API.
It's perfectly normal to be able to cater to more authentication scenarios than "web app logging in directly to the target API and using its cookies".
If they want to make a web app they should use the cookie mechanism but ultimately each client app is responsible for how it secures its access.
Okay.
So make your webpage send the authtoken in a cookie and leave off the Authorization header, and have your third party (presumably native) clients send an Authorization header but not any cookies, and write your server software to check for both.
This seems trivial. What am I missing?
The point of the cookies being HttpOnly is that it makes them completely inaccessible to client side JavaScript, making a whole load of session hijack/XSS attacks impossible.
The request for a bearer token here circumvents this protection because then there's a way for a client to avoid cookies all together, making the API vulnerable again.
Under what circumstance would a web client need to send an Authorization header at all? The browser sends the cookie and the server treats that as equivalent.
Malicious JavaScript in that case could theoretically forge a request using an auth token it acquired some other way by sending it as Authorization: Bearer in addition to the cookie, but 1) this would be extremely easy to defend against (just check for the cookie before you check the Authorization header) and 2) it would still not allow malicious JS code to access the user's auth token which was still stored in an HTTP only cookie, or really do anything that server side code (read: script kiddie scripts) couldn't, apart from sending a request from the web client's IP address.
it makes them completely inaccessible to client side JavaScript
Dude literally said to do this for browser clients, and only support bearer tokens for non browser clients.
Can a non-programmer get some explanation?
HttpOnly cookies can't be read by javascript, so there's no way to set the bearer token in the Authorization header.
You have a very wild fantasy of what a non-programmer is.
Okay, well have you ever used a dinglehopper?
I've smoothed a schleem or two in my time
An API lets different software talk to each other. HttpOnly uses secure tokens (think password) that a server uses to confirm identity.
Bearer tokens also confirm identity but the added security provided by HttpOnly does not allow passing such within the api information.
They asked for ELI5 and you gave them ELI CS undergrad
To be completely fair to the attempt, there is a reason we have decent incomes.
Ok il attempt again, take in mind though i am no expert in this field either.
An api is a system that allows software to talks to eachother. It does this by sending structural packages back and forth that can be read by software.
Such package usually includes a secure identifier to confirm authorized acces ( like a token) as well as a formal request (show me/edit/remove this specific data)
The api receives the data package, and if the authorization is valid executes the request.
The way I understand it (i am no expert on this ) onlyhttp is a way to provide authorization tokens through a browser cookie (you know those right?), meaning only that browser can have access with that token. The client person never sees the token so its pretty secure in the background.
The bearer token is similar to the one in the browser coockie but the client person needs to enter it inside the package for the api. This can happen from any browser or script by anyone who knows the bearer token. Except Apparantly you cant enter such tokens at all if the api is set to onlyhttp.
JavaScript is a language that runs on a user’s computer, when they visit a web page. It is often used for dynamic functionality, ie when you click “like” on a comment… JavaScript running in your web browser will make a request to the server letting it know that you liked the post, then the server will respond with a total number of people who liked it or something.
But, the server needs to know how to authenticate which user liked the comment (so you can’t like it twice etc). There are various authentication mechanisms to do this, with their own trade-offs. Over all, there’s secret information that the browser and the server have to share with each other, and we don’t want that information being accessed by the wrong people.
There’s also a common problem with web apps called “cross site scripting”. Basically somebody might craft a cleverly formatted comment that exploits a bug in the web page and causes the attacker’s code to run. One trivial example might be if every time a person read a comment thread, the attackers code caused that person to “like” a request. A more serious exploit would be one that finds out that secret authentication information I mentioned and shares it with the attacker. They can then pose as the victim user and do anything they want as that person. This would be bad.
So, on to the different approaches and their tradeoffs.
- HttpOnly cookies. Basically when you log in, the server gives your browser a cookie vouching for who you are. Each subsequent request to the server will include this cookie automatically. The browser handles attaching it to the request, and the browser hides it from any JavaScript running on the page. One trade off is that it requires some authentication to happen between the user and the service (ie enter your username and password), to generate the cookie in the first place. This is likely what OP’s customers want to avoid.
- bearer tokens: basically, when JavaScript code makes a request to the server, it can optionally add some tokens in the request headers and use those to authenticate the user. I’m assuming OP’s scenario involves his company providing a service that is used by another company’s web site. They want to log in the user on their system, then forward some info along to OP’s system describing that user. They can’t just set an HttpOnly cookie for his domain, since it would be private to him; so instead they store a magic token in the browser’s local storage or somewhere and send that on every request. The down side is that JavaScript has to be able to read that token, so it enables that malicious user we talked about to steal it if they exploit some other bug.
Anyhow, one common solution here is to set very short expiration dates on those bearer tokens. That way if somebody steals it, they can’t use it for long.
Another strategy is to limit what each token can do. OP needs to make it so you can like a comment using one of those bearer tokens, but more dangerous actions like purchasing things, deleting content, etc, should be guarded by a more secure mechanism. Then the damage is mitigated if the bearer token leaks.
Thanks! This was the best explanation I got, I think.
it's a security style.
the OG "goat" style says the only things that can request the server are those that get their badges from the server (or some place the server trusts) beforehand.
then comes the client that wants to be able to supply their own badges.
Get the token from the cookie instead of the Authorization header