Salesforce Certified Sharing and Visibility Designer – Programmatic Sharing Part 2

3. 3.2- Minimizing Security Risks in Programmatic Apex Sharing

This is section three, Programmatic Sharing, and this lecture is about minimizing security risks and programmatic Apex sharing. The topics of this lecture are cross site scripting attacks, sockwell Injections cross site Requests forgery Attacks data Access Control using the wish sharing keyword, this lecture discusses other security risks in Apex and VisualForce and what are the different ways to mitigate them.

Apex and VisualForce pages can expose an. org to different types of security risks like cross site scripting attacks, crosssite request forgery, and so called injections. In order to prevent such attacks, it’s very important to understand the different ways to prevent these risks and the considerations related to the use of some attributes like, let’s say, static queries, bind variables, and existing protections offered by salesforce like anticsrf tokens.

To better understand security risks in Apex, please sign up for this salesforce developer. org that shows these security risks as examples. This developer. org has various examples of these risks. So once you sign up for this, by following this link, you can see different examples in this and then you can test them yourself. On top of that, I highly advise you to do this.

Trailhead Module let’s now start with the cross site scripting or XSS. Security Risk as you are aware, in the past web pages were very simple and static, and they relied on HTML with just the content displayed and nothing dynamic. On the other hand, current web pages are in fact nonstatic web applications. They are dynamic and update based on the action taken by the end user.

So, for example, a simple mouse click can create a pop up window, or it can play music and so on. Cross site scripting or XSS attack occurs when a user input, like for example, entering a specific text and a form on a web page is reflected in the HTML of the web page for that. This kind of attacks can take this user input and execute it as code due to the poor separation between code context and user data.

 As mentioned, cross site scripting results when user input is executed as code. This is an example that will make it much more easier for you to understand it. Let’s say that we have a website that has an input field and this input field is taken and shown in another part of the web page. So any value that we enter in this input field will be taken and it will be shown as an output field. So let’s simply enter this text and as you can see, it is displaying in this other output field without any problem.

So you can see on the right side we have this input field and then we did enter this text. We clicked on Create Scroll, and then we have this value of this input field displaying and this output field. Now let’s get a little bit more sneaky. What happens if we enter some HTML code into this text box and execute? What will happen. Now let’s enter this. Instead of a simple text, let’s enter a text. But this text should be between two HTML tags.

So we will choose the U tag, we will open it and then we will close it. What happens when we click on the button? Well, because the enter text contained an HTML tag which is the underlying tag, and because the website was not designed to deal with this kind of risks of attacks, the underlying HTML tag is now part of the page source and the result at the bottom is an underlined text. Let’s now try this.

We will use the image source tag and then inside this tag we will use the on error attribute. This will result in a pop up because the entertain and the input field led to that. Both of these two examples are very simple and harmless, but you can see that this can get ugly quickly with more sophisticated input and can interact with the host server.

Now that you have seen the dangers that cross site scripting attacks can do, let’s see what you can do to protect against this kind of attack. As we mentioned previously, cross site scripting is caused by weak separation between code context, the actual underlying application, and user data, which is any information submitted by the user.

There are two basic techniques that we can use to protect against cross site scripting. First, we have the input filtering, and then we have the output encoding. The first mitigation technique for cross site scripting is the input filtering. Input filtering works on the idea that malicious attacks are best code on the point of user input. For example, if the user inputs a text between the B tag and the page strips or blocks the code, then no unauthorized code will run. There are two types of input filtering.

First, we have the blacklisting, where specific bad characters or combination of characters are banned, meaning that they cannot be entered or stored. The developer creates a list of known bad characters like HTML or script tags and throws an error if any bad character are in the input. And second, we have whitelisting, where only characters or words from a known list of entries are permitted, preventing malicious input. For example, if the user enters anything besides numbers and a phone number field, the application will throw an error.

The second mitigation technique for cross site scripting attacks is the output encoding. While input filtering techniques work by preventing bad data from entering the system, output encoding techniques take the opposite way they prevent malicious payloads already in the system from executing. In fact, output encoding is often considered much more necessary than input encoding because it doesn’t rely on any upstream or downstream protections and it cannot be bypassed by alternative input pathways.

How does it work? Well, this should be covered on the code side by using the appropriate encoding on the browser side. For example, in the case of the less than character. You can replace this character with the String and lt semi column and your browser will understand that you want the text version of the less than character, not the HTML version.

