Agree 100%. At my company, I've deployed the open source version of JSONLint.com internally to prevent any accidental exposure of internal or confidential data.
Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
101–110 of 170 posts
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#102Earlier quoted context omitted.
There are server side JWTs that are never exposed to the users.
I thought the entire point of signing a JWT was because you need to validate it because there is some endpoint that is untrusted and you have to treat the claims as potentially compromised.
JWTs are in end like passwords.
Sure they have a limited duration.
Sure they might not work for all actions.
Sure they don't need a password database on the side of the receiver.
But it's best to treat them like temporary password + some arbitrary metadata.
So no, they don't protect you from corrupted clients, they just limit the damage in what can happen and when it can happen but the corrupt client can still do all kinds of bad things.
Edit: I need a different Android keyboard, this is driving me nuts.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#103What's a good open source JSON viewer GUI (or TUI) with Linux support (with collapsing trees, searching, filtering, diff, etc)? I had these exact same concerns last time I was trying to look for one. I found some online JSON tools and could use them for simple things. But I hated putting the JSON I was working on into some 3rd party website, even if it didn't contain anything sensitiveness. I try to use jq whenever I…
Firefox has a pretty nice viewer that does searching, filtering and node collapsing
JQ will do the filtering / searching if you need anything advanced.
I've never searched for a json diff utility.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#104Earlier quoted context omitted.
worked at a courtroom, most pastebin clones were banned it's a natural worry
And a good one too. I'm currently maintaining https://0bin.net , and because we encrypt everything client side, people feel like they can post anything they want. We get some pretty personnal stuff. They really should not. It's a can of worms. We can get compromised. Bought. Receive a court order (we comply with dmca). Or they could be on the wrong URL (typo squatting, phishing...). Don't trust random online services…
> [...] because we encrypt everything client side, [...]. We get some pretty personnal stuff.
How do you see what people post? Do you see people talking about it, or do you have other means of determining what kind of content gets posted?
Just curious; I'm sure your encryption is on point.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#105Earlier quoted context omitted.
There are server side JWTs that are never exposed to the users.
I thought the entire point of signing a JWT was because you need to validate it because there is some endpoint that is untrusted and you have to treat the claims as potentially compromised.
Yes? And?
I may have a backend service that is both internally and externally exposed, necessitating all requests to it be signed. I may have a backend service that has load limits that need to be fairly adhered to, and to do that I allow users only so many requests per time period. Even without load limits, I may want to know who is calling me, and forcing services to first request a token on behalf of themselves makes it more likely that each service will uniquely identify itself.
Really, if you trust the callers of your API enough to allow unsigned JWTs, you probably should trust them enough to not require anything (because copy/paste mistakes alone mean the data isn't valid, intention aside). If you can think of a reason why not having any identity information at all is problematic, you should probably force a signed JWT. The extra effort is negligible, it reduces potential risk if the use of the service changes and it starts getting 'untrusted' users, and it helps reduce "oops" mistakes upfront.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#106Earlier quoted context omitted.
Sure, but to be sure you’d have to validate it every time, because the site’s content may have changed since your last visit. Do you?
No, you'd just have to validate it when you're inputting something particularly sensitive (and I really do usually look in the network console when I'm doing something like that)
Sounds like a lot more work than using a local solution.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#107But using google, slack, skype, gitlab, bitbucket... is fine to send sensitive data?
I work at a place that takes this all very seriously. No. Google search is available but monitored, skype/gitlab/bitbucket/etc are all blocked. Code formatting tools are blocked to the extent possible and people are instructed not to use them. Folks that slip up and get caught are usually written up the first time, after that they are terminated. The only way to legitimately use tools like these from work are if they…
Do you work in a field that warrants this kind of stringent requirements or is the security team overzealous? Do these kind of rules extend to using third party libraries etc?
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#108Earlier quoted context omitted.
It is rather common practice to encrypt the JWT that is presented to the browser which uses it as an opaque value. Pasting a decrypted token on a public site is then definitely a form of information disclosure. Whether it is exploitable or not is a different question.
I did not know that. What would be the point of encrypting the JWT? Allowing the client to see the claim should not really be a concern.
You can put claims (and other metadata) in their which you don't want the client to see.
Like you might not want to expose how exactly your internal permission system works to the client to make it harder to find places what did to bad configuration your JWT can be (ab)used to do thinks it shouldn't be able to. (I.e making security bugs harder to find from the outside).
Or it could expose internal IDs which might have some privacy concerns.
Or the internal IDs are not as security random and you might maybe be able to use that in some way to have a very round about kind of Oracle like attack.
Or this internal data could be used to make social engineering attacks easier.
....
Edit: or you encapsulate another internal only access token in there which the gateway server your website communicates with used to access the resources you are allowed to access and you want to make sure that a attacker who got access to the internal network somehow doesn't has access to any internal tokens without hijacking a service which has such tokens.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#109If you never use production data for anything other than production this stops being a problem. You can put all the dev and staging JWTs you want in to jwt.io at no risk if those things aren't available to the outside world.
Except, habits some catastrophic failure coming together.
The later one makes you need to access production data even through you don't want to the former one makes you leak it in the hurry to fix that catastrophic failure.
To just name one example.
Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
#110Earlier quoted context omitted.
Some attacks exploit vulnerabilities in dev infrastructure. Exposed dev JWT token may enable such an attack.
This is precisely why my comment makes it clear that dev shouldn't be available to the outside world.
"making things not available to the outside world"
Has been proven repeatedly to not reliable work.
And security model must assume a attacker somehow got access to the VPN it whatever you use for isolation.
If not it's not a reliable security model.