8 ms·
Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators
- meddlepal 6y agoI 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 6y agoSure, 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 6y agoNo, 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)
- gruez 6y agoThe network console isnt going to tell you if the site's exfiltrating data via websocket or webrtc.
- shawnz 6y agoIt actually will (at least for websockets), it's just that websocket messages aren't nicely included in the timeline along with typical requests. You need to find the request that initiated the websocket and go to the details -- it shows the messages there
- scintill76 6y agoPresumably you enter dummy data to validate first. What if it doesn’t send that, but does send the real data?
- shawnz 6y agoThen I'd change the keys in that rare circumstance. What are the chances the attacker will be able to take advantage of the leak before I have a chance to change them, particularly given an attack like this would likely be a blanket attack and not targeted?
- nostoc 6y agoSounds like a lot more work than using a local solution.
- shawnz 6y agoPersonally 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.
- samsquire 6y agoI 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 6y agoOr rather like with most online services, only feed them data you're comfortable with being shared to everyone.
- sumtechguy 6y agoI find these services useful when I first start using a format with test data. Then I usually look for something local for long term use.
- hatch_q 6y agoBut using google, slack, skype, gitlab, bitbucket... is fine to send sensitive data?
- pmontra 6y agoIt is not. In a project I'm working on we encrypt our secrets with git secret before sending them to GitHub. When we want to quickly share unencrypted secrets between us we drop them as files into a server we access over ssh. That should be OK. The gist of it is that if a secret is in clear on a server outside our organization it's not secret anymore. And yet my customer trust their cloud provider (Google) with their data.
- onion2k 6y agoNo, it definitely isn't. Github (and probably others) will show you big scary warning messages if you commit things like AWS keys.
- elliekelly 6y agoWhat about when you commit a file with client data or PII?
- clinta 6y agoHow does that work on the command line? Does it reject your push? Or is this only for people editing on the github website?
- jordache 6y agoi 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
- Liquid_Fire 6y agoOn Firefox you can disable this via an about:config setting (set keyword.enabled to false).
- onion2k 6y agoIf 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 6y agoAgreed. 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.
- thinkloop 6y agoHe addresses this. He mentions leaking implementation details, and possibility for mistakes.
- beardedwizard 6y agoWow really? Lateral movement is very real, your mindset is dangerous.
- wardnath 6y agoThat 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.
- notimetorelax 6y agoSome attacks exploit vulnerabilities in dev infrastructure. Exposed dev JWT token may enable such an attack.
- onion2k 6y agoThis is precisely why my comment makes it clear that dev shouldn't be available to the outside world.
- demarq 6y agoIt 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 6y agoIf 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 6y agoAnd 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.
- quercusa 6y agoNot everything can be proven until it's too late; at some point experience and informed intuition need to be part of the risk evaluation.
- lordnacho 6y agoI 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 6y agoI 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 6y agoPretty 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.
- kalium-xyz 6y agoWebapps 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.
- beardedwizard 6y agoHow will you know if the code changes?
- jordache 6y agodid you validate that those sites do not batch data input over time and send them out, much later than your direct user input interactions?
- adamsea 6y agoIf the app runs locally in the browser, you monitor network connections and whatever else for web sockets, etc, to ensure that no information is passed from your browser to the site beyond the initial http request, then, there never would be any information sent to the site to batch, correct? I think that is correct. Also I agree with previous posters who pointed out that for the common JWT use-case: user authentication in an SPA or website, the JWT is running in users browsers and so should not contain any sensitive information to begin with.
- vimslayer 6y agoOpen 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.
- jamietanna 6y agoNot sure if you fully read the article, but I mention that up until fairly recently, jwt.io was performing some metric collection, which I'm not sure many people were aware of
- arcatan 6y agoFor 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 6y agoThis is interesting! I've blogged about an OpenSSL-only version in https://www.jvt.me/posts/2019/06/13/pretty-printing-jwt-openssl/ https://www.jvt.me/posts/2019/06/13/pretty-printing-jwt-open... which optionally needs Python, so you can do it with basically 0 new dependencies, if that's what you want :)
- deleted 6y ago[deleted]
- shadowgovt 6y agoFor 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 6y ago>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 6y agoSo 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 6y agoNo. 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.
- deleted 6y ago[deleted]
- colinclerk 6y agohttp://jsonprettyprint.net/ http://jsonprettyprint.net/ ranks high for "json pretty print" in Google and is an example where data hits their server.
- wingi 6y agoServer-side-rending is sure not privat. More on http://jsonprettyprint.net/privacy http://jsonprettyprint.net/privacy - well formated.
- YetAnotherNick 6y agoPretty print privacy.
- jaywalk 6y agoI 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 6y ago> 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 6y agoThere are server side JWTs that are never exposed to the users.
- qppo 6y agoI 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.
- dathinab 6y agoJWTs 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.
- jamietanna 6y agoPrevious discussion: https://news.ycombinator.com/item?id=24342063 https://news.ycombinator.com/item?id=24342063
- seaerkin 6y agoI 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.
- dec0dedab0de 6y ago* 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.* I don't think it is highly unlikely. I think it is highly likely that if you make a habit of using these tools one of them will eventually be compromised. Either through a technical hack, financial pressure, purchase by an immoral entity, or a disgruntled employee somewhere along the path. Then again if it's just for testing/learning, and the data isn't really sensitive who cares, use what's easiest. Most of the time the easiest for me is jupyter so I can test how it actually works, and when I'm finished I have working code.
- seaerkin 6y agoThe likelihood of compromise depends on data being sent + chance of said service being malicious, which is why I said highly unlikely. Even if I gave you a JWT or config file, you'd still have to know how and where to use it. Sometimes this can be obvious, sometimes even if you know how, you can't access the where like if the credentials contained access to a db local to only my machine or to a server behind a firewall.
- zzapplezz 6y agoThis topic is much broader than just online JSON tools. There are all kinds of converters, transformers, and linting tools available online for many languages and frameworks that you shouldn't be sending your private code to. I disagree with the author on always running it locally for yourself. If a service is useful enough, you should set it up internally so your team has a sandbox to use it. Spread the knowledge instead of hoarding it. Compiler Explorer is an example here.
- jdmichal 6y agoCompletely 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 6y agoAnd 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.
- Gby56 6y ago1 - 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
- paultopia 6y agoFor 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 6y ago> 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 6y agoYes 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.
- R0b0t1 6y agoThe alternative is oftentimes doing nothing and putting people out of work. You shouldn't proactively punish people for the potential actions of other unrelated people who might choose to break the law.
- quesera 6y agoI 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.
- redbeard0x0a 6y agoWorking with ACH is NACHA a good day, the day you realize all of banking is built on falling dominos.
- quesera 6y agoACH gets a bad rap. The file format is archaic, but not objectively worse than any alternative (modern or contemporary). It helps to think of an ACH file as an expression of a line protocol, with field framing and offsets and some internal checksumming. ACH files are mostly human-readable in their raw form (some simple vim highlighting goes a long way), and that was surely a design goal. It is terse (important for 1960's era data transfer/storage costs) which makes it information-dense, which remains a feature today. As a system, the ACH Network is incredibly reliable and secure. The security is built into the system, not into the file format. Only trusted players are invited to participate, and the threat of removal is much greater than any enticement to deceive. Furthermore, it is a full-recourse system. Errors can be backed out after the fact. File delivery is secured in the usual way. Preshared keys, SSH/SSL, etc. ACH is more secure than your bank/broker website, or any ecommerce transactions. I would like to see encrypted (or at least cryptographically-signed) ACH files, and I wish ACH was used in support of something quicker than a 2x/day (business days only) batch settlement cycle...but that's an interbank/Fed issue.
- brian_herman__ 6y agoI 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
- pinteresting 6y agoIf 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 6y agoIt'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/
- jakear 6y agoThis 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)
- mattacular 6y agoTldr: security risk
- nickjj 6y agoFunny, 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.
- softveda 6y agoI use jwt.ms Validation is done in javascript and as it says "data never leaves the browser"
- frou_dh 6y agoWitnessing 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 6y agoCringe is one thing, but exposing data gets you walked out the front door. The two are worlds apart in terms of severity.
- pwinnski 6y agoI 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 6y agoYesterday, I created a python script to reproduce jwt.io, so thanks for the motivation!
- david_draco 6y agoMore 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.
- dahfizz 6y agoFor 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.
- suff 6y agoSMH The 'author' (who posts their real name and just gave attackers ideas for new user names) told who his client is, and because of the nature of the post, also some of the security technology and languages they use. I have a feeling this 'security' dev won't be on the project much longer.
- p49k 6y agoI 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 6y agoI 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.
- recov 6y agoI'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 6y agoBecause 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.
- zemnmez 6y agoWhile 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.
- djsumdog 6y agoWhat'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 6y agoFirefox 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.
- amelius 6y agoConsidering 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.
- vscarpenter 6y agoAgree 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.
- m6PeelVLsQ8QawN 6y agoSome 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.
- bstar77 6y agoEven 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.
- prophesi 6y agoIs there a good resource for finding terminal replacements for online tooling?
- jamietanna 6y agoI'm happy to write blog posts for local alternatives to online tooling if you can share things you'd want
- kazinator 6y agoIf 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.
- darth_avocado 6y agoI 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.
- Mc_Big_G 6y agoFor VIM users: %!python -m json.tool
- jupp0r 6y agoI 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
- erulabs 6y agoI 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...
- Traster 6y agoIt'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.
- jamescodesthing 6y agoSomeone 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.
- mpurham 6y agoThis 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)