31–40 of 170 posts
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.
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.
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.
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.
Earlier quoted context omitted.
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'
Type myintranetsite/ instead, this is faster than http:// in front.
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.
> 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 sensitiv…
Earlier quoted context omitted.
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)
The network console isnt going to tell you if the site's exfiltrating data via websocket or webrtc.
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.
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.
Some attacks exploit vulnerabilities in dev infrastructure. Exposed dev JWT token may enable such an attack.
2 - Look at the network tab, see anything leaving your browser, websockets whatever ? if not, it's probably fine