As a developer you can use the same concept to mitigate cross site scripting attacks because characters that can act as code are not represented in the meaningful version. Inside a block of code only the characters text equivalents appear. Now let’s talk about so called injection. So cool. Injection involves taking users applied input and using those values in a dynamic circle query. Let’s see this in an example. As you can see here we have a simple VisualForce page. You can see that this is a page that is using a custom controller. It has a page block with this title and then it has a four tag. As you can see, inside this we have an output field and then we have an input field with value equals to name and then we have a button that calls the action query.

At the bottom part we have a page block table element. Inside this we have two column elements. The page block table element has the value equal to cons and then it has a variable equal to con which is being used in the column components. Now on the right side we have the equivalent controller. As you can see this is the name of the class which is the controller of the VF page. It has a string and the string is called name with a getter and a setter. And it also has a list of contact which is called cons. As you can see the action query which is a method. This is equivalent to this action on the left side. And what does it do? It just has a string called query string that has a Socalled query and then it’s calling the database query method to invoke this string which is the so called query.

And then this is now being fed to the cons variable which is listed on this page block table. One very important note here as you can see that this is the string and then inside this we are defining the so called query. And then we are using this database query method to dynamically run this query. The very close of this query has this it has Is deleted equal to false and name like name.

So if we input anything on this side this will be used inside this query and this name is equivalent to the input field. So if you enter anything on the VF page this will be used in the query. And you can notice that we also have the is deleted equal to false. So this is a very important point to shed light on. As you can see I took the very close from the previous example and put it here on the top. Now let’s see two different examples. When the user enters bob and the input field.

This is the result of the very close. It is a very simple query that appears normal. But now let’s say that we have another value entered by the user when the user enters this string into the input field. So as you can see, this is exactly what the user entered test and then this sign and then one code and then one parentheses or and all of that. So if we take this input and replace name in the so called query with this input, you can see that this is the result of the so called query. This is the result of the string that is being used to build the so called query.

As you can see, if we run this you can see that the result of the so called query will be much more different than the result of entering any simple string. The resulting query will show all contacts. Why? Because as you can see the user entered this string and because he entered a closing parentheses, this parentheses is taken to close this first waveclose part and then this user entered or name like anything, which means that now we are looking for any contact be deleted or no. So this is a clear example of a socket injection that can be used to modify the intended logic of a query.

Now, what can be used to prevent sockwell injection attacks? To prevent a Socalled injection attack, avoid using dynamic Socalled queries and instead use static queries and binding variables. Let me give an example. As you can see, the method on the top is the one that we had in the previous example. To fix it we can use instead a static query with a bind variable and not a dynamic query as you can see in the code at the bottom.

So instead of using this dynamic so called query, so instead of using a string that will be used to construct the query and then the variable of the user will be there, we can instead build our variable that is exactly the user input and not the whole so called query. So this is basically a static query and this is a dynamic query. So if we use a dynamic query we are risking a Socalled injection. Finally, if you must use a dynamic Socalled query, use the Escape single quotes method to sanitize user supplied input. This method adds the escape character to all single quotation marks and a string that is passed in from a user. The method ensures that all single quotation marks are treated as enclosing strings instead of database commands.

Now let’s talk about cross site request. Forgery or CSRF. Cross site Request Forgery causes a user’s browser to perform an unwanted action on a trusted website for which the user is currently authenticated. Let me give you an example. Let’s say that an attacker has a web page called attacker. com. This could be any web page that you can visit. But this is just an example. Now let’s say that this website has an HTML tag that looks like this one image source and then we have a link and then this link has different attributes. So as you can see, it looks like a simple link and then you can see that we have these different parameters or attributes that are added to this link. So the attackers page contains a URL that performs an action on another page. So if I visit the attacker. com page, this will be executed. Now let’s see how this attack works. If the user who is visiting attacker. com is currently logged in at the same time to webpagea. com, then the above code will run and the URL is received and the action will be performed because the browser maintains the logged in user session and the user is still authenticated on webpagea. com.

To make it more clear, let’s say that you have logged in to your Gmail account and then you have closed the browser. After five minutes you have reopened the browser and you went to your Gmail account. In this case you will not need to relog in again to your gmail account because the browser maintained the session. This is the exact same thing here. The catch is that the user is already logged in to web page A by his her normal username and password and the session is maintained. And let’s say that this user is an admin on web page A. Now, because attacker. com executes a code on web page A without the user knowing and because the user has an open session with web page A, then this code will execute. So the code that we run in this case is this one.

