How your Bad Code is Making Hackers RICH: DigitSec CEO Offers Salesforce Security Tips to DFW Salesforce Developer Group

Title Slide with Image of Waqas Nazir

In this presentation to the Dallas/Fort Worth Salesforce User Group titled “How Your Bad Code is Making Hackers RICH,” Waqas focuses on common Salesforce security mistakes developers make while innovating, shares some of the perspectives that hackers might have, and explains why they may find it attractive to do bad things. Watch the full video above or read the full transcript below!

Hacking has gone from a fun way to learn and discover flaws so that they can be fixed to a more professionally-oriented marketplace of bug-bounty programs and professional consulting. Unfortunately, it’s also evolved to a point where hacking can result in ransomware and other types of attacks. This leads us to the point we find ourselves in today where the average 3rd party data breach can cost companies $8 million dollars. It’s pernicious! 

You can even find Ransomware-as-a-Service tools for as little as $39 on the Internet, while some attack tools will be provided at no up-front cost as long as the developer gets a cut of the ill-gotten gains. Companies can be hit by “double extortion” attacks where the bad guys compel them to pay to unlock access to their system AND must pay to not have sensitive data released publicly on the web. Companies may also be hit with fines for violations of security compliance rules and they may work with hackers to avoid those fines. Malicious hacking attacks represent a real and growing threat and the primary target is customer personally identifiable information (PII) which is the core of your Salesforce data.

One of the biggest security challenges the SaaS industry must confront is the assumption that all aspects of security are managed by the vendor. Many companies don’t realize that adding customizations or changing configurations often introduce critical security vulnerabilities into Salesforce. Moreover, sometimes impressive new features may have security implications that companies don’t realize, leading to a vulnerable deployment. We also see critical management challenges in that Salesforce as a platform can oftentimes serve many different business units in the same company with no clear assignment of responsibility for assessing and maintaining the security of the Org. 

Finally, there’s the “downplay syndrome,” where people minimize the importance or scope of the Salesforce Org and by extension, the threat. Companies may think that because Salesforce is low-code, or no-code, or that because their Org doesn’t contain mission-critical data, that there is only a minimal threat of a breach or that a breach will have limited consequences.

As a platform, Salesforce can be viewed as existing in two key areas:

  • Client-Side which is web-based and there are options for using VisualForce, deploying Custom HTML or Javascript, or deploying Lightning web components and the AURA framework.
  • Server-side where there are Apex controllers, triggers, APIs, etc. 

So most vulnerabilities are generated from bad code, rather than the vulnerability coming from the hardware side. It’s critical to keep this in mind as you develop code, but you should also rely on sound DevOps practices to support your efforts.

The flexibility of Salesforce configurations can be enormously helpful, but dangerous as well. Even if you have great code, it could still be compromised by running in an overly-permissive environment.

A very important tip to note is that many people assume that Salesforce IDs are some sort of secret code that only Salesforce understands. In reality, a Salesforce ID is generated based on a well-documented pattern, meaning that hackers might be able to enumerate through the possible values in the URL to find vulnerabilities.

So how can you fight off attackers and increase the security of your Salesforce Org? Below are just some of the many great tips that Waqas shares in his presentation:

  • Don’t wildcard domains for Remote Site Access. This can lead to access from unauthorized domains.
  • Only enable the Metadata API for the period during which you need it, then shut it down. Leaving it enabled persistently can be a critical vulnerability.
  • If you are going to rely on digital certificates for authentication, you should police self-signed certificates. While easy to generate and use, they don’t offer much protection on the internet.
  • It’s important to have the proper sharing model for classes and objects built in Salesforce and use granular permission sets for your users. Furthermore, developers and admins have to be careful of the security context that exists as data flows across objects and classes by using sharing rules.
  • When you must use “without sharing”, it’s important to document your reasons. Mixing code that will execute “with sharing” with code that will execute “without sharing” is usually a bad idea.
  • SOQL and SOSL injection vulnerabilities are common and often critical. The fix is to bind your variables rather than to create strings on the fly. You can also use escapeSingleQuotes() but that isn’t a complete solution when considering queries for integer or Boolean values.
  • Secrets within Salesforce are a powerful thing. When you use “Protected custom settings” for your Apex code, it will limit the access to those credentials to the specified namespace.
  • Marking data as “transient” within your Apex code will protect sensitive data when it is exposed in the view state. Knowing that data can be exposed in a Base-64 encoded hidden form-field can really help you remember this rule.
  • Salesforce will render variables even when the code is set off in the comments. This can create an exploitable attack vector. Using “Escape equals false” for rendering mark-up is problematic. There are useful functions for rendering data in almost any code context, like HTML, Javascript, or URLs.
  • Understanding your attack surface on custom code as a developer or an architect is key to security. The best way to do this in your modeling is to add an attacker at every entry point. Then ask yourself what can you put in place that will run additional validation, checks or additional constraints that will protect against attacks?
  • Relying on the principle of zero trust, that even authenticated users could be malicious users, is a sure path towards writing great code.

Read the full transcript below!

TRANSCRIPT

Paul McCollum:
All right, so this is our usual segue to Waqas, where he gives us tips on secure code, but we’ve got a full session on that right now. So Waqas Nazir is the CEO and founder of DigitSec, I have not had a chance to look up your background so that I can talk you up. So I’m sorry for the bland intro, but please take it away at your leisure.

Waqas:
Thanks, Paul. No background or talking me up needed. I’m here to share some things about security for Salesforce. Thank you for having me. My goal is to work through a deck, which talks about some of the common mistakes when which are made while developing on Salesforce. And since the title was something along the line of how bad code is making hackers rich, maybe touch upon like what’s happening with the overall cybersecurity industry, how of people are addressing some of the challenges. What are some of the latest challenges briefly, as you probably know, it’s a pretty vast topic, but give you some perspective of what’s happening from a hacker’s perspective and why it’s becoming more attractive for people to do bad things through technology.

