
Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators - pcr910303
https://www.jvt.me/posts/2020/09/01/against-online-tooling/
======
seaerkin
I agree with the author. Is it highly unlikely, sure, but it's important to
create awareness of the risks associated. At the end of the day, you are
sending potentially sensitive data to a third party.

Good security posture is all about building habits and I personally don't want
myself or my team being comfortable with the idea of pasting code or JSON
config files into a third party system.

If any of these online tools are sending your data to the server, don't use
them. You don't know what happens with your data once you send it and
accidents happen even if the service has your best interests in mind.

For the ones that are client side, such as JSON-to-go. You can save the client
side code locally, set a bookmark, and use your local version instead.

~~~
evanreichard
I keep a copy of CyberChef [0] locally. Can do the majority of the data
manipulation I need. Does JWT Decoding / Signing / Verification and JSON
Validation / Pretty as well. You can experiment with insignificant data here
[1].

[0] [https://github.com/gchq/CyberChef](https://github.com/gchq/CyberChef)

[1] [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/)

~~~
vongomben
Wow this looks really useful

------
paultopia
For those criticizing the author for 'fantasy' security problems, it seems
relevant to emphasize that they work at a bank---their threat model is
probably rather more vigorous than most.

~~~
thieving_magpie
> they work at a bank---their threat model is probably rather more vigorous
> than most

Until one day when you work with ACH files and start having existential dread
about the american payroll system.

~~~
dathinab
Yes it's sometimes rediculus with what regulated businesses can get away with
as long as it's either historical or had been certified to be secure at some
point in time.

~~~
quesera
I don't think this is a good argument.

The ACH network is orders of magnitude more secure than credit cards. And ACH
transfers have simple recourse, when errors or fraud occur.

------
jaywalk
I think the author is over dramatic. Like when he says this:

>I've been burned a number of times by folks putting a Non-Production JWT or
an Open Banking Sandbox certificate into jwt.io.

He hasn't been "burned" by that at all. No security breach occured because of
that. He does have somewhat of a point, but he goes off into fantasy land
trying to justify it.

~~~
ljm
> these are sensitive in of themselves, as they have implementation details
> for our services, and as mentioned, certain things could be used outside of
> Capital One.

I imagine these JWTs will find their way into a frontend application in prod
(because what else would they be for?), at which point any actual user of
theirs could pull the token down and get access to these implementation
details. The only thing sensitive about a JWT should be its ability to
authenticate a user; encoding _actually sensitive_ data inside that token,
such as anything you want kept secret, would be a huge mistake.

~~~
notimetorelax
There are server side JWTs that are never exposed to the users.

~~~
qppo
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.

~~~
lostcolony
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.

------
onion2k
If 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.

~~~
wardnath
Agreed. This pretty much applies with any data & tool. If the data is extra
sensitive, make extra sure the tool you are using is secure. If your data is
for dev purposes only, the tool doesn't have to be validated as thoroughly.

~~~
beardedwizard
Wow really? Lateral movement is very real, your mindset is dangerous.

~~~
wardnath
That is a good point to make. If the development data can lead to exfiltration
of higher privacy data then I would define it as "more sensitive" and take
that into consideration, this particularly applies to config information
required for authentication. I understand your perspective however, it is
important to take lateral movement into account.

------
arcatan
For inspecting JWT tokens, I like the step command-line tool:
[https://smallstep.com/cli/](https://smallstep.com/cli/)

    
    
      pbpaste | step crypto jwt inspect --insecure
    

It can be combined further with jq if you need to dig out a specific field.
(pbpaste is a macOS cli command that prints the contents of the clipboard)

~~~
jamietanna
This is interesting! I've blogged about an OpenSSL-only version in
[https://www.jvt.me/posts/2019/06/13/pretty-printing-jwt-
open...](https://www.jvt.me/posts/2019/06/13/pretty-printing-jwt-openssl/)
which optionally needs Python, so you can do it with basically 0 new
dependencies, if that's what you want :)

------
shadowgovt
For JWTs, I agree with this stance, since they are security credentials and
therefore basically all of them are sensitive information.

I don't discourage online tooling in general. It's a risk/benefit trade-off---
No, you shouldn't paste sensitive information into websites run by other
people in general, but for non-sensive information where you don't care if the
online tool is logging it or not, go for it. There are significant advantages
to not having to roll your own for every single thing you need to do.

Carried to its extreme conclusion, "Don't use online tooling" implies "Don't
read jvt.me," because who knows what that website is doing while vending you
blog posts? clearly, you should roll your own solution by maintaining your own
private collection of knowledge that you never share with anyone else. ;)

~~~
tester34
>For JWTs, I agree with this stance, since they are security credentials and
therefore basically all of them are sensitive information.

As long as it's prod env and your expiration time is somewhat reasonable, then
I don't think it is sensitive at all unless you're storing an actual sensitive
informations in them.

~~~
gruez
So you're just hoping that there isn't a bad guy on the other side trying to
use the credentials in real time? Seems like a bad assumption to make,
especially for a site that's specifically made for pasting in JWTs.

~~~
recursive
No. No one's hoping anything. It's more like a realization that even if
there's a bad guy, they're only going to be able to pwn your dev environment,
which has no valuable data in it, and can be replaced with a script.

------
hatch_q
But using google, slack, skype, gitlab, bitbucket... is fine to send sensitive
data?

~~~
jordache
i hate how when I'm copying + pasting a url to a test or internal environment,
to the browser address bar - I may have a typo in there, or an extra space.
Bam! The URL just became a google search

~~~
MaxBarraclough
So I'm not the only one.

It's even worse than that though, enter 'myintranetsite' and hit return, and
you end up on a Google search page. Instead you have to enter
'[http://myintranetsite'](http://myintranetsite')

~~~
mschuster91
Type myintranetsite/ instead, this is faster than [http://](http://) in front.

~~~
londons_explore
As you type, the name is still being sent to Google for search suggestions
with every keystroke until the final "/".

If you prefix with "[http://"](http://"), no requests are made to Google
(except "h", "ht", "htt", "http", and "http:")

~~~
reificator
> _If you prefix with "[http://"](http://"), no requests are made to Google
> (except "h", "ht", "htt", "http", and "http:")_

This seems surprising to me. Can you back up this claim?

~~~
andinus
If you have search suggestions enabled then "http:" will be sent. Firefox
disables them in Private Browsing mode for this reason.

\- [https://support.mozilla.org/en-US/kb/search-suggestions-
fire...](https://support.mozilla.org/en-US/kb/search-suggestions-firefox)

~~~
MaxBarraclough
> If you have search suggestions enabled then "http:" will be sent

What's the point of sending those characters?

~~~
antsar
Search Suggestions. You typed "h", maybe you want to search for "harpoons".
"ht" might suggest "htaccess". "http" might be a search for "httpie". etc.

~~~
MaxBarraclough
Yes, of course :-P

------
meddlepal
I agree with the premise though its easy to validate if these tools are
sending data to a remote dest with the network activity developer tool in any
of the major browsers.

~~~
ryukafalz
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?

~~~
shawnz
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)

~~~
nostoc
Sounds like a lot more work than using a local solution.

~~~
shawnz
Personally I don't feel that's true if you include the significantly increased
amount of research necessary to even _find_ a decent local solution most of
the time. Web apps are much more discoverable.

------
david_draco
More important than security issues, you are building a chain of dependencies
that likely is undesirable. The service goes away, and you have to change your
workflow -- less likely to happen with local software. Also less likely to
happen with open source software than commercial software.

What if countries similarly tracked their dependencies on other countries and
foreign companies, rather than just their budget? There are some trade-offs
where you want to avoid dependency even if it is more costly. Recent scandals
with constructs of selling water sources and public infrastructure to lease it
back cheaper, comes to mind.

------
lordnacho
I don't agree. I think online tools are great for quick-and-easy testing, and
doesn't require any privacy issues. Mostly the benefit is ergonomics: I don't
need to set up a bunch of stuff to do the thing I want, someone has done it
because they had the exact same need.

The kind of thing I typically do with them:

\- Diff two files

\- Check brackets. JSON, jwt, that kind of thing

\- Run code snippets in a fiddle site

\- Regex

\- Unit converters, HEX/decimal calculators

\- Color pickers

In all cases, I'm using the tool before anything sensitive has been created.
Why shouldn't I use a regex tool to figure out the exact string before I copy-
paste it into my code? Or if I want to see if some particular little algorithm
works, why not play around with it online, when an editor is already there and
ready?

In any case, whatever I discover is part of a larger whole that was not set up
in a way where this subproblem was going to be easy to test for, eg my
particular use case may not make it easy to put a bunch of tests strings
through regex.

~~~
ahefner
I was boggling at how this could be tolerably efficient for someone, but I
think I see it. My development workflow is terminal-centric, so copying out of
the terminal to paste into a browser is extremely painful, whereas running
'diff', 'json_verify', etc. on local files or typing snippets into
python/node/etc. from the shell is almost free. I suppose though if I were
spending my day in VS Code or any kind of GUI IDE or similar, and if my
workflow isn't optimized to pop open a unix shell with a keystroke for quick
throwaway commands, it would be a lot easier just to C-a C-c alt-tab C-v from
my GUI editor into a browser.

~~~
bradstewart
Pretty much. I use a mix of terminal and VS Code for development. Quite often
I either don't have tools like json_verify, a hex/rgb code converter, jwt
pretty printer, etc installed; or I can't remember what/how they're called. At
which point its usually easier to slap it in a web search.

------
frou_dh
Witnessing developers copy-paste code from their editor into textareas on
webpages to do formatting/linting/etc induces the same kind of internal
cringe-factor as when witnessing general computer users use the mouse for
absolutely everything and knowing zero keyboard shortcuts.

Or to put it in contemporary terms:

Trigger Warning: Unoptimized Workflows

~~~
suff
Cringe is one thing, but exposing data gets you walked out the front door. The
two are worlds apart in terms of severity.

------
erulabs
I do enjoy this perspective from someone who says "I have no access to
production data". Typically that is used as an excuse to not practice any
security whatsoever, rather than as a side-note on a security heads-up!

I go back and forth on this all the time - easier access to production means
faster development, but requires more discipline. Being able to reproduce
production issues without production data takes a lot of engineering - which
can be hard to justify when you're a tiny shop - when I was DevOps for 100
engineers it was certainly a much simpler time justification...

------
jdmichal
Completely unsurprised that this is coming from someone working at a bank. I
saw a lot of the same working at another very large bank. Banks are extremely
risk adverse in certain areas, such as using externally-hosted tooling.
Certain areas of my employer, including where I worked, couldn't even use
public cloud services. (And my area was additionally PCI, meaning that we also
couldn't use our _internal_ cloud services...) It's to the point where they
would rather risk the project or products success, over whatever their
perceived risk using external hosting.

~~~
YetAnotherNick
And yet I find that their security model is just backwards. They have myriads
of rules like you can't email outside org and when people need to send
something to others, they inadvertently find solutions which are less secure
than email. My friend interned at a top bank as software developer and he got
the response due to access requirement they can't give him any project.

------
colinclerk
[http://jsonprettyprint.net/](http://jsonprettyprint.net/) ranks high for
"json pretty print" in Google and is an example where data hits their server.

~~~
wingi
Server-side-rending is sure not privat.

More on
[http://jsonprettyprint.net/privacy](http://jsonprettyprint.net/privacy) \-
well formated.

~~~
YetAnotherNick
Pretty print privacy.

------
nickjj
Funny, I was just thinking about this the other day when I wanted to convert a
bunch of JSON into YAML.

There were a number of online tools that did the conversion. The first thing I
did was test them with dummy data to make sure it was fully client side and
worked offline.

Can't be too safe if you're planning to run these tools on data that is
protected by contract or NDA. Even if it's not, I still wouldn't want a third
party site saving and potentially doing something with the data.

------
darth_avocado
I mean, as a dev for last 15 years, my rule of thumb is "don't trust the
internet". Don't copy paste your code onto the internet, and don't copy paste
internet's code into yours.

Also, another rule that helps, what's in production, stays in production.
Don't copy paste things onto your machine, don't write things down in your
notebook and don't even try sending it over the public internet.

------
pinteresting
If you could sandbox part of the screen to say this thing is standalone and
cannot perform any networking abilities and is cut off from everything else on
the page that would be great.

The browser could recognise that tag and you get a safe space for people to
copy/paste/interact with online web tools.

I'm pretty sure you can do this with WASM right now, but the browser doesn't
inform the user that this is a safe space.

~~~
hundchenkatze
It's not exactly what you're describing and may be overkill, but you can
definitely accomplish this with Qubes OS.

[https://www.qubes-os.org/intro/](https://www.qubes-os.org/intro/)

------
demarq
It sounded like the OP had some solid proof but eventually it boils down to
"I'm suspicious".

It's a valid opinion just not an objective one

~~~
beardedwizard
If there was proof it would be a different thread, but "don't paste
credentials into websites you don't control" seems like great advice for life.

~~~
Spivak
And if the app really is completely local to your browser like it says then
make a copy and run it locally or on an internal web server for your whole
team. Boom. No more "malicious updates" problem.

------
zemnmez
While this article goes into the technical detail of how an attack from jwt.io
to a developer might work, I think it most importantly leaves out what the
potential threat actor in this threat model is, and what they hope to achieve.
The actor would need to compromise jwt.io and use it to specifically target
some developer (since the data is likely in localStorage).

This kind of attack is, I think very unlikely to happen because the costs vs
potential rewards / risk are so poorly balanced. A jwt.io compromise is pretty
hard, and you might get nothing from it!

That said, I agree with the idea that within the web security model, people
should not be pasting security-critical data into sites! But I think this is
more an issue of people having access to these security-critical keys than the
sites themselves. After all, they could have downloaded a malicious binary, or
their laptop could be stolen. People should not be put in a position where
they have security critical keys on their clipboard.

------
jupp0r
I agree with the author. I still think he makes some invalid points.

1\. "Although Non-Production, these are sensitive in of themselves, as they
have implementation details for our services, and as mentioned, certain things
could be used outside of Capital One."

Implementation details of your services shouldn't be a part of your security.
Otherwise, you are relying on security by obscurity. I agree that you
shouldn't necessarily share them publicly (if just for the sake of preventing
people from relying on them as a public API), but declaring them as a security
breach is far fetched (I'm assuming they are not actually relevant to your
security).

2\. Many of the points that the author attributes to 3rd party services
actually also apply to local tools, if they are downloaded by something like
npm.

* it's not clear whether the code you are running is identical to the open source version of the code that you think you are running

* you have to trust a third party you have no relationship with

------
brian_herman__
I use these shell scripts for generating passwords. This uses bash.

    
    
      gen-pass(){
        gpg2 --armor --gen-random 1 15
      }
      gen-pass2(){
        openssl rand -base64 15
      }
      gen-pass3(){
        strings -n 1 < /dev/urandom | tr -d '[:space:]' | head -c15
        echo ""
      }
    

edit:formatting

------
recov
I've made internal tools for the exact thing, jwt inspection , which was a
nice exercise and guarantees privacy. For things like JSON, using your
editor/cli would be much faster. I'm not sure why a lot of developers don't
add these integrations/learn the tools.

~~~
hirako2000
Because many users would rather not learn how to use 12 different cli
commands. Many software dev can't even be bothered to learn how to copy/paste
text content in the terminal or vim that spans longer than the screen.

A Web page makes things simpler, everyone has a browser. I built an internal
web tool, replicated what the ones found on the Internet do, and developers in
my organisation are using it daily.

------
p49k
I think that for identical reasons, browser extensions should be severely
restricted on dev machines to a whitelist. I think it’s crazy how so many
developers install Chrome extensions managed by random anonymous people which
often have broad permissions and which auto-update.

------
margaretdouglas
I am constantly suspicious of all online tools. Every time I see someone paste
a blob of customer data into an open browser tab to format the JSON I cringe;
this is precisely the reason I spent a few hours to learn how to use `jq`
efficiently.

------
djsumdog
What'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 can on the command line, but having good, local,
visual tools (that aren't plugins to web browser or filled with electron
cancer) would be nice.

~~~
nostoc
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.

------
kalium-xyz
Webapps like jwt.io run locally in your browser and you can monitor traffic,
prevent further requests or even run them yourself to make sure of this. This
post is misinformed at best.

~~~
jordache
did you validate that those sites do not batch data input over time and send
them out, much later than your direct user input interactions?

~~~
vimslayer
Open in private window, set to offline in the console's network tab, do your
thing, close the window. At least I'm not aware of a way the app could send or
persist the data when you do that.

------
vscarpenter
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.

------
mpurham
This was a great read and I definitely agree with the author that you have to
be careful about data that you post online. This is a reason why I've created
Polypad ([https://mattebot.co/polypad](https://mattebot.co/polypad))

------
Traster
It's always seemed to me that if someone at Google were to look at the terms
entered into chrome from my company it would probably have a shocking amount
of proprietary information - plans, costs, passwords etc. It's not exactly the
same online tooling that the author is talking about, but anything going into
your browser is probably going somewhere you can't truly trust.

------
m6PeelVLsQ8QawN
Some people at certain lines of work must use computers that cannot connect to
the internet at all. This should not be a surprise to anyone.

------
dahfizz
For me, it's more about workflow than anything. Its much faster to run some
json through `jq` than it is to reach for my mouse, switch to my browser, open
a tab and google for json validator, try to find a decent one, then try to
copy and paste a huge file over.

If you spend all your time in the browser anyway, it might be different for
you.

------
jakear
This is an area where github pages shines. Unless my threat model includes
github colluding with the website to steal secrets (it usually doesn’t), I can
check the source of a tool once and later be able to view only patches, with a
guarantee that the source I see is what’s actually running.

(I work at msft)

------
kazinator
If I made a list of the programs people should not be using online, some dinky
data format validator would probably be among the last priorities on it,
probably somewhere just above an online converter between l/100km and mpg, or
an online egg timer. Pick your battles and all that.

------
pwinnski
I am now motivated to set up local tooling that is as easy to use as online
tooling. I've been nervous at times about pasting data, and usually triple-
check first, but that itself takes time, and one day I might be in such a
hurry I don't take it.

Better to establish good habits now.

~~~
pwinnski
Yesterday, I created a python script to reproduce jwt.io, so thanks for the
motivation!

------
bstar77
Even if JWT.io does everything on the up and up, if that site is compromised
then every single user that pastes their token is as well. If I was a
malicious actor, that's a site I would target first. We should use trusted
local utilities to decode these tokens.

------
jamescodesthing
Someone offline stack overflow for me before I paste half our source into it.

Agree with the author btw, just like the idea of taking it to a really far
fetched conclusion.

------
prophesi
Is there a good resource for finding terminal replacements for online tooling?

~~~
jamietanna
I'm happy to write blog posts for local alternatives to online tooling if you
can share things you'd want

------
samsquire
I use python -mjson.tool to validate JSON. And JQ to query it.

TLDR Don't use online services, you have no idea what they're doing with your
data and if they run the open source version they say they do.

~~~
magicalhippo
Or rather like with most online services, only feed them data you're
comfortable with being shared to everyone.

------
jamietanna
Previous discussion:
[https://news.ycombinator.com/item?id=24342063](https://news.ycombinator.com/item?id=24342063)

------
softveda
I use jwt.ms Validation is done in javascript and as it says "data never
leaves the browser"

------
Gby56
1 - Stop using JWTs would be a better first step, go to
[https://paseto.io](https://paseto.io)

2 - Look at the network tab, see anything leaving your browser, websockets
whatever ? if not, it's probably fine

------
Mc_Big_G
For VIM users:

%!python -m json.tool

------
mattacular
Tldr: security risk

------
amelius
Considering that user agents are far more powerful than servers if you divide
their power by the number of users, and considering that we have WASM now, one
should wonder why these tools even need to run on a server.

