API Security Checklist for developers(github.com)
github.com
API Security Checklist for developers
https://github.com/shieldfy/API-Security-Checklist
70 comments
Most web frameworks I'm familiarized with have a concept of middleware, where you can perform any authentication checks before yielding.
Having read a bit into the topic, I'd +1 avoiding JWT. Getting authentication "right" is difficult. I think most applications should default to using stateful authentication. By the time you actually need stateless authentication "to scale", you'll hopefully have enough experts on-board to help you understand the tradeoffs.
Having read a bit into the topic, I'd +1 avoiding JWT. Getting authentication "right" is difficult. I think most applications should default to using stateful authentication. By the time you actually need stateless authentication "to scale", you'll hopefully have enough experts on-board to help you understand the tradeoffs.
Yeah, in my experience a lack of centralized authorization checks is one of the most sinister issues in typical API construction. And I've seen pretty wonky reasons (relatively speaking) for not wanting it ("it would take a lot of refactoring", or "that presents a single point of failure").
If you don't set up centralized auth checks and instead prescribe !!!CONSTANT VIGILANCE!!!, you're just setting yourself up for an auth bug in a hastily submitted pull request at 4 pm on a Friday afternoon, when someone is lethargic and ready to head out for the weekend. The code is going to get committed, then pushed to production after three people write a quick "LGTM!" Three months later a bug bounty is going to come in with a snazzy report for you (hopefully).
The better thing to do is 1) abstract all authorization checks to a central source of authority and 2) require the presence of this inheritance for tests to pass before deployment.
If you don't set up centralized auth checks and instead prescribe !!!CONSTANT VIGILANCE!!!, you're just setting yourself up for an auth bug in a hastily submitted pull request at 4 pm on a Friday afternoon, when someone is lethargic and ready to head out for the weekend. The code is going to get committed, then pushed to production after three people write a quick "LGTM!" Three months later a bug bounty is going to come in with a snazzy report for you (hopefully).
The better thing to do is 1) abstract all authorization checks to a central source of authority and 2) require the presence of this inheritance for tests to pass before deployment.
have the handlers of all endpoints inherit from a base class that performs the check automatically
I disagree. Much better to have a single endpoint which does nothing except validate opaque requests and passes them upstream. No good ever comes from having crypto code mixed up with non-crypto code.
I disagree. Much better to have a single endpoint which does nothing except validate opaque requests and passes them upstream. No good ever comes from having crypto code mixed up with non-crypto code.
I'm not talking about crypto --- really, it was an offhand comment about what real advice about structuring code for security looks like, compared to "validate inputs so you don't have XSS" --- and whatever you're proposing is probably something I'd agree with.
Do you have any further info on why you so strongly recommend against JWT? My MO has been to know and understand the standard, what it provides (e.g. signed assertions a la SAML, albeit easier on the eyes) and what it does not (e.g. encrypted body without adding your own JWE), and to use it accordingly.
This is probably the first I've heard from someone I know is more than just some random HN commenter that JWT is not recommended.
This is probably the first I've heard from someone I know is more than just some random HN commenter that JWT is not recommended.
Some links I found:
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo...
https://mailarchive.ietf.org/arch/msg/unbearable/QoybOl0cciD...
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
In a nutshell with my comments:
Benefits
- Easier to (horizontally) scale: that's true. My previous company shut down a few servers thanks to JWT
- If it has a vulnerability, just update to patch it ... instead of fixing your customized algorithm. It's way better, but you need to use the most popular / battle-tested / maintained library for your language and keep track of its CVEs as any another dependency.
Drawbacks
- Not revocable, but you can 1) make it short lived, 2) create a blacklist check in a key/store database or 3) tie another verification to it with the cost of a database call (https://dadario.com.br/revoking-json-web-tokens/). Regarding the article (part 2), when it says what would happen if your server is down .. seriously, it's way easier to anything but a key/store value of a few items to get down first than any other server
- Developers think that the data is encrypted, when it's only base64'd
- Libraries have to make up for the flawed specification that allows the JWT to carry both the algorithm used and the signature
- Libraries are not as battle-tested as cookies
- Libraries may support flawed algorithms (e.g., RSA with PKCS #1v1.5 padding - for JWE), thus you have to know what you're picking
Some points that I agree or partly agree with the author of such article:
- Easier to use: that's nonsense. I'd say that it's the same thing as implementing a cookie mechanism
- Works better on mobile: that's nonsense
- Works for users that block cookies: you can very well put your session token in the LocalStorage and achieve the same effect
- They take up more space: true
- Built-in expiration functionality: that's nonsense. Cookies have it as well.
- By storing it on LocalStorage you avoid CSRF, but you can do that with session tokens already. Regarding the links above that 'by using JavaScript you open up your application to a lot more risk' .. well, to build a page without JavaScript in 2017 is madness. Let's get back to reply with full HTML content again? Lol. Backing to the point, it's not really a benefit of JWT, but commonly related to tokens that you store on LocalStorage, even though they're subject to XSS, as opposed to cookies w/ HttpOnly flag -- and then we go again to discuss how this flag only passes a 'false sense of security' because if you have a XSS, you already have lots of trouble.
Topics that are complicated:
- Saying 'more secure' or 'less secure' depends on how it is implemented. You could have secure JWT implementations and flawed stateful session implementations.
- Data goes stale: depends on what data you put on it! Just putting the user's UUID is not something that is likely to change, except when the user is removed;
Benefits
- Easier to (horizontally) scale: that's true. My previous company shut down a few servers thanks to JWT
- If it has a vulnerability, just update to patch it ... instead of fixing your customized algorithm. It's way better, but you need to use the most popular / battle-tested / maintained library for your language and keep track of its CVEs as any another dependency.
Drawbacks
- Not revocable, but you can 1) make it short lived, 2) create a blacklist check in a key/store database or 3) tie another verification to it with the cost of a database call (https://dadario.com.br/revoking-json-web-tokens/). Regarding the article (part 2), when it says what would happen if your server is down .. seriously, it's way easier to anything but a key/store value of a few items to get down first than any other server
- Developers think that the data is encrypted, when it's only base64'd
- Libraries have to make up for the flawed specification that allows the JWT to carry both the algorithm used and the signature
- Libraries are not as battle-tested as cookies
- Libraries may support flawed algorithms (e.g., RSA with PKCS #1v1.5 padding - for JWE), thus you have to know what you're picking
Some points that I agree or partly agree with the author of such article:
- Easier to use: that's nonsense. I'd say that it's the same thing as implementing a cookie mechanism
- Works better on mobile: that's nonsense
- Works for users that block cookies: you can very well put your session token in the LocalStorage and achieve the same effect
- They take up more space: true
- Built-in expiration functionality: that's nonsense. Cookies have it as well.
- By storing it on LocalStorage you avoid CSRF, but you can do that with session tokens already. Regarding the links above that 'by using JavaScript you open up your application to a lot more risk' .. well, to build a page without JavaScript in 2017 is madness. Let's get back to reply with full HTML content again? Lol. Backing to the point, it's not really a benefit of JWT, but commonly related to tokens that you store on LocalStorage, even though they're subject to XSS, as opposed to cookies w/ HttpOnly flag -- and then we go again to discuss how this flag only passes a 'false sense of security' because if you have a XSS, you already have lots of trouble.
Topics that are complicated:
- Saying 'more secure' or 'less secure' depends on how it is implemented. You could have secure JWT implementations and flawed stateful session implementations.
- Data goes stale: depends on what data you put on it! Just putting the user's UUID is not something that is likely to change, except when the user is removed;
I generally agree with your conclusions, but I don't understand why you compare JWT to cookies. These technologies are completely orthogonal. JWT can be stored in cookies and whatever you put in traditional cookies can generally be stored in local storage.
The right comparison is JWT vs. session tokens stored in DB or KVS. Or in case you already decided against storing sessions in DB, you should compare JWT against rolling your own crypto.
With this approach, cookies should be thought more as a mechanism for storing and presenting session data, not as security mechanism. You can't rely on cookie expiry date for instance - if someone steals that cookie, they can completely disregard expiry, HttpOnly, Secure, Domain or whatever other property you stick to the cookie.
Cookie expiration is basically worthless. Whether you're storing your sessions in a database or cryptographically signing them you should always add your own expiration mechanism. I've seen too many systems that blindly relied on cookie expiration for security, only to realize the implications later.
The right comparison is JWT vs. session tokens stored in DB or KVS. Or in case you already decided against storing sessions in DB, you should compare JWT against rolling your own crypto.
With this approach, cookies should be thought more as a mechanism for storing and presenting session data, not as security mechanism. You can't rely on cookie expiry date for instance - if someone steals that cookie, they can completely disregard expiry, HttpOnly, Secure, Domain or whatever other property you stick to the cookie.
Cookie expiration is basically worthless. Whether you're storing your sessions in a database or cryptographically signing them you should always add your own expiration mechanism. I've seen too many systems that blindly relied on cookie expiration for security, only to realize the implications later.
> I generally agree with your conclusions, but I don't understand why you compare JWT to cookies.
You're right when it comes to terms. Allow me to clarify what I meant by Cookies and JWT in the explanation above:
I was referring to Cookies as the default storage for stateful session mechanism used by web frameworks that makes use of a random session ID with high entropy. It's the no-brainer approach to implement stateful sessions and (usually) doesn't require changes on the client-side but require you to store all sessions in a file/redis/db. And expiration that you pointed now makes sense, because I'm talking about the expiration of the session on the server-side, although Cookie has this mechanism which does little to prevent session hijacking.
JWT, on ther other hand, usually is stored on LocalStorage and requires some development changes on the JavaScript framework because it needs to read from LocalStorage, capture the JWT and send it in every request. With a web framework's default approach (that I used the term Cookies), it's seamless.
You're right when it comes to terms. Allow me to clarify what I meant by Cookies and JWT in the explanation above:
I was referring to Cookies as the default storage for stateful session mechanism used by web frameworks that makes use of a random session ID with high entropy. It's the no-brainer approach to implement stateful sessions and (usually) doesn't require changes on the client-side but require you to store all sessions in a file/redis/db. And expiration that you pointed now makes sense, because I'm talking about the expiration of the session on the server-side, although Cookie has this mechanism which does little to prevent session hijacking.
JWT, on ther other hand, usually is stored on LocalStorage and requires some development changes on the JavaScript framework because it needs to read from LocalStorage, capture the JWT and send it in every request. With a web framework's default approach (that I used the term Cookies), it's seamless.
> Developers think that the data is encrypted, when it's only base64'd
Doesn't it depend on the specific implementation? For example I have been using github.com/dgrijalva/jwt-go package to build a token, add claims and sign it along with github.com/auth0/go-jwt-middleware to validate the requests. The JWT in that case is signed and encoded as a string using the secret.
Doesn't it depend on the specific implementation? For example I have been using github.com/dgrijalva/jwt-go package to build a token, add claims and sign it along with github.com/auth0/go-jwt-middleware to validate the requests. The JWT in that case is signed and encoded as a string using the secret.
jwt-go says right in the readme that it is not encrypted:
>> It's important to know that JWT does not provide encryption, which means anyone who has access to the token can read its contents. <<
>> It's important to know that JWT does not provide encryption, which means anyone who has access to the token can read its contents. <<
Okay, let's say that 3rd party read the user id which my app keeps in a JWT token. What would they do with it?
> Works for users that block cookies: you can very well put your session token in the LocalStorage and achieve the same effect
AFAIK LocalStorage is disabled when cookies are disabled.
AFAIK LocalStorage is disabled when cookies are disabled.
Here's something longer I wrote about JWT:
https://news.ycombinator.com/item?id=14292223
I really ought to just suck it up and write a blog post.
https://news.ycombinator.com/item?id=14292223
I really ought to just suck it up and write a blog post.
Is most of this specific to JWT and its format? Meaning if my token consists of a stateless "id" and an authenticated hash of it appended, and I have it passed as an HTTP auth bearer header, am I good? Assumptions being my authed hash algo is acceptable, my "id" value embeds a creation time that I expire in a few hours, and nothing can be gleaned from the "id" itself.
> I really ought to just suck it up and write a blog post.
Yes please!
Yes please!
>> Finally: don't use JWT. JWT terrifies me, and it terrifies all the crypto engineers I know. As a security standard, it is a series of own-goals foreseeable even 10 years ago based on the history of crypto standard vulnerabilities. Almost every application I've seen that uses JWT would be better off with simple bearer tokens.
This is really surprising to me. I use Play! framework and the whole play framework community suggests to use JWT for authentications as Play! doesn't support sessions out of the box. Is it just JWT itself is bad or how developers use it is bad? Just a noob question.
This is really surprising to me. I use Play! framework and the whole play framework community suggests to use JWT for authentications as Play! doesn't support sessions out of the box. Is it just JWT itself is bad or how developers use it is bad? Just a noob question.
It is a standard for crypto created by non-crypto people. It is bad, don't use it. Using it correctly is harder than rolling your own stupid simple bearer token, which is very rare for standards. Using stateful authentication is even simpler. Using django or something like that is even simpler.
>JWT might be the one case in all of practical computing where you might be better off rolling your own crypto token standard than adopting the existing standard.
This isn't the first time I heard this claim, but I've also read that vulnerabilities were related to libraries and implementations, not the standard itself. Is it true?
To me, I don't see the benefit of passing meaningful information via JWT, and it might even pose a risk.
>simple bearer tokens
I guess you mean cryptographically secure random byte strings?
This isn't the first time I heard this claim, but I've also read that vulnerabilities were related to libraries and implementations, not the standard itself. Is it true?
To me, I don't see the benefit of passing meaningful information via JWT, and it might even pose a risk.
>simple bearer tokens
I guess you mean cryptographically secure random byte strings?
What are some more trusted alternatives to JWT for signed tokens with claims / expiry?
Depending on your situation, you've got only 3 reliable options, as far as I'm concerned.
1. You could just generate random session IDs (UUIDs or 128-bit base64 strings) and store them in your database or in a persistent cache like Redis. Most OAuth middleware offer this functionality already. Drawback: Scalability - but in most cases you don't need it.
2. Use an alternative format that doesn't provide all the features of JWT, but provides better security: Fernet or Macaroons. https://github.com/fernet/spec/blob/master/Spec.md https://github.com/rescrv/libmacaroons
You'll need to implement claim validation and expiry validation all by yourself.
Fernet is probably better for you if you don't need the killer feature of macaroon (stacking caveats). The payload can be anything, but if you really like JWT you can always stick a JSON-encoded JWT payload inside the token and use your favourite JWT library to verify it.
If you want to support use cases like delegation or claims verified by third parties, Macaroons are worth a look.
Drawbacks: - Limited programming language support. - No built in mechanism to support key rotation (like JWT header kid). You'll need to roll your own.
3. Roll your own crypto. This not as bad as it sounds, since you could (and should!) use the NaCl/libosodium primitives. The only difference between NaCl secretbox and Fernet is that the latter includes a timestamp - which you can easily add on your own.
1. You could just generate random session IDs (UUIDs or 128-bit base64 strings) and store them in your database or in a persistent cache like Redis. Most OAuth middleware offer this functionality already. Drawback: Scalability - but in most cases you don't need it.
2. Use an alternative format that doesn't provide all the features of JWT, but provides better security: Fernet or Macaroons. https://github.com/fernet/spec/blob/master/Spec.md https://github.com/rescrv/libmacaroons
You'll need to implement claim validation and expiry validation all by yourself.
Fernet is probably better for you if you don't need the killer feature of macaroon (stacking caveats). The payload can be anything, but if you really like JWT you can always stick a JSON-encoded JWT payload inside the token and use your favourite JWT library to verify it.
If you want to support use cases like delegation or claims verified by third parties, Macaroons are worth a look.
Drawbacks: - Limited programming language support. - No built in mechanism to support key rotation (like JWT header kid). You'll need to roll your own.
3. Roll your own crypto. This not as bad as it sounds, since you could (and should!) use the NaCl/libosodium primitives. The only difference between NaCl secretbox and Fernet is that the latter includes a timestamp - which you can easily add on your own.
> - No built in mechanism to support key rotation (like JWT header kid). You'll need to roll your own.
That's not true. Macaroons have identifier field. See the Readme doc in libmacaroons [0]. Direct quote:
> The public portion tells us which secret we used to create the macaroon, but doesn't give anyone else a clue as to the contents of the secret.
[0]: https://github.com/rescrv/libmacaroons/blob/master/README
I'd say that the biggest difference between JWT and Macaroons is that Macaroons are on one hand simpler than JWT (only one algorithm allowed) and on the other a lot more flexible. Caveats are just byte arrays and it's up to the user to decide how to verify them. The official docs present simple case of string predicates (user = Alice) but it'd be also possible to use something similar to Bitcoin Script. Of course this flexibility has a price: if using third party caveats (another unique aspect of Macaroons) all services must use the same caveat language.
That's not true. Macaroons have identifier field. See the Readme doc in libmacaroons [0]. Direct quote:
> The public portion tells us which secret we used to create the macaroon, but doesn't give anyone else a clue as to the contents of the secret.
[0]: https://github.com/rescrv/libmacaroons/blob/master/README
I'd say that the biggest difference between JWT and Macaroons is that Macaroons are on one hand simpler than JWT (only one algorithm allowed) and on the other a lot more flexible. Caveats are just byte arrays and it's up to the user to decide how to verify them. The official docs present simple case of string predicates (user = Alice) but it'd be also possible to use something similar to Bitcoin Script. Of course this flexibility has a price: if using third party caveats (another unique aspect of Macaroons) all services must use the same caveat language.
Interesting, I didn't realize that.
The JWT ecosystem (or JOSE ecosystem to be exact) offers a lot of other machinery beyond just having a key ID for key rotation like JWK and OpenID Connect discovery, but there's nothing preventing you from using the same discovery mechanisms with Macaroons.
I'm using these mechanisms already with a variety of other non-JWT implementations.
Oh yes, exactly, JWT has a stronger ecosystem. Sometimes I feel like they are aimed at different problems, JWT to replace opaque tokens with stateless ones (but if you want instant revocation it becomes a problem) and Macaroons for delegated access. JWTs can be easily used to replace session tokens while Macaroons work best when you've got your entire architecture designed with them in mind.
Just recently I was thinking that it would be nice if my DNS provider used Macaroons for API access. If I want to limit Let's Encrypt's client's access to just _acme-challenge.example.com I could take the Macaroon from DNS provider that has complete access and limit it to "_acme-challenge" and TXT records only. What is nice with Macaroons is that you can derive sub-tokens offline, just from the master token. Wrapping JWTs in JWTs, while possible, leaves one with the base64-in-base64 matrioshka problem.
Just recently I was thinking that it would be nice if my DNS provider used Macaroons for API access. If I want to limit Let's Encrypt's client's access to just _acme-challenge.example.com I could take the Macaroon from DNS provider that has complete access and limit it to "_acme-challenge" and TXT records only. What is nice with Macaroons is that you can derive sub-tokens offline, just from the master token. Wrapping JWTs in JWTs, while possible, leaves one with the base64-in-base64 matrioshka problem.
I think Kerberos [0] is the industry standard.
[0] https://en.wikipedia.org/wiki/Kerberos_%28protocol%29
[0] https://en.wikipedia.org/wiki/Kerberos_%28protocol%29
no JWT but "simple bearer token" is not a good advice as I have no idea how to implement that. I'd rather use JWT with restricted crypto (make sure "noop" is not allowed).
In tptacek's other post from two months ago:
> For almost every use I've seen in the real world, JWT is drastic overkill; often it's just an gussied-up means of expressing a trivial bearer token, the kind that could be expressed securely with virtually no risk of implementation flaws simply by hexifying 20 bytes of urandom.
This is then to say "generate a random number, give it to the client, accept that same random number in the future as evidence of the client's authorization". A familiar form of that would be a session cookie whose content was generated by a cryptographic random number generator. The session cookie is an index into a database that indicates the properties and authorities that that particular session does or does not have.
Now I guess the reason people may like JWT is that they don't have to have a database or store of tokens that they're issued and what authority each one connotes, because they can verify the signatures on the JWT and then believe the payload. And one system can issue authorizations that another system can consume without direct communication between the two. I think these believing-the-payload properties are a part of what Thomas doesn't like.
> For almost every use I've seen in the real world, JWT is drastic overkill; often it's just an gussied-up means of expressing a trivial bearer token, the kind that could be expressed securely with virtually no risk of implementation flaws simply by hexifying 20 bytes of urandom.
This is then to say "generate a random number, give it to the client, accept that same random number in the future as evidence of the client's authorization". A familiar form of that would be a session cookie whose content was generated by a cryptographic random number generator. The session cookie is an index into a database that indicates the properties and authorities that that particular session does or does not have.
Now I guess the reason people may like JWT is that they don't have to have a database or store of tokens that they're issued and what authority each one connotes, because they can verify the signatures on the JWT and then believe the payload. And one system can issue authorizations that another system can consume without direct communication between the two. I think these believing-the-payload properties are a part of what Thomas doesn't like.
On rare occasions there might be a good reason for stateless auth. I think stateless auth is overused (it's especially funny to see it used on sites that are otherwise dependent on HTTP cookies), but not intrinsically evil.
But there can be no reasonable argument for a standard conceived of in the last 10 years to allow users to deploy something for which the payload chooses the cryptographic interpretation of the payload. No application anyone on HN is deploying needs user-selectable cryptography. This is never a feature; it's only ever an invitation to horrible vulnerabilities.
But there can be no reasonable argument for a standard conceived of in the last 10 years to allow users to deploy something for which the payload chooses the cryptographic interpretation of the payload. No application anyone on HN is deploying needs user-selectable cryptography. This is never a feature; it's only ever an invitation to horrible vulnerabilities.
> But there can be no reasonable argument for a standard conceived of in the last 10 years to allow users to deploy something for which the payload chooses the cryptographic interpretation of the payload. No application anyone on HN is deploying needs user-selectable cryptography. This is never a feature; it's only ever an invitation to horrible vulnerabilities.
When I read about JWT's I saw the alg fields to a simple indicator of the algorithm being used on the JWT, not that it is allowing the token to select whatever algorithm it wants for the server to run. Granted, this is a semantic difference, but if you treat the alg field as such it then becomes the servers choice of what algorithms to support. The practical solution is simple: Only support one algorithm, and if the token's alg does not match what the server is expecting, do not authorize. Sure this is a weakness in the JWT spec, but the real underlying issue is dev's not understanding the security mechanisms and libraries they are deploying. That is bad news no matter what tech they are using.
When I read about JWT's I saw the alg fields to a simple indicator of the algorithm being used on the JWT, not that it is allowing the token to select whatever algorithm it wants for the server to run. Granted, this is a semantic difference, but if you treat the alg field as such it then becomes the servers choice of what algorithms to support. The practical solution is simple: Only support one algorithm, and if the token's alg does not match what the server is expecting, do not authorize. Sure this is a weakness in the JWT spec, but the real underlying issue is dev's not understanding the security mechanisms and libraries they are deploying. That is bad news no matter what tech they are using.
If you leave the `alg` field out, the exact same scenario occurs: someone sends you a token, and you fail to authorize using the server-side configured algorithm. Having this field adds nothing of real value.
The only thing having an `alg` field does is make the standard trivially misusable by well-intentioned developers.
The only thing having an `alg` field does is make the standard trivially misusable by well-intentioned developers.
Well, practically every JWT library developer thought otherwise, because they'll all verify the JWT based on the alg field, which means every careful implementation of JWT must validate "alg", but I'm afraid there are too many developers out there who don't.
Realistically speaking, it looks like JWT won the popularity race and IETF unfortunately won't deprecate the algorithm header anytime soon, so we should at least try to campaign library maintainers to have the algorithm field ignored by default and use the algorithm specified by client code instead.
Realistically speaking, it looks like JWT won the popularity race and IETF unfortunately won't deprecate the algorithm header anytime soon, so we should at least try to campaign library maintainers to have the algorithm field ignored by default and use the algorithm specified by client code instead.
I feel about this the way I imagine an internal medicine doctor feels when a patient starts earnestly discussing colloidal silver.
> make sure "noop" is not allowed
Security by blacklisting is a bad idea. You don't need to look far - it's JWT libraries that could be fooled into accepting public key as a symmetric key [0] so even if you fix the noop bug you are still vulnerable. That's what's wrong with JWT - you always have one more issue than you think.
[0]: https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
Security by blacklisting is a bad idea. You don't need to look far - it's JWT libraries that could be fooled into accepting public key as a symmetric key [0] so even if you fix the noop bug you are still vulnerable. That's what's wrong with JWT - you always have one more issue than you think.
[0]: https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
> Don't use Basic Auth
Why not? If it's an API meant to be consumed by a server I don't see what the problem is.
Why not? If it's an API meant to be consumed by a server I don't see what the problem is.
Was going to ask the same question. Assuming https of course, what is the matter with basic auth?
Generally you should try to tokenize your auth system. Passing "keys to the kingdom" directly to the API for each API call can cause a lot of grief in the event of a breach of one of your nodes. If you're using a tokenized and access-level controlled system with something like OAuth, the breach is bad - but it's temporary without having to run around trying to change creds over.
I think that the main issue is the client must send what is essentially the plaintext password on every request, meaning the client also must store the password. It might be short-lived, might not, but is a security risk to keep the password around on the client side for the duration of the session.
I like to use Basic Auth for API's with clientid/secret pairs. So it's not the user password and individual credentials can be revoked while it's much simpler to implement than full OAuth
If I'm not mistaken Twilio does this too for their API
If I'm not mistaken Twilio does this too for their API
It's fragile: leaks the password when TLS is having a bad day, when the server's compromised—say, on more than 1% of days in the last five years.
It's fragile to request smuggling attacks too, because the password is not entangled with the request, just next to it.
We have lots of mechanisms that do better than both of those: client certs beat the first, and HMAC of the request and key headers with a secret beat both.
It's fragile to request smuggling attacks too, because the password is not entangled with the request, just next to it.
We have lots of mechanisms that do better than both of those: client certs beat the first, and HMAC of the request and key headers with a secret beat both.
I don't bookmark many links but here's [1] a good one for all to keep on a similar topic.
It's a SO article on security for web transactions.
[1] https://stackoverflow.com/questions/549/the-definitive-guide...
It's a SO article on security for web transactions.
[1] https://stackoverflow.com/questions/549/the-definitive-guide...
No amount of checklisting and best practices substitutes for hiring someone smart to break your stuff and tell you how they did it. You can check all the boxes and still get pwned.
You can learn and run automated tools for 6 months and end up knowing 1/3rd of what a great pentester knows.
If you want to know you can resist an attack from an adversary, you need an adversary. If you want to know that you followed best practices so as to achieve CYA when something bad happens, that's a different story.
But honestly the security picture is so depressing. Most people are saved only because they don't have an active or competent adversary. The defender must get 1,000 things right, the attacker only needs you to mess up one thing.
And then, even when the defender gets everything right, a user inside the organization clicks a bad PDF and now your API is taking fully authenticated requests from an attacker. Good luck with that.
Security, what a situation.
You can learn and run automated tools for 6 months and end up knowing 1/3rd of what a great pentester knows.
If you want to know you can resist an attack from an adversary, you need an adversary. If you want to know that you followed best practices so as to achieve CYA when something bad happens, that's a different story.
But honestly the security picture is so depressing. Most people are saved only because they don't have an active or competent adversary. The defender must get 1,000 things right, the attacker only needs you to mess up one thing.
And then, even when the defender gets everything right, a user inside the organization clicks a bad PDF and now your API is taking fully authenticated requests from an attacker. Good luck with that.
Security, what a situation.
> No amount of checklisting and best practices substitutes for hiring someone smart to break your stuff and tell you how they did it.
Which is not to say that it doesn't help.
As a pen tester, I'd much rather they tick all the boxes and save money because now I don't have to report all the low hanging fruit (which is fun the first two times you pwn an application but gets boring quickly -- I'd rather have something interesting to test).
Which is not to say that it doesn't help.
As a pen tester, I'd much rather they tick all the boxes and save money because now I don't have to report all the low hanging fruit (which is fun the first two times you pwn an application but gets boring quickly -- I'd rather have something interesting to test).
If the main input to the security of your application comes from having a penetration test, you're going to have a bad time.
There's no mystery to what an app. security tester does really, and getting the basics of app. sec right early in the development lifecycle is probably the most important piece of having a good solid app.
Sure get a tester in at the end to poke it and find edge cases and weird security bugs, but for a new app. getting someone in the early phases of development to provide security architecture advice is probably more important.
There's no mystery to what an app. security tester does really, and getting the basics of app. sec right early in the development lifecycle is probably the most important piece of having a good solid app.
Sure get a tester in at the end to poke it and find edge cases and weird security bugs, but for a new app. getting someone in the early phases of development to provide security architecture advice is probably more important.
What are peoples thoughts on using TLS client certificates for authentication?
Given we're talking about APIs, we avoid many of the UX problems, but it feels like taking on a different set of problems than just using a bearer token. It does provide baked in solutions for things like revocation and expiry though.
Given we're talking about APIs, we avoid many of the UX problems, but it feels like taking on a different set of problems than just using a bearer token. It does provide baked in solutions for things like revocation and expiry though.
It's a pain in the arse for everyone involved. Adding another management layer to the stack isn't my idea of maintainability, and I'm inclined to agree with you on your point that it introduces a new set of problems.
TLS client certs are nice if everyone knows what they're doing, but in a lot of orgs that just isn't the case.
TLS client certs are nice if everyone knows what they're doing, but in a lot of orgs that just isn't the case.
I'm not that familiar with TLS client certificates so I'm not qualified to say, but if you consider other developers as your users, then the UX problem remains.
Web developers in general are more familiar with other forms of authentication so unless you have a strong reason for picking TLS client certificates I would suggest picking something else.
In other words: I would be more likely to try out an API if it was based on Basic Authentication. ;-)
Web developers in general are more familiar with other forms of authentication so unless you have a strong reason for picking TLS client certificates I would suggest picking something else.
In other words: I would be more likely to try out an API if it was based on Basic Authentication. ;-)
Seriously problematic for browsers - see Garrett Wollman's article linked below, and follow the link to his previous "defence" which has a good roundup of problems https://blog.bimajority.org/2016/05/02/an-update-on-the-http...
Client certificates don't work in http2. If you use due diligence and store them in secure hardware then they could be a lot more secure than bearer tokens (cannot be exported) but I guess most people would just store a PKCS#12 file on disk and that'd make them as secure as a bearer token.
On the other hand some companies use them even for browser clients for passwordless authentication.
On the other hand some companies use them even for browser clients for passwordless authentication.
> Always try to exchange for code not tokens (don't allow response_type=token).
There is absolutely nothing wrong with the implicit flow if the application (including in-browser ones) is requesting the token for itself (and not for some server or any third party). In case of a standalone app that would be just an extra meaningless step.
There is a slight difference in presence/absence of refresh token, though, but that would make implicit flow more secure (because, if standard-compliant, there won't be any refresh tokens at all), not less.
In case of a browser, the token would end up in the browser's history, but given that a) if browser itself is compromised game is already over, and b) that it's not possible for other parties to access the history (besides some guesswork that doesn't work for tokens), paired with a fact that c) such tokens should be short-lived, it's not a big deal.
> User own resource id should be avoided. Use /me/orders instead of /user/654321/orders
This has absolutely nothing to do with security. TBH, I don't see any issue if /me/ would be a redirect or an alias for /user/654321/. That may make perfect sense if a conceptual purity is desirable ("for each object there is one and only one URL - the canonical one"), with its pros and cons.
> Don't use auto increment id's use UUID instead.
Similarly, that barely has anything to do with security. One just has to understand that sequential IDs are trivially enumerable (and an obvious consequence of this fact - that API consumers would be able to enumerate all the resources or, at the very least, estimate their cardinality).
And as for the security - it should've probably said UUIDv4, because if one accidentally uses e.g. UUIDv1 their IDs would lose the unguessability.
There is absolutely nothing wrong with the implicit flow if the application (including in-browser ones) is requesting the token for itself (and not for some server or any third party). In case of a standalone app that would be just an extra meaningless step.
There is a slight difference in presence/absence of refresh token, though, but that would make implicit flow more secure (because, if standard-compliant, there won't be any refresh tokens at all), not less.
In case of a browser, the token would end up in the browser's history, but given that a) if browser itself is compromised game is already over, and b) that it's not possible for other parties to access the history (besides some guesswork that doesn't work for tokens), paired with a fact that c) such tokens should be short-lived, it's not a big deal.
> User own resource id should be avoided. Use /me/orders instead of /user/654321/orders
This has absolutely nothing to do with security. TBH, I don't see any issue if /me/ would be a redirect or an alias for /user/654321/. That may make perfect sense if a conceptual purity is desirable ("for each object there is one and only one URL - the canonical one"), with its pros and cons.
> Don't use auto increment id's use UUID instead.
Similarly, that barely has anything to do with security. One just has to understand that sequential IDs are trivially enumerable (and an obvious consequence of this fact - that API consumers would be able to enumerate all the resources or, at the very least, estimate their cardinality).
And as for the security - it should've probably said UUIDv4, because if one accidentally uses e.g. UUIDv1 their IDs would lose the unguessability.
> User own resource id should be avoided. Use /me/orders instead of /user/654321/orders
Can somebody explain this?
Can somebody explain this?
I believe its because its a more explicit indication that the route MUST have access control logic etc baked in.
It also conveniently makes a CSRF vulnerability easier to exploit. And, as soon as there's more than one of something (e.g. say a family/corp account with an administrator that can do something for different users), it falls apart.
I think this is an interesting security consideration but I would prefer implicit identity for the following reasons:
If the API is meant to be consumed by machines then it's unlikely that CSRF would be a threat.
CSRF controls are more likely to be provided out of the box by a framework. Authorization controls are often tightly coupled to the business domain and are less likely to be usable out of the box.
If you need to support a scenario where administrators perform tasks on behalf of other users, then I would suggest evaluating whether a sudo-like mechanism could be viable solution.
If the API is meant to be consumed by machines then it's unlikely that CSRF would be a threat.
CSRF controls are more likely to be provided out of the box by a framework. Authorization controls are often tightly coupled to the business domain and are less likely to be usable out of the box.
If you need to support a scenario where administrators perform tasks on behalf of other users, then I would suggest evaluating whether a sudo-like mechanism could be viable solution.
what happens if I type in /user/654322/orders instead of /user/654321/orders? Did I just access someone else's account?
Yes, if you're a supervisor or parent account or something like that.
Preventing flexibility at the URL level rather than performing proper authentication strikes me as a poor decision.
Preventing flexibility at the URL level rather than performing proper authentication strikes me as a poor decision.
I think this is a rather special usecase, this makes sense with inhouse applications where something like this might be common, but probably not something you want on the public api of a shop.
I disagree. What about the support rep, who needs to look at the customer's orders? What if it's a e.g. digital games store, and you want to have kids accounts which can be reviewed by their parents' ? What if you sell to businesses, and you want to let employees purchase stuff without having access to the address and billing info, which is configured by a master account?
You're just tying yourself down for no good reason.
You're just tying yourself down for no good reason.
Generally you’ll just get a 403 response. There’s still authentication taking place, I’d imagine this tip in particular is just to protect from revealing any potentially dangerous identifiers.
By making the owner's userid implicit, you're foreclosing on the possibility of authorization bugs where an endpoint fails to verify that the current user is authorized to see orders from user 654321.
Basically, avoid literal (insecure direct object) references to resources where possible so you have fewer areas where a server can goof authorization checks. Preempt the possibility of a server expecting any direct reference and structure your API to only load resources from a backend, not the user's input.
This goes hand in hand with abstracting all authorization checks to a single gateway/middleware layer that each call inherits, rather than a spot check per call or a group of checks for different groups of calls.
(This is in addition to what 'lvh and 'tptacek have said already.)
This goes hand in hand with abstracting all authorization checks to a single gateway/middleware layer that each call inherits, rather than a spot check per call or a group of checks for different groups of calls.
(This is in addition to what 'lvh and 'tptacek have said already.)
Let's say you are the user 654321. You see that you can access your private page at /user/654321. You then try to access /user/112233: if the developer forgot the authorization controls, or inserted bugs, you can access other users' informations
So I'm developing a simple SAAS with little to no private info and where failure isn't critical.
For initial release I build a page that uses html buttons and basic javascript to GET pages, passes a key as a parameter, and uses web.py on the backend.
It seems like it would be a lot of work to implement the suggestions here. At what point does it make sense?
For initial release I build a page that uses html buttons and basic javascript to GET pages, passes a key as a parameter, and uses web.py on the backend.
It seems like it would be a lot of work to implement the suggestions here. At what point does it make sense?
The guy forgets the main thing here: length, type and range checks!
I'm finding issues like API servers hanging/crashing due to overly long or malformed headers all the time when I work on front-end projects.
Programming in a language with automatic range and type checks does not mean that you can forego vigilance even with the most mundane overflow scenarios: lots of stuff is being handled outside of the "safe" realm or by outside libraries.
I'm finding issues like API servers hanging/crashing due to overly long or malformed headers all the time when I work on front-end projects.
Programming in a language with automatic range and type checks does not mean that you can forego vigilance even with the most mundane overflow scenarios: lots of stuff is being handled outside of the "safe" realm or by outside libraries.
I've filed a pull request to include a CSP technique I've started adding on some of my apis:
https://github.com/shieldfy/API-Security-Checklist/pull/5
https://github.com/shieldfy/API-Security-Checklist/pull/5
Further, the list succumbs to the cardinal sin of software security advice: "validate input so you don't have X, Y, and Z vulnerabilities". Simply describing X, Y, and Z vulnerabilities provides the same level of advice for developers (that is to say: not much). What developers really need is advice about how to structure their programs to foreclose on the possibility of having those bugs. For instance: rather than sprinkling authentication checks on every endpoint, have the handlers of all endpoints inherit from a base class that performs the check automatically. Stuff like that.
Finally: don't use JWT. JWT terrifies me, and it terrifies all the crypto engineers I know. As a security standard, it is a series of own-goals foreseeable even 10 years ago based on the history of crypto standard vulnerabilities. Almost every application I've seen that uses JWT would be better off with simple bearer tokens.
JWT might be the one case in all of practical computing where you might be better off rolling your own crypto token standard than adopting the existing standard.