Waqas:
So I’m going to share this deck that will go over this topic in a structured way. And then hopefully as Paul mentioned, if I get time and if there’s interest, we can show you the demo hack that we have, where we exploit a couple of vulnerabilities in a Salesforce instance that give us admin access to an org from the outside. So that’s pretty interesting, and hopefully you’ll find it interesting as well. So let me know when you’re able to see my screen.

Paul McCollum:
There it’s coming up, how your bad code is making hackers rich. Catchy title!

Waqas:
Yeah. Thanks for that. It’s your title stuff. I just copy pasted it. And so no protocol required to wait till the end to ask questions. Feel free to chime in as I’m going through this deck. The goal for this is for everybody to contribute and also ask questions if you like. So like I said, the main thing that I want to cover today is just the state of cyber security generally, and then the state of SaaS platforms and Salesforce specifically, and then talk about what are some of the challenges when it comes to SaaS platforms and security.

Waqas:
There’s a lot of misunderstandings and a lot of assumptions made with SaaS platforms, which can be dangerous from a security perspective. So I want to touch on that and then do sort of a overview of some of the things that Salesforce, when you’re developing in Salesforce, you should be careful about. The goal is not to do a full, deep dive of everything to do with Salesforce security, but to kind of whet your appetite with some of the things that you should be careful while developing on the platform and then talk about the need for application security with SaaS and Salesforce specifically, and then hopefully just now do a round up.

Waqas:
So what’s interesting is that over the years hacking started as this fun activity where people were experimenting with technology. So we used to call like hacking for fun and profit, but it was more for fun. People in the industry found it exciting and fun to find flaws so that they can be fixed. And they were recognized, as a result we had these long lists of contributing hackers, which were basically researchers who were finding flaws and they were given sort of recognition for the good work they were doing. But as time has progressed, we’ve had programs like bug bounty and things like that come into play where actually researchers, when they find bugs are actually going to get some money out of that effort. And rightfully so some of the things that they’re doing there doing a service for that company to find flaws and get those addressed.

Waqas:
But that has brought into this instance of, if I was to create an opportunity to make money by hacking, how much money can I really make. So if I’m a good person, I’ll get some bug bounty, but if I’m a bad person, maybe I can make more money. So that has created this whole new area of just hacking for profit, not necessarily for the good, and that’s where a lot of professionals draw the line is that they don’t engage in anything where they’re actually using a vulnerability to actually directly profit outside of sanctioned bug bounty programs. The numbers are pretty staggering. So average data breach in the US costs about $8.64 million and ransomware attacks are on the rise. There is a rise of ransomware as a service, and there are products, which are sold as low as $39, which basically is a ransomware that captures users’ data, encrypts it, and then asks for ransom.

Waqas:
There are some services which have no cost, so you can buy a piece of ransomware, attack a company, and you don’t have to pay a penny for that ransomware. But when you do get money back, you have to pay the vendor that you used for that ransomware to give them a cut. So it’s a pretty low barrier to entry for a malicious person on the internet to kind of use these services, which are pretty sophisticated tools. And we’ve had instances where 19 year old… Like teenagers have hacked multi-million dollar corporations and use these services, which are readily available.

Waqas:
A lot of the ransomware attacks go unnoticed because the goal for attackers is to stay under the radar. So they typically would ask low ransom so that they can make profit on scale. But over the years, we’ve seen targeted attacks to bigger companies. The classic one being recently against the Colonial Pipeline, which ended up paying about $4.4 million to the attackers to bring their systems back online. So the ransom typically varies from exploit to exploit. The second thing that we’ve seen, which is also interesting is just what is called double extortion, which is basically first you compromise install ransomware, disrupt the system, and then actually take the data out of that environment. So not only do they need to pay the ransom to bring their systems online, but the malicious parties then threaten them that we’re going to release this data on the web, try to make money that way.

Waqas:
But also that will result in compliance fines. There’s pretty much every nation and every continent is coming up with some sort of compliance program around data. And most of them, if you don’t comply with them, there’s a fine associated with it. So companies have to make this decision that either we do this on the low and get this taken care of by paying a ransom or face compliance fines and things like that. So actually something which is good, which is designed to better companies, which is through compliance programs, is actually being exploited by hackers to further extort money from the people that they’re able to hack. And then the attackers, of course, are not just novices. The nation-states are seeing this as a big tool in their arsenal, and they invest heavily in programs that disrupt companies as well as nations.

Waqas:
You could imagine the impact that Colonial Pipeline hack had on the East Coast. And you could extrapolate if that wasn’t addressed what could have transpired. So if they weren’t able to bring their pipelines up sooner, what could have been the results. So you can see, even in the future, nationstates investing heavily on cyber weapons and things like that, which would disrupt nations. And so it’s a growing threat against nations, this cyber warfare. And we’re also going to see more and more sophisticated attack vectors that come with it.

Waqas:
Moving on to the State of SaaS. So there are so many SaaS platforms that it’s hard to even catalog them, right? And we ourselves, our company as a SaaS service and pretty much every other company is moving towards that. It’s just a better, an easier way of doing business applications and things like that. So there’s just an explosion of SaaS platforms out there. And each one is unique. Each one is different from a security perspective. It’s different from a usability perspective. And this explosion has created a lot of interesting security challenges, and most often they are not addressed. And we’ll go over a while that is because of some assumptions that companies make when they’re getting onboarded. So what you’ll see from most SaaS applications is this very low barrier to entry. You just have to fill in a small form and just hit subscribe now, and you’re ready to go.

