Many public Salesforce sites are leaking private data
krebsonsecurity.com
krebsonsecurity.com
As someone who implements Salesforce projects for companies like this, I place the blame solely on whoever setup that Vermont org. Salesforce's permissions are very, very powerful and flexible, which also makes them complex. Salesforce recommends and works best with a "least privilege" security model.
It is frustrating to me how often I see colleagues (and some clients) push for a "wide open" permissions structure, where every internal user can see everything unless otherwise specified. It's just laziness towards doing it the right way. During a brand-new Salesforce implementation for a multi-thousand user company, the stakeholders pushed me hard for an open policy. "We trust our employees". Ugh.
Just because "least privilege" is "the right way" from a (some?) technical perspective, doesn't mean that it's the right way from a business perspective. There is a real, and significant, business cost to needing to wait for access and not being able to discover data (and thus not even knowing that you need to ask for access).
That being said, there is also a real, significant business cost to leaking sensitive information. If users are frequently waiting for access or unable to discover data, that's a failure in understanding the users needs and/or failing to test those needs in UAT during implementation. Convenience should never trump security, in this context.
Time and effort cost money. It's possible that the value gained is less than the cost, and so therefore isn't worth it. Of course, it's also possible they don't understand the value gained until there's a scandal.
That doesn't excuse exposing things publicly, or to employees who have no plausible business purpose, but relatively permissive structures internally are good.
And it cuts to the heart of the agility you're describing -- if I can't know what I'm NOT seeing, then how can I discover I need to request it?
From this perspective, Salesforce is absolutely engineered for top down "Identify the process, create a set of permissions that allows it, then apply those permissions to the appropriate set of people" design.
As opposed to bottom-up discoverability (e.g. I can see that I don't have access to this thing, somewhere) + RBAC requests for a permission set I learn I need.
This is so true. I feel that most of our closed source scripts are duplicates because you can't search for existing internal projects in our system. If you know it's there you can ask for it, but you usually don't, so you build your own.
It made me realize everyone else was using source control completely wrong. Game changer to be able to look at or copy the source for {anything}.
These aren't mistakes, this is truly people cutting corners to either get a project across the line or to do it cheaply.
Albeit, we had many Salesforce developers, but we were VERY focused on security. I was pretty happy with how it turned out, because other COVID vaccine providers in the area that were using Salesforce were struggling -- https://www.austinchronicle.com/news/2021-06-11/hellsite-aus...
If anyone is curious, the scheduler I worked on is https://vaccine.heb.com/scheduler . Don't work there anymore, but I love that team!
If a Salesforce project started with zero permissions and made you add them in, and didn’t have any big blanket “*” permissions, I’d eyeball the implementers a wee bit more.
Otherwise known as the "Jira Problem".
Guest user problems go far deeper than what the article describes and over the years Salesforce has been slowly dialing down what the guest user can have access to. It's an intricate exercise to properly lock down that profile in Experience Cloud (the portal feature portfolio).
Guest user aside, privilege escalation attacks are very easy to introduce when writing custom APEX and front-end code. APEX is Salesforce's backend language similar to Java but runs in a system context not entirely constrained by the security settings of the running user. It's very simple for a naive developer to introduce a privilege escalation attack when writing an APEX method that is called from the front-end javascript framework ( LWC or Aura ). This is especially the case when the underlying record access model (think row-level access control in PostGres) is left to defaults or even opened further and not properly locked down.
At my firm we have an entire practice dedicated to Salesforce security and require security scans, reviews, and remediation performed by this practice for all implementation projects because of things like this.
What _other_ major sources of data leaks should we expect from such past performance?
Considering my experience with Saleforce, I'm quite sure the comment is entirely earnest.
Does FOIA apply here? Can we find out who the third party was?
In my brief exposure to it, I found that Salesforce's main strength is that it will let you do whatever you want. Its main weakness is also that it will let you do whatever you want.
Once they lock down the authorization permissions they ought to reconsider whether they really need to be displaying that data all over the place.
Analogy. I don’t like the apple app store being so choosy about what I can install, nor the play store telling me what to do.
However. I haven’t gotten any malware from a third-party in my dang life.
If you make a platform that doesn’t do anything without plugins, you can’t control what people do with it. Looking at you, Eclipse.
SF is the second-worst offender I’ve worked with.
https://help.salesforce.com/s/articleView?id=000385008&type=...
There was no need to make those human readable; 64 character UUIDs would have been just fine; as it is they're sequential and so if you know yours you can guess some more.
So now, you have all your contacts available for unauthorized users to read, and since they provide automatic "list" pages as /<first 3 chars of record> you automatically get a nice table interface for anyone to scrape.
It's not any different than what you can do with any other site. It's just that Salesforce is an incredibly wide and deep platform. You need to understand a lot about general web app security and then you need to know the Salesforce way of doing it across the whole platform to cover your bases. It's just a very complicated beast.