As you can see we have web pagea. com and because the user has an active session with webpage A, this whole thing will run which will create a new user with that email and with that type. So by running this code without knowing, the user has created a new user for the attacker. This is another example. Imagine that you are the user and you visited the website towncryer. com. So as you can see here, this is you. You went to this website, this website had this hidden code and then you already had a session with this website open. Because you had this session open, all of this code could run. And as you can see here, we are invoking some API and then we are if you aren’t creating a user on this website. So you are creating a user without knowing, because the code of creating a user was hidden in this bad website and because you had a session open with this website.

So without knowing, you created a user for the hacker. So in other words, the attacker got the user’s browser to perform an unwanted action on a trusted site for which the user is currently authenticated. To prevent these attacks, Salesforce has implemented an antics token. This is a setting in your Salesforce. org that is enabled by default. The protection can only be disabled by contacting Salesforce support and you can see the CSRF settings by going to setup security controls and session settings. How does this protection work? This is an example for the same request as before, but this time with the Cross site Request Forgery protection turned on.

With the protection turn on, every request to Salesforce requires another parameter, which is a token, which is a number of random unique characters. So when the attacker website tries to execute its bad code, the bad code does not have the token to be accepted by Salesforce server. For that it will be denied. This token will change on every request for further protection and upon the next page load, the application checks the validity of the token and only executes the command when the token matches the expected value. This feature protects you when using all of the standard controllers ad methods. All seems good with Cross site Request Forgery, but even though Salesforce implements an anti CSRF token, there are ways to fall and the trap. This is a VisualForce example. As you can see, there is an action parameter that calls the perform in its action method and the controller. Let’s see this controller. This method parses the user ID parameters applied in the URL and uses it to update the user as a knight in the system. So you can see on the top we have a VF page and this VF page has this action, which means that this action will load before loading the page. And what does this action do? It will do all of that. So the main problem here is that before the VisualForce page renders and the user browsers, the Perform init action method is called.

And since this action executes before the rest of the page loads, it bypasses the default CSRF protection provided by the platform. To prevent this, block the application from performing operations on a page load by removing the action attribute and change any output link that gets its value from the action attribute operation on page load to a command button.

So when the user clicks on the link, it executes the Apex code rather than refreshing the page. And the final piece of this lecture is the with sharing keyword. As you are aware, each object in Salesforce has its own sharing permissions and each user has a predefined access to a certain records based on the sharing. When using standard controllers, the sharing settings are enforced, meaning that when a VisualForce page is using a standard controller, the user will only be able to access the records that they can access within Salesforce. This is called system mode. But when using a custom controller, the built in user permissions object and field level security and sharing settings are not respected during execution.

Which means that a user will be able to access all of the records, even though his or her sharing settings don’t allow this. This is called system mode. This is the default behavior and custom controllers. An Apex class has the ability to read and update all data within the the with sharing keyword on class definition forces the use of the security sharing permissions of the user currently logged in. In the first example, all contact records are returned, even if the currently logged in user does not have access to all of these contact records. But when we add the with sharing keyword, only the contacts that the logged end user has access to will be returned.

Note that this keyword only affects records access and does not affect feed level security or object level security. And that’s it for this lecture. In this lecture, we have talked about how to minimize security risks in Apex in general, which can be indeed be used in programmatic Apex sharing. There are several risks that we should be aware of. Cross site scripting occurs when the user supplied input is reflected on the HTML of a web page. To prevent this, we can use input filtering and output encoding. Socket injection involves taking users applied input and using those values in a dynamic Socalled query.

To prevent this, avoid using dynamic sockwell queries and instead use static queries and binding variables. Cross site request forgery attacks cause a user’s browser to perform an unwanted action on a transit site by which the user is currently authenticated. To prevent this, make sure that the CSRF protection is turned on and avoid performing operations on page load and change any output link to a command button so when the user clicks the link, it executes Apex code rather than refreshing the page. And finally, we have talked about the with sharing keyword that is used to control data access as it directs the platform to use the security sharing permissions of the user correctly logged in.

This keyword only features sharing rules and does not include field level security or object level security, which is also called Grant. And finally, as usual, thanks for watching.