Waqas:
So out of the box, these platforms are pretty standard. They allow you to manipulate data. What have you, but as the platform grows, gains traction, the vendor is not able to support every use case. So they start opening up their platform. And this may not be any revelation for the folks here in Salesforce, you all developers. But then this creates an opportunity for third party vendors to come on the platform. So they start writing their own apps, developers write customizing the platform. So it enables them to innovate quickly and address business use cases. And they move far away from that initial click and subscribe to a very complicated environment where there’s many moving pieces and each one can have a security implication.

Waqas:
So some of the challenges that we see with SaaS platforms and the first and the most common one is that all the security aspects of a SaaS platform are taken care of by the SaaS vendor, which means that there is no way that we can mess up, right? They don’t understand the implications of the customizations they’re doing, or the implications of the different configurations within the platform. So this is a pretty dangerous assumption from a security standpoint, but we find this as a big challenge when we’re talking to people that you really need to look at SaaS security.

Waqas:
The second challenge that we face is just a lack of knowledge of the different things that you can do with this SaaS platform, which creates this notion of you’re operating blind in the sense that you may see a business feature that has just been released by the SaaS vendor, but you don’t understand the security implications of it or the compliance implications of it. So most of the time, the people who are utilizing a SaaS platform are, in essence, just consuming a lot of features without having a complete knowledge of what’s the best way of actually consuming this feature and making sure that it’s secure. And that can be very dangerous when it comes to security.

Waqas:
The other interesting concept with SaaS development specifically is who’s responsible, right? We see that most of the SaaS platforms as they start, they are out of the box features not a lot of customizations, but soon over the years, customizations are made to those environments. And many times by different departments to the same SaaS platform. So you don’t really know who would be the ultimate person who’s responsible for these changes from a security perspective. There’s also a lot of third party integrations that are done. So in the end of the day, business takes in, for example, Salesforce, and then they keep customizing it. And when a core becomes a core technology, they’ve moved so much through different iterations that they don’t really know how can we make one person or one group responsible for the development of this platform.

Waqas:
This is addressed from some of the technical debt that they may have, but also from a security perspective when you’ve had many people developing on the platform and you don’t really know who would be responsible once we start looking at the security of that development. And then the last challenge that I can go over and there’s many. It’s just like, we find this sometimes, it’s the downplay syndrome. This is only CRM. This is only ERP. This is only support. So, it’s not really that important, but what we’ve found is that there is important data in these platforms, sometimes sensitive data. And if they’re not properly secured, if resulted in breaches and fines and things like that. Moving to Salesforce. So there shouldn’t be any surprise to anyone Salesforce thoughts itself as no code, low code platform. They famously have the no software icon. And then they also have these developers zone. And so it shouldn’t be a surprise to the group here, but on one hand, they’re saying there’s no code. On the other hand, they’re saying we have 3.7 million Salesforce developers.

Waqas:
What’s interesting from Salesforce perspective is that they understand that their platform is very versatile and it can be customized. And it’s more than just a SaaS platform to be honest. It’s more like a platform as a service when you start customizing it. So they’ve given all the tools to the developers to do this, right? And then they’ve said that it is a joint responsibility between you as a user and Salesforce. So there are things that they would do, right? But there are things that you, as a consumer of the service, are responsible for. And those are the things that developers mostly are the ones who are going to be concerned about because they are the ones who are writing custom code, making integrations and things like that. So this is basically the official guidance from Salesforce is that if you mess up, it was basically your responsibility. We will make sure we don’t do anything wrong from our side.

Waqas:
So if you look at Salesforce as a platform, you can break it down into two key areas, right? There’s the client side code, and there’s the server side code. The client side code is web-based, you have visual force, you can write custom HTML script, JavaScript. You have lightning web components. You have the AURA framework. And on the server side, you have apex controllers, triggers, APIs, and things like that.

Paul McCollum:
Can I add something in? So it’s kind of easy to blow this stuff off when you’re a developer and your code is not necessarily handling money or sensitive data, but that’s not the only way that the breaches can have a cost anymore. Bank of America had a breach that a company blamed it for one of its partners, who’s handling corporate bank accounts. Somebody they lost money, got transferred out of their account. The company started a huge ruckus blaming Bank of America for losing their money. Bank of America started a massive forensic research, found out that, that company had lost one of its passwords. Somebody had a compromised password. They didn’t secure the password. They’d shared it with somebody, it got somewhere. Bank of America sued them for not following their password policies and personal security. So, and yeah, that was money. Yeah. It made the news.

Paul McCollum:
Also if your company gets a black eye, if you’re public and you get a breach that can cause a stock price drop. That can cause a customer faith drop. And they usually only have one thing to do whenever that happens is publicly and loudly fire the people that were responsible for it. And that can personally impact you financially. Also, I don’t think they’re under any obligation to keep from disclosing who was responsible and who they fired. So when they Google your name, if you want to see caused a breach due to sloppy coding next to your name on your resume forever, that’s a good way to have that happen. So, I just wanted to extend that impetus to own code security.

Waqas:
Right. Yep. And most of these bugs and exploits, at the root, there is some faulty piece of code. It is rare to have hardware exploits. It’s not something that doesn’t happen. Hardware exploits are pretty common as well, but majority of the exploits are happening due to faulty application code or misconfiguration of some sort. So there’s a lot of emphasis on quality code as well as good. DevSecOps practices to protect against attacks like that. So the question really then is that if you think of any other development language like web based, and the question then is how different really is Salesforce? The answer is not that much, right? There may be some quirks that these other platforms have, or Salesforce has some different features, but the net of it is that it allows you to develop client side code, which gets rendered within the browser. And then it allows you to deploy server side code, which gets rendered on Salesforce instances. So it’s not a SaaS platform from the strict sense of a SaaS platform. It’s actually more like a platform that allows a lot of customization.

