> “My team is frustrated by the permissive nature of the platform,” Carbee said.
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.
> It's just laziness towards doing it the right way.
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).
Definitely worth keeping in mind the business needs. I'm not going after "well designed security that meets the business needs". I'm calling out lazy security that cuts corners because doing it well takes time and effort.
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.
Knowledge workers aren't usually hired to be process-following automatons confined strictly to requirements known in advance by their superiors, but rather to creatively design, optimize, and troubleshoot the processes around them. Which requires visibility into how they are actually operating in production, and not just in the imagination of some other designer.
That doesn't excuse exposing things publicly, or to employees who have no plausible business purpose, but relatively permissive structures internally are good.
Salesforce's worst design principle is hiding things people don't have access to.
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.
>if I can't know what I'm NOT seeing, then how can I discover I need to request it?
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.
Most places I’ve worked default to letting everyone read any source. Is that not the norm? Agree that it’s a game changer for those willing to use it, but I find that last qualifier to be surprisingly rare.
I'm calling out lazy security that cuts corners because doing it well takes time and effort.
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.
The truth is that Salesforce implementation partners vary incredibly widely in standards, and the platform has grown to be so large in part because of its customization opportunities. Salesforce has provided the tools to make the platform secure, but it is up to the implementation partners to use them. The finger needs to point to the partners doing this work.
These aren't mistakes, this is truly people cutting corners to either get a project across the line or to do it cheaply.
The product is essentially something like a very slow, "low-code" programming framework/UI builder. You get a huge variety of quality in Salesforce implementations, ranging from bad to extremely terrible.
This feels like a “well they should have already been experts” answer, which isn’t really an answer.
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.
For a project that has real world consequences in regards to private data, yes, they should have already been experts. There are about a million opportunities between the start and end of a project to evaluate and address data concerns and get the sharing and visibility model right. The permission model in Salesforce is not as black and white as zero permissions or big blanket * permissions. With a few exceptions for system administrators, Salesforce makes you make the decision of what to share with who whenever new objects and fields are created.
Yep. I was pretty confused because I worked on a COVID scheduling app hosted on a Salesforce "Site" (guest user, public site, whatever terminology use for it nowadays). Salesforce recently then had pushed a guest user security update that restricted object permissions to read. The only way you could let an anonymous/guest user write/modify was to write explicit Apex (backend Java-like language for Salesforce) to do that logic.
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!
i do a lot of Salesforce stuff, all of these issues are on Experience Cloud ( the Salesforce portal portfolio ). No one ever looks closely at the "guest user" this is basically used for unauthenticated portal pages, even though there isn't a user per-se there's still a session and it maps back to a user and profile ( profile = what controls security for a group of users in Salesforce ). What happens is the guest user ends up with read access on an Object ( SF term for a table ) somehow but it's never surfaced on the portal as a page and therefore never tested/known by the testing/qa team. Then, as an end user curious enough, through some browser request manipulation or address bar manipulation you can access the records for that Object (table).
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.
Yeah, it's a sad mess. I used to work at sfdc in the experience cloud, my team didn't own the guest user stuff directly but it and other permissions-related issues were always ongoing problems we'd have to work around anyway, or try to find better solutions for given our limited ability to change things (long history from the Sitemasher acquisition and integration), or help various owning teams fix their own broken stuff (articles were always "fun" and special especially when it came to sitemaps). Even collaborated with dedicated security folks to put together better info on securing a community (now 'digital experience' or whatever). I've thought if I needed some cash I could perhaps join a firm like yours and contribute some value quickly knowing how the sausage is made, but to be honest I'd rather forget about it all...
Did you know David Green by chance? A few years ago I ran into him a couple times in a row and got to be friends. Great guy but he always seemed to have a lot on his mind heh.
Yup, he was PM for my team for a while (and others) before we could hire more and scale up development further. Agreed he's great, he did indeed have a ton on his plate! (Heh, I guess I don't want to forget the people across the various DX teams, most of them I worked with were pretty nice coworkers to have and I still chat with or grab meals with some.)
Salesforce is impossible to set up by design. The mistake here was that these small businesses and government agencies didn't contract with a Salesforce-preferred ISV charging $250+/hr per consultant to correctly configure it for them.
Well its clearly not impossible since there is a whole industry of professionals doing it successfully for the past 2 decades. Salesforce is difficult to implement because it is extremely customizable and Salesforce is effectively completely hands off. It is not a small business product, and government contracts tend to be a race to the bottom for price, which results in poor quality of development.
FYI, I think you mean "implied," rather than "inferred." Remember the difference this way: when someone implies something, that means you may infer that they want you to believe it.
> Akiri said he notified the Washington D.C. government in February about his findings, but received no response. Reached by KrebsOnSecurity, interim Chief Information Security Officer Mike Rupert initially said the District had hired a third party to investigate, and that the third party confirmed the District’s IT systems were not vulnerable to data loss from the reported Salesforce configuration issue.
Does FOIA apply here? Can we find out who the third party was?
I've lumped Salesforce into a certain group of platforms everybody loves to hate on, like Jira and Wordpress, but they all have a similarity.
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.
There are legitimate grievances across the vast array of features Salesforce offers but if you find yourself blaming your tools you might be a poor craftsperson - or at least your organization is. And thats a hard truth many won't face and fewer would openly acknowledge.
Well how would salesforce, or any system, know you’re storing social security numbers? A custom field (a user created table column in SF jargon) is defined using a handful of data types. It’s up to the person doing the configuration to take the extra steps given what kind of dat is going in these fields.
yeah URL but you can also manipulate browser async requests. Salesforce portals and plain old Salesforce make a lot of async calls back to the server which is the style these days. You watch these in your browser dev tools and sort of deduce what's happening. Then you can play around and see if you can replay these requests but pointed at different objects or records and see what happens.
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.
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.
FWIW, the 18-character "longer ID" is just a checksum of the first 15 characters. The ID storage format did not change when 18-char IDs were released. So, in some ways, that opportunity hasn't been missed yet ;)
yeah that would have helped, but the issue was really that either the default RBAC for contacts when using "salesforce sites" was either Public from what I remember or it was one of those things that required a lot more proper setup and people usually would "get back to it later" and never did.
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.
This is a known issue. I was doing some bug bounty work on a target, found a salesforce domain leaking data. Reported it responsibly, and they basically told me to kick rocks. I have hear of similar issues from other security researchers.
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.