[HN Gopher] Many public Salesforce sites are leaking private data
___________________________________________________________________
Many public Salesforce sites are leaking private data
Author : impish9208
Score : 158 points
Date : 2023-04-28 12:43 UTC (10 hours ago)
(HTM) web link (krebsonsecurity.com)
(TXT) w3m dump (krebsonsecurity.com)
| satrday wrote:
| > "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.
| simonw wrote:
| If people keep making those mistakes, the blame should lie with
| the design of Salesforce itself.
| mym1990 wrote:
| 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.
| madeofpalk wrote:
| > Salesforce's permissions are very, very powerful and
| flexible, which also makes them complex
|
| Otherwise known as the "Jira Problem".
| Waterluvian wrote:
| 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.
| mym1990 wrote:
| 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.
| zdware wrote:
| 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!
| bramblerose wrote:
| > 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).
| satrday wrote:
| 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.
| martincmartin wrote:
| _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.
| closeparen wrote:
| 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.
| ethbr0 wrote:
| 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.
| carlmr wrote:
| >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.
| jiggawatts wrote:
| Someone here said: "Be permissive for people, least privilege
| for servers."
| coding123 wrote:
| https://registry.terraform.io/providers/hashicorp/salesforce...
| paxys wrote:
| 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.
| tomrod wrote:
| LOL. I wholeheartedly disagree where you place the blame.
| Broken-by-design means blame lies with Salesforce entirely.
|
| What _other_ major sources of data leaks should we expect from
| such past performance?
| aliasxneo wrote:
| I think there's an inferred /s at the end of the comment
| you're responding to :)
| the_duke wrote:
| I don't think so.
|
| Considering my experience with Saleforce, I'm quite sure
| the comment is entirely earnest.
| Paul-Craft wrote:
| 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.
| tomrod wrote:
| I reckon I am the obligatory whoosh of the day :) -- thanks
| for recontextualizing
| mym1990 wrote:
| 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.
| bombcar wrote:
| Those ISVs charging $250 an hour are the source of lots of the
| insecurity, because "that makes it work" finally.
| webel0 wrote:
| So many of these pages displayed tables that included a column
| for SSNs.
|
| Once they lock down the authorization permissions they ought to
| reconsider whether they really need to be displaying that data
| all over the place.
| chasd00 wrote:
| it's just bad config, it's a checkbox to censor fields like
| ssns on the UI. They need to check that box and click save.
| carlmr wrote:
| What's right should be easy. SSNs should be censored by
| default and it should be really hard to disable that.
| testplzignore wrote:
| > 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?
| gazelle21 wrote:
| 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.
| b33j0r wrote:
| This is a direct consequence of integrations as a service.
|
| 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.
| layman51 wrote:
| I still need to dig into the details, but does this exploit work
| primarily by changing stuff that appears in a URL?
| npace12 wrote:
| yeah for a public site thats exposed you just go to /003 and it
| would have a list of all the contacts lol
| bombcar wrote:
| When they went to longer IDs they REALLY MISSED OUT on the
| ability to make them cryptographically secure.
|
| 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.
| npace12 wrote:
| 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.
| cdcarter wrote:
| 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 ;)
| chasd00 wrote:
| 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.
| doubled112 wrote:
| 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.
| tmpz22 wrote:
| 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.
| chasd00 wrote:
| 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.
| Jach wrote:
| 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...
___________________________________________________________________
(page generated 2023-04-28 23:00 UTC)