Waqas:
So configurations is one of the key areas from Salesforce’s security model, right? It allows you to have very lenient configurations. It allows you to open up your instances to the point that you have no security. So it’s something that, as developers, you may be writing really good code, but if your code gets deployed in an insecure environment, then those environments will be open to attack as well. So as developers and admins, there needs to be an understanding of how to operate securely in the Salesforce world. So looking at both configs and code is important, and there are some interesting settings that you can do with Salesforce, which basically triumph all secure occurring. So it’s important to deploy secure code in a secure environment.

Waqas:
So one of the common questions or attack vectors that we see are around insecure data access. And sometimes we feel like the admin and sometimes even developer don’t understand the ID. Salesforce IDs are not pseudo random. Even if they were pseudo random, the security controls should be in place, but being pseudo random can give somebody this false sense of assurance that somebody needs to grab an ID to get a record, but that’s not entirely true. Salesforce’s IDs are well documented and they follow a pattern. So if somebody was able to get one ID, they can enumerate other IDs and gain access to other data if there wasn’t a proper validation of the user’s access. So it’s important to know this basic point when you’re developing for Salesforce, is that if you have a piece of code that is taking an ID as an identifier to access code access data, unless you validate whether this user has access to this ID or not, you’re most likely opening up a security flaw, which allows that user to basically enumerate other objects by just supplying valid IDs, which could be enumerated easily.

Waqas:
So from a security perspective, like I said, there’s two main areas you can break the Salesforce platform into. The client side code and server side code, and we’ll go over some of these as part of this, some of the controls that you need on the Client Side Code, as well as on the Server Side Code, so that you have some understanding when you’re developing for each type of technology to be aware of these things. Waqas:
So there’s a setting called Trusted Content Security Policy Trusted Sites. This is basically a list of URLs that you want to allow to be added into a Salesforce’s domain. So think of this as extending the platform on the Client Side. So if you have, let’s say a Client Side Integration with a third party platform, in order to allow that integration to work, you have to create what is called a CSP site. And Salesforce allows you to add any site you wanted to, but by default, it doesn’t allow any Client Side requests to a third party site from Lightning Web Components.

Waqas:
So this control is basically there, to make sure that third party content is not loaded without somebody explicitly allowing it to be loaded. What we’ve seen is that you can this control is sometimes used by using wildcards and things you like that. So it’s important to make sure that you have very specific endpoints that you want to allow as part of that. And similarly there’s course policies that you can set within Salesforce, which means that these are the domains that my Salesforce instance can speak with, or the domains that my Salesforce instance can basically can be called from. So these are third party domains that can call into your Salesforce instance and get a response back. So you have to be careful when you set these up, because if you wild card another SaaS environment, then every tenant from that SaaS environment is able to call to your Salesforce instance. So you have to make sure that this is lockdown as well. And it’s very specific to a domain that you want to allow, and it’s not a wildcard to a common domain that is available.

Waqas:
The third control for Server Side Requests is Remote Sites, and I think you’re probably aware of how this works. What’s interesting, though, is that remote sites are per org. So when you enable a remote site, all pieces of code can then invoke access to that remote site. So it’s not granular. So you have to make sure that there’s some additional authentication on top of that remote site that, a piece of code needs to be able to interact with it. Because, if let’s say you’ve developed some code and then there’s some other vendor that has developed code, if you enable a remote site, both pieces of code can call into that remote site. So it’s important to have some validation on top of that, and not just rely on like a, you know, whitelist of remote sites and making sure, of course, that there’s as a cell validation, because you could have insecure remote sites. Although, I think that is going away with the new changes, you cannot any longer have insecure remote sites. Before it was allowed. So that’s a good thing that’s happening on the platform. But then there’s the metadata API, right? I’m pretty familiar with this technology and Salesforce where you can actually deploy metadata. What’s interesting is that having this enabled also enables other pieces of code to deploy metadata in the Salesforce instance.

Waqas:
And that can be a security bug if you have this enabled in production, because all of a sudden, a malicious application can start deploying metadata that, you have no idea of in production. So instances where the metadata API is enabled, I think it should be for the time when you’re deploying something and then disabled for use, because you don’t really need to have this enabled all the time during operations. So it’s basically a way to get around security controls is by just having a malicious app, just deploy metadatas within a Salesforce instance.

Waqas:
So some things that we’ve seen with a lot of deployments is that a lot of self-sign certificates are used for authentication. It is easy to generate self-sign certificates on the platform and use it for authentication, but self-sign certificates provide no security whatsoever in the internet scenario. So it’s important to have sign certificates if you’re actually using them for authentication and make sure that you use those for production. So a lot of interesting stuff happens on the server aside. The code, by default, runs with admin permissions. So any object that you want to access, you have access to on the Salesforce side. The queries are run with admin permissions, and it is basically on the developers to implement proper authorization checks for all of the server side code.

Waqas:
The authorization, of course, is based on the current FLS and sharing model. Here’s an explanation of how this would look like. A user who has access to, let’s say, building would be in essence, in a object type of object. So if you have two buildings, a user only has access to one of those building that’s forced by the crud method. And then which floor then user can really go to his in the, basically the different fields on that object. And then which of these specific buildings is what sharing enforces, right? So if you, even though you have access to an account object, which account object is, is controlled by the sharing rule. And that is determined based on sharing rules and rule hierarchies and manual sharing rules and things like that.

Waqas:
So in the code, actually, you have to make sure that you’re enforcing all these by using the proper sharing terminology for the classes. So if you don’t define a sharing model for a class by default, and it will do actions without sharing, so you have to explicitly say that observe sharing rules. So the users that do have access to certain objects should be only able to read that object, or update that object, or delete that object. What’s also interesting is that if you a class, if a class is called, that has sharing enabled, but it’s called by a class which doesn’t have sharing, then the sharing rules will not apply. So in those cases you must use like inheritance to make sure that the security context flows between the classes. So ideally you should define classes with sharing rules.

