With the current
Meteor.settings model there’s a huge dilemma wether it’s secure to use third party packages. It is pretty obvious that granting access to the settings object all over the system makes credentials data vulnerable to really trivial attacks as described here:
I think that this thread on StackOverflow hasn’t received enough attention from the community so I was hoping it might be wise to bring it to the public one more time.
Long story short, the author of the posts observes that the malicious attacker may still our precious data by inserting the following line of code within a smart package source code:
It’s arguable if this is a serious risk and what are the odds a scenario like this may happen in real live. I understand that the community is al about trust and responsibility. But imagine - maybe you are a package author - a situation when someone stoles your meteor development account credentials and publishes an infected version of the smart package on your behalf. It would be a total disaster which we would all like to avoid, right? Another scenario: an attacker creates a package whose name differs by only one letter from the original one. Impossibru? Please take into account that some of us uses really funny nicknames, and it’s really easy to make a spelling error there. Imagine further that the guy (attacker) sets it’s state to “unmigrated” so the package is not visible on the atmosphere and it’s not easy to detect something wrong is going here and flag the package before it’s too late.
There must be some way out of here. The solution is - in my opinion - using the function scopes of individual files to include sensitive data locally with selected files only. And hey! We’re using this exact technique already:
but for a different purpose. So why not put a
Settings object on the list as well and only allow accessing sensitive - private - settings from the application context, and not smart packages context.
Yeah, I know what you may think. What if a smart package requires access to the
Meteor.settings object. Well, there are some ways to workaround that of course to ensure backward compatibility. Though - in my opinion - no package should actually require access to the settings implicitly and this can be easily avoided by exposing a
config routine that may be called by users of the package. From my experience most packages are doing this anyway, so that’s it. There’s no real need to expose settings to the packages implicitly.
All this said, I’m curious what to you guys think. It’s quite clear this level of security cannot be achieved without direct actions from MDG and updates to the meteor core rather than creating a dedicated package. I think the changes would not have to be huge and the only dilemma is how to keep the backward compatibility in a reasonable and secure way.