cFIREsim security vulnerability

[jamesplease]

Hi Mustachians!

I know a number of you may use the excellent cFIREsim tool. Recently, I found a security vulnerability that I wanted to share with you all. tl;dr, anyone can view or edit your saved simulations. If you put any sensitive information in there that you wouldn't want anyone to see, then you may want to go through and edit or delete your simulations to remove it. Also, be sure to download your results, because anyone can go in and delete everyone's simulations without much effort.

A month ago, I shared this problem with the creator of cFIREsim, Bo, but he didn't get back to me. I mentioned I'd share this publicly after a month, so here I am. A more technical description of the vulnerability can be read about here:

https://github.com/boknows/cFIREsim-open/issues/72

Thanks for reading!

James

[Outside the Box]

Yeah, I'm actually aiming to rewrite the whole site in python/django and add in better auth (and actual API endpoints) early next year.

Ha. And until then, anyone can just enumerate the users and then enumerate all the sims, sucking in all that data, and then delete everyone's sims at will. Nice!

He should disable the public site now, add a signed time-limited validation token (like JWT) returned to the client that is used in the HTTP requests back to the server (validated there) in the interim and put it back up, not just say "deal with it until I rewrite."

This is trivial stuff.

That's my opinion anyway.

[sol]

For some reason, I'm not terribly concerned about my cfiresim runs being sold on the dark web.

Is there even a place you could enter PII in there?  It's not like it's collecting credit card numbers or home addresses.

I never had any expectation of privacy in the first place.  If he were to just put a warning label at the top saying "any information you enter could be stolen by hackers" I think it can continue to be a valuable resource to the community with no other required changes.  It doesn't appear to be monetized.  There is no EU agreement.  I don't see the problem here.

[Outside the Box]

For some reason, I'm not terribly concerned about my cfiresim runs being sold on the dark web.

Is there even a place you could enter PII in there?  It's not like it's collecting credit card numbers or home addresses.

I never had any expectation of privacy in the first place.  If he were to just put a warning label at the top saying "any information you enter could be stolen by hackers" I think it can continue to be a valuable resource to the community with no other required changes.  It doesn't appear to be monetized.  There is no EU agreement.  I don't see the problem here.

Some people use the same username in multiple places which can be easily reversed to their real identities and then their sims include their real-life assets which they may not wish to disclose.

Acting like it isn't a problem doesn't seem like the right response, especially when the fix is so easy.

Edit: It's as simple as the server sending down a JWT generated (hopefully with an expiry). The client just sends this right back with the HTTP requests and the server validates it with its secret (same one used to generate the JWT). This way, you're doing the authentication OP suggested when he discovered the issue.

This really is something that would take a few hours, at most, to implement and test on most apps.

JWT libraries are available for every platform/language. It's mostly "plug and play" into whatever code you're using. You just define a secret on the server side (not shared with the client). Generate on page request, send to client, client sends back with async requests, server validates. Done.

[jamesplease]

Although I agree with Outside the Box that this is basic web development best practices, I am not concerned that anyone’s financial future is in peril due to what they have saved in cFIREsim.

It’s more that the service doesn’t tell you that it’s insecure, which goes against user expectation. I believe it’s a web developer’s responsibility to clearly communicate to users who can access any information that they store on the service, and how it can be used. This is why privacy policies are a thing.

A more realistic consequence of this vulnerability is that someone may have put a lot of work into a bunch of simulations, then log in one day and find that they’re all gone. Perhaps there are database backups, but perhaps not. That could possibly upset someone if they lost a lot of time, or if they were relying on this service to plan for FIRE.

The problem isn’t that this is Equifax-breach-level security issues, but more that the service isn’t being honest with its users. I agree with you, sol, that a warning at the top of the page, and no other changes, would probably be fine.

With that said, a service that does not have these vulnerabilities is obviously preferable, especially considering how straightforward it is to implement basic security.

[Outside the Box]

James, I see he said he will review your PR by the new year. If I have some time, I'll fork and do a PR. I'll have to set up a new pseudonym GitHub and SSH keys/email, etc.

He doesn't share db_connect.php, presumably because he thinks that's where secrets should be and doesn't commit a "default" config, so I'd have to recreate that. Presumably all that's needed is a PDO object called $db globally to get it going locally?

Edit: Never mind. I took a look at the code more. He's got lots of missing code. The repo isn't usable as-is. headers.php is missing along with the db_connect.php. His actual site is running the input.php it appears, using the phpBB3 login credentials and setting up a global (ew) $user in headers.php I'm guessing.

I don't want to try to guess at a JWT fix without being able to actually run it myself. For someone who has the skills to create cFIREsim, he should easily be able to drop in a PHP JWT implementation pretty easily into input.php (put the current token into the context of the Simulation class), getData.php (validate the token), and cFIREsimOpen.js (send the token that was dropped in input.php).

When he has time. I give up, without a completely runnable app from source to start with. :)

[pigpen]

Agreed that the site should probably post some sort of "data not secure" warning (although I'm not especially concerned about it personally -- and I agree with other posters who say that they never had expectations of privacy to begin with).

I would suggest, though, that before you get too indignant about it, you remind yourself that the creator did what I'll assume is a great deal of work and charges you exactly nothing to use the site.