Waqas:
And if there’s an instance where you must use without sharing, for example, based on the new releases that Salesforce is doing for certain scenarios, there’s no other option then using without sharing, then it’s important that you basically have a way of cataloging those classes and documenting why is it that you are actually doing without sharing, and there’s legitimate reason because you’re the user context as such, or it is being limited by the platform, So you must do it this way. But what is a bad idea is mixing code that is meant to be executed with sharing with code that is meant to be executed without sharing. So what that happens is you have a class without sharing, which has both code structures, and you have a very insecure class in that sense, because you are hoping that these methods will only be called by people who have access to it. But since the class is not enforcing the sharing rules, you’ve opened your yourself up to an attack.

Waqas:
So the fix for these is pretty straightforward. Salesforce gives you the right methods to call for each object type and fuel type with select statements. You can also use to get security enforced parameter, and that will enforce the authorization and access for you. So SoQL injection is actually a pretty common attack in Salesforce. It is very similar to SQL injection. The only difference is that Salesforce has limited the attack to select only. And here’s an example of how this would look like. So user’s parameter being grabbed ID, being grabbed from the input and being passed into database dot query. And if the input was give me the opportunities where the IDs, nothing or name is equal to Salesforce will give you the opportunity with the name Salesforce on it. So it’s easy to bypass security by exploiting SoQL injection mobilities and SoSL injection is very similar to SOQL injection as well.

Waqas:
So the fix for this is using the variables as bind within the statement, instead of creating a string on the fly. If you must create a string on the fly, then always use escapeSingleQuotes(). But one thing to understand is that escapeSingleQuotes() doesn’t protect you against queries, where you are searching on integer types or boolean types, because escapeSingleQuotes() is basically escaping single quotes. And if you don’t have single quotes, you’re not being protected. So you have to have other validation on top of that to make sure the values are boolean or is an integer and things like that. So that will protect you against SoQL injection.

Waqas:
So working with secrets in Salesforce, we find many times there are a lot of secrets for integrations secrets for specific functions to be called with APIs and what have you. And so here are the most important controls when it comes to working with secrets. So if you have Apex code that is going to be using a specific set of credentials and you create a package for that Apex code in a name space, then it’s recommended a use protected custom settings. So that limits the exposure of those credentials to only the Apex code within that name space. So no other Apex code will be able to call and get those credentials. So that’s the approach for saving secrets within a named a piece of code. The crypto functions give you additional ability to encrypt data on you. You can use utilize those for specific data types. Salesforce also enables you to have encrypted custom fields. So these are great for storing sensitive data like financial data SSNs, and things like that. What’s important to note is that only users who have the permission of view encrypted data can actually see this data in the interface. All other users will always get this data encrypted. And then the last thing that you can do with credentials is create name credentials.

Waqas:
This is available so that you can have some name credentials, which are not available or viewed by other users, but some users will be able to do it. So such as users with permissions of customized application or admins, which is a good mechanism for saving credentials for third party APIs and things like that. What’s also important is that when you’re handling sensitive data, let’s say you’re handling SSN or a piece of data, which is sensitive in nature. If you don’t market as Transient in your Apex code, it can actually be disclosed to the user. And the way this gets disclosed is that some of the variables on Salesforce’s Apex code get added to what is called the view state. So if you do a view source of a Salesforce page, you’ll always see a view state as a, Base-64 encoded hidden form field.

Waqas:
And in that form field are typically variables from the server side. So if you have a secret password that you didn’t want to disclose to your users, if you didn’t mark it as transient as a transient variable, it can end up in the view state. So that’s another pointer to make sure that whenever you’re handling secrets of sensitive data, you mark it as transient. So quick time check, Paul, I have a few more things go over, but I don’t want to take all the time going over some of the other things,

Paul McCollum:
No, please do you, are, you are the, the main ticket for the show and this is going great. There was one thing that I was going to add in, and I don’t know if I was looking for it while you may have mentioned it in. And I just took my maintenance trail modules badges this last weekend and week. There’s a new SoQL keyword. The of, with sharing that kind of pairs to the way the classes do with sharing. That’s something I think you can with, if you’re not working in a class that’s dedicated and, and declared with, with sharing, you can actually, you can put that in the SoQL itself to it. And it will the, I think the best thing about it is it gracefully delivers an error. If you don’t have access to the call columns or the data that you’ve queried, it’ll automatically send a handled exception and let you know that it’s a permission exception, and not just fail with the usual whatever buffer error that you get. Whenever it can’t find a pointer or something.

Waqas:
Yeah.

Paul McCollum:
So, sorry, please.

Waqas:
Yep. That’s the term with security enforced. So you can just tag that at the end of a SoQL statement and it’ll enforce user permissions. Yep.

Paul McCollum:
Thank you. Okay.

Waqas:
Cool. So cross-site scripting, we’ll go over this in a, in the exploit a bit, but what’s interesting in this example is that if you were to use this piece of code in a different just state HTML, you’ll see that, since it’s within the comment, it would be hard to exploit unless you were able to craft a string in it. But what’s interesting with Salesforce is that Salesforce gets the server side variables are compiled on the server side. And then the client side page is then loaded here. So whatever is in the comments, and it is the server side, variable, Salesforce will compute it, and then you’ll be able to see even the commented could be replaced by the right values. So in the is case, you have the variable foo.bar, and it is within a comment, but if you look at the exploit closely, all the exploit is doing is that closing the comment earlier, basically closing the variable definition first, and then closing the variable.

