4 ms·

I still need to dig into the details, but does this exploit work primarily by changing stuff that appears in a URL?

by layman51 3y ago

npace12 3y ago
yeah for a public site thats exposed you just go to /003 and it would have a list of all the contacts lol
- bombcar 3y ago
  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=1 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 3y ago
    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 3y ago
    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 3y ago
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.

I still need to dig into the details, but does this exploit work primarily by changing stuff that appears in a URL?

npace12 3y ago

yeah for a public site thats exposed you just go to /003 and it would have a list of all the contacts lol

bombcar 3y ago
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=1 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 3y ago
  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 3y ago
  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 3y ago

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.