Waqas:
I’m sorry, closing the comment and then writing JavaScript that’ll get executed. So this shows like there’s some attack vectors that people may think that it’s, oh, I’ve just commented this piece of code out, but it’s actually still exploitable given the way Salesforce’s variables are rendered versus JavaScript. So make sure you look at all controls where you say escape equals false for the markup, because all those are vulnerable to cross-site scripting. Salesforce gives you the methods to encode user input. For example, if you’re within a JavaScript context, you use GSN code to make sure you’re protected against cross site scripting. If you’re within HTML, use HTML in code. If you are within your URL contacts, you use URL code. If you are within JS often HTML link code, then you use JS and TML link code. They’re pretty verbose in the way you want to use these functions, but they can become a bit confusing at times. So if you’re dynamically adding HTML to an element, which is discouraged in lighting web components, but is totally fine for regional force components or visual force pages, then you want to make sure that you utilize this particular function.

Waqas:
So there’s another attack that you have to be aware of when you’re developing on Salesforce, which is arbitrary redirect. So basically taking a user controlled input and then redirecting a user. Of course, since the user trusts your domain, they trust the redirect as well. So if you’re not particularly careful in redirecting users, you may end up users being fished or redirected to malicious sites through your site. Of course, the fix for this is to make sure either you have a whitelist of domains that you redirect to, or you always contaminated with a forward slash or something. So it’s always a relative redirect instead of an absolute redirect. If it’s an absolute redirect, then you want to, create a whitelist of good domains that you can redirect to, and not just rely on user input to redirect users, cross site request forgery went over this attack last time. So we can breeze over this one. It basically allows users to perform actions without their knowledge.

Paul McCollum:
[inaudible 01:12:05] you’re not in any rush.

Waqas:
Okay.

Paul McCollum:
Yeah. This is the good stuff. So I’m trying to write down these function names to make sure I still have them whenever I’m doing them, but this is the developer part.

Waqas:
Yeah. We’re happy to share the deck as well after the meeting.

Paul McCollum:
Great.

Waqas:
So folks can utilize it, but the fix for this, this was the, just to give some background to the folks who are, who didn’t attend the last meeting, this was the security tip of the month at the last meeting, where we went into this attack in some detail of how this looks like and why this is relevant to Salesforce. Basically this talks about the fact that you shouldn’t do any create, update, or delete functions within the initialization of a controller. Because if you do, then you’re opening yourself up to this attack, which basically makes just to request to a page with certain parameters. And if the page was doing things in the initialization of that, that controller, for example, here, there’s the invoke function, which is being called, and the invoke function basically grabs an ID from the URL of this page and then just deletes an account.

Waqas:
So you could see, in order for somebody to attack this, all they need to do is make the user come to a page where there’s an image and it has a link to this page and then a valid ID. And they can automate that and just delete all the accounts by using this one attack. So the reason this is vulnerable is because the second this page loads, the ID is grabbed, and object grab and then deleted. So it is by design vulnerable to this type of attack. So in order to protect against this attack, we recommend that you always do these functions. For example: update, delete, or create in a call back instead of initialization routines. So here we have a call back which says, save this account or update or delete this account. And there’s a card check that’s happening to make sure that the user’s able to update this account. And then there’s a call to update. All right. So we can breeze over this. This was the precursor to LWC. A lot of interesting stuff. Maybe, in the future talk, we can go over these things. 

Waqas:
From a developer perspective, one of the key elements is to understand the attack surface of the customization that you as a developer, or as an architect, is doing. And the way we recommend to look at any of this integrations or customizations in Salesforce is to add an attacker at every entry point, right? So you have an API, let’s say there’s a malicious person coming through that API, or the API has been compromised. What controls do you have to make sure that you’re talking to the right API, or the data that you’re getting from the API, you’re actually validating, and not wholeheartedly trusting that it’s kosher, right? Similarly, if you have an integration with a backend system, you think of that there’s a malicious input from there. Similarly, you think of the users that are coming in to your platform are going to use your customization or piece of code.

Waqas:
All input that comes from them is potentially malicious. If you have identity providers, what type of validation do you have with those identity providers? And you simulate a malicious user coming from that identity provider, and how those are protected. Similarly, from different entry points, whether it’s mobile or a different API that you’ve exposed, you think that there’s an attacker from that perspective and how are you protecting from those attacks?

Waqas:
So it’s important exercise to do when you’re developing on Salesforce, is to just understand your attack surface, right? What are you exposing, and whatever you’re exposing, what level of trust you associating with it. There’s a increasing body of work which says that there should be zero trust. So even if you have authenticated users coming over VPN, you should still consider them as untrusted until proven otherwise. All their input considered malicious unless proven otherwise. And that stems from this principle of zero trust. And there’s a lot of value in that. And if you are a developer, and if you think along those lines, you’ll end up writing pretty good, secure code, because you’re considering everything as potentially malicious, unless you’ve protected against that attack, or unless you’ve verified that it’s not malicious. So that’s a good approach to take when you’re customizing Salesforce.

Waqas:
So that’s where I think there’s a lot of value as a developer to think of Salesforce, and your customization, from the lens of application security. There’s a lot of assumptions being made on the platform, which are dangerous from a security perspective, which have led to data breaches, and what have you. And at the root of it is a vulnerability in the code, or a misconfiguration. So it’s important that we introduce application security to Salesforce, and developers are the most equipped to address this challenge. And if they start writing secure code, then they will ship with confidence. Their customers will be more happy with the end product, because they will not have to deal with compliance related issues or data breaches, not to mention the fact that they’ll be able to sleep easy at night, given they’ve done all they can to protect themselves.

Waqas:
So it’s important to take a bridge that you know you’re not going to fall off of. All right. So key takeaways, there are many attack vectors for Salesforce given it’s a highly customizable environment. The platform provides a lot of controls, but they need to be implemented. So Salesforce developers need to create those guardrails for their code.

Waqas:
And then in the end of the day, the SaaS providers are not going to be responsible for any vulnerable code deploying within sandboxes or production environments. So that, the presentation, comes to an end. I’m happy to take any questions or comments or feedback or thoughts that you all may have.

Paul McCollum:
That was great. I’m checking to make sure that everybody can speak if they want to. Yeah. I love seeing those. I tell you, the thing that haunts me when I started studying for CEH, one of the things they told you to go download was this penetration testing toolkit that was freeware all in one. And if you wanted to, you could point it at a website, and it would download the entire website, clone it to where it could operate wherever you want. You could pull up an exact copy of Bank of America, your Salesforce org, whatever you had access to. And those quick redirects that changed the domain on you, that you don’t catch, because you didn’t expect, clicking on an image, having it there and understanding that that’s what you’re working against. All these tools are free.

Paul McCollum:
Actual critical exploits are surfed by hackers within hours of them being released or discovered. They’re people scanning your orgs, trying to figure out, are you running a server with this patch level, so I can get in? It’s almost automated scanning of servers and systems. So the stuff that… The hackers are smarter than we are. They know our systems better than we do. And it’s much easier to attack a large number of systems, than defend while you’re trying to provide business value. So it’s…

Waqas:
Yeah. And I think part of it is that security is sometimes not emphasized to developers, right? They’re told to implement a feature that would generate more leads or generate more business. And if you say, “I need to run security analysis on this,” and all of a sudden, I need to go back to the developers and make sure they address these issues. Unless that’s emphasized, and it’s a part of the culture at the company, it’s unnoticed for some time. And the longer it goes unnoticed, the harder it becomes to tackle, and the problem becomes exponential. Like you said, it is an attacker’s game, right? Unfortunately. Because they just need the weakest link in your system or to exploit while you have to defend against everything, right? So there’s a lot of things that you, as a developer or builder, have to do to do things right.

Waqas:
But I think the benefit that developers or builders have is the ability to see the system from the inside. So they can take the guesswork out of the things that the attacker has to do. So they’re able to look at the system from the inside, and then be able to create controls around all the different variables and moving pieces. And that’s, I think, the key to building secure systems, is having that visibility, because like you said, the attackers are waiting for one slip up, and that’s all they need to get in. And they’re actually sometimes ahead in the analysis piece, and they know your system’s better than you do, which shouldn’t be the case.

Waqas:
So I think a cultural shift from the organization is needed to enable developers, so they can actually spend some time on security, because they’re capable of writing secure code, right? It’s just, if that’s an emphasis and a priority, then they do it. But if the priority is shipping code as fast as you can, regardless of what shape it’s in, then you’ll continue to see exploits and hacks and things like that continue to surface. And we’ve seen some companies do this better than others, and it comes with a cultural shift from them.

Waqas:
And even like companies which had notoriously poor security have come long ways by making that cultural shift, where they made this a priority, and now they’re shipping great products.

Paul McCollum:
I had a stupid moment, and I’m happy I caught myself being stupid watching the first half of your presentation. I was getting a little itchy and wanting to see code. I wanted to see the Wist security enforced, and you were showing all of the admin controls that turned things on and off. I was like, “Well, that’s admin stuff.” And as I was ramping myself up to get frustrated with it, I realized all of the admin controls that affect dev capabilities, your admins aren’t going to know about. So you, as a developer, you really have to take… You’re the only one that will know what and why those controls should be enabled, turned on, and enforced. It’s not your code. It’s not just your lines of tags and instruction. You’ve got to make sure that the framework supports that, because it’ll be your code.

Paul McCollum:
You’ll be the one that gets blamed if you didn’t configure the org to run your code safely. So I am looking forward to going back through that with a little bit more humble eyes, because I’ve never worked with an admin than it would know cross site scripting and what cores was and how that worked. And I might turn it off to get it to work for a while in dev. But if I accidentally promote that change up to production, or somebody else does as part of a change set or a batch or a metadata scan that just pushes changes up. I caught somebody the other day, almost pushing a cores allow request up to a client’s production environment based on… I think it was installing an app exchange app that expected you to put on your org an allow request to clam AV. And we started pushing that up to… I was like, “No, no, we’re not promoting…”

Paul McCollum:
And it was just there. It’s like, oh yeah, I shouldn’t have put that there. That was there to make this work. It definitely doesn’t need to go to production. And those slips can happen. And if you’re not paying attention, and if you don’t know where all those admin features are, you’re the one that’s guilty of not managing your code, because your code connects to an org, and those settings are code settings, not admin settings.

Waqas:
Yep. And I think if you elevate from a developer to an architect, then you’ll see, also, these are all interconnected, right? That you can make sure that the developers are doing the right thing. But then the developers are actually guiding the admins, too, to make sure that they’re doing the right thing to deploy the code securely. And they’re not just like… You could write the best, like I said, the best code you can, and if the admin exposes your org, all of a sudden, you are responsible because you are part of the team. So I think there is definitely a disconnect that I see sometimes, that admins are running independent of the dev arm. Dev arm is more focused on like, “We do code. We don’t touch configs,” and the admins are like, “We do configs. We don’t touch code.”

Waqas:
So I think there needs to be a healthy balance maybe from an architect or something, where they can bring the two disciplines together, as we’re on the same page from a security perspective that when you’re deploying, when you’re adding a cores policy, you have to ask me like, “Do you really need this CORS policy? Because my code certainly doesn’t need it. Or do you need to add this CSP policy? My code doesn’t need it.” So all those things, I think, are important, as you go through this exercise. So yeah, definitely a good point. Yeah.

Paul McCollum:
And I’ll go ahead and say it, because I love starting fights, but we all know if admins were smart enough to be developers, they would be. So you’ve got to do that. I’m kidding. If you’re admins, I’m just joking.

Waqas:
Who’s the admin on the call can counter that? The other way around, right? From the admins.

Paul McCollum:
I have the argument with the Megan fairly regularly about the maturity and security architecture being something that, when you’ve written bad code, you can be a good developer. When you’ve built bad solutions and seen bad code written, you can be an architect, and you have to have that experience. And I think with security, you’re almost required… It’d be hard for me to stay in a developer role, knowing all of the things that I should be checking and testing whenever I’m working with developers that may not have seen all this. I think once you know where the holes in something are, it’s your responsibility to step up and be an advanced hole plugger, to fix those areas and make it your specialty and continue to move up, because it’s hard to explain. Nobody’s really teaching you where all these levels are.

Paul McCollum:
I haven’t seen a good class explaining what cross site scripting is. Salesforce has some stuff on it, but it’s changed, and interacts with locker service. It’s getting complicated, and it’s hard to sit down and tell somebody that’s really just started programming in the wizzy wig interface of Salesforce all of this skunk works behind the scenes that you really need to appreciate. And I think once you do, you’re obligated to continue to work at that level, and help, and guide others and teach, because it’s big, and it’s deep. And if we want to continue to live online, we have to educate and move people up.

Waqas:
Yeah, and I think some developers have to pick up the mantle, so to say, right? To lead the way and really explain to the ecosystem that these are the security implications of the code that you’re writing, whether that’s doing a deep dive in cross site scripting, or SoQL injection, or credit flaws or what have you. But there’s definitely a void that needs to be filled to address in the ecosystem.

Paul McCollum:
So I’m excited for you to be doing this recurring session with our group on security. And I’d love for you to tell us briefly about DigitSec, and I will segue into why I think it’s going to be amazing for us to have you as a partner with our group.

Waqas:
Sure. So we’re a company specializing in developer security for Salesforce. We have a product that does static source code analysis, as well as runtime testing, software composition analysis, and configuration review of a Salesforce environment. What that means is that we can assess the Salesforce instance holistically, and provide instance guidance on what the current risk posture, or the threat posture, is for that Salesforce org. But more importantly, our mission is to enable developers to write secure code.

Waqas:
And the way we help developers do this is by giving them this tool set. So they use this on a daily basis, if you want, to analyze their code as they’re developing. So when they see a certain bug being flagged by our product, they become aware of the issue. They know how to address it. And then hopefully, going forward, they’ll not introduce the same type of bugs as they’re developing. So continuously taking the bar down of security vulnerabilities with their projects, and that’s our, basically, goal as a company, is to enable developers with our product to develop securely and stay secure in production.

Paul McCollum:
And so, you wrote the DigiSec program that does scanning a while ago. And you just wrote it once, and you leave it alone and you don’t update it ever, right?

Waqas:
So we have a service, and it is updated pretty much regularly, because there’s new exploits coming out. There’s new stuff that Salesforce releases, and there’s security implications of those. And I wish it was like done once.

Paul McCollum:
I was being sarcastic and tee balling that up for you. And it’s really my… So your business model is built around keeping track of new exploits and putting them into your product, so that you can find them for your clients. And I’m very excited to have you regularly show up, and tell us, “Here’s where the new things are. You can scan for them yourselves, or you can use our product, but this is what’s new. These are the three things that came out this week that we rolled into our product. Now you know, and that’s the difference.” So I’m super excited to have you here participating regularly, to keep us on the bleeding edge and be able to write zero day safe code.

Waqas:
Well, yeah, yeah. I mean, hopefully we’ll want to disclosing any zero days in that presentation, but definitely new ways of exploiting things, and what we see happening in the ecosystem. The goal is to make people aware so that they can be proactive about security.

Paul McCollum:
Yeah. I only accidentally heard about the SOQLwith security enforced the other day when I was doing my maintenance that was quite overdue, and, yeah, I’m sure you guys have already put that on a SoQL analyzer and hey, you’ve got 800 SoQL statements that don’t have with security enforced. Make sure you’re okay with that. And yeah, I am looking very forward to keeping regular touch with all of those things. So thank you for your session.

Paul McCollum:
And I’m blathering on. Anybody else have any questions for Waqas? All right. Quiet group. Everybody busily scribbling notes. All right. So I’ve had enough people attack me on social, asking for where the video’s going to be hosted. So with your permission, I’m going to try and start up a YouTube channel and get this out here. And it’ll be the tipping point for us, getting started and doing that extra work. So hopefully that’ll be up soon, and I’ll link to the deck when you get that to me. Thank you for very much, Waqas. that was great.

Waqas:
It’s a pleasure. Thanks, Paul.

Speaker 1:
Thank you all.

Paul McCollum:
Thanks, Almay. Anything to close us out? Adrian? Almay?

Almay:
Yeah. I would like to thank you, everybody. Thank you, Waqas for this wonderful session. And I appreciate everybody’s with this part of the hiccup with the baby account, you’re all stuck with us, and gave us your time. So appreciate you all for sticking with us and thank you, Waqas and team. This is great.

Paul McCollum:
All right, well, thank you everybody. We’ll see you next month, and we’ll talk to you soon. Have a good week. Reach out if you hear anything new, or want to share anything, or have anything include in the presentation. We’re always open to new content. Until next time, bye guys.

Waqas:
Thank you everyone. Take care. Bye. Thanks.

Picture of Adrian Szwarcburg

Adrian Szwarcburg

Sign up for our Newsletter

Get security tips sent to your inbox.

Sign up to get updates and security insights from DigitSec