Secure Coding: External App Integration

Just another WordPress site

Secure Coding: External App Integration

welcome everyone this is secure coding for external app integrations with force calm hi I’m hasta this is tim first of all since this is the third day of dreamforce i am pretty sure that all of you know this by now but please do not make any buying decisions based on this talk alright so I’m hasta Cinco and I am a product security engineer at salesforce com and as a part of my job what I do is I work with product teams who are building applications for our customers so everything that our developers are building for our customers to use I work with them to make sure that it’s secure from a design standpoint of an implementation standpoint I conduct penetration tests on salesforce applications and I work with the teams and provide better security training make sure they have everything they need enable most more self service for product teams and you know helping them understand security bugs and guiding them to remediation today in external app integrations we’re going to talk about how do you build secure integrations with the platform and yeah I’ll hand it over to Tim I good morning everybody my name is Tim Bach I am also on the product security team at Salesforce one of the major roles that I have is conducting penetration tests on partners hoping to list on the appexchange so if I have failed any of your application reviews I do apologize for that a little bit the other thing I do is develop security automation tools to try and help our partners prepare for the review and be more likely to pass on the first their first mission so we are actually working on a lot of really cool proactive vulnerability detection stuff and reporting tools for you guys we hope to release that to you early in 2015 but there will be a link at the end of the presentation if you’re interested in helping us beta test some of that it’s going to be some really exciting stuff and like hasta I work with partners on phone calls and conference calls to try and help them through the process help them learn how to code securely so let’s talk a little bit about some of the stuff that we see our partners doing on salesforce and some of the things that have security implications does so the talk today is about app integrations and it’s one in a series of talks that the security team has been putting on this week talking about all the different ways that you can do things as developers with Salesforce and how to do it securely but app integration specifically is when you’re going to take Salesforce data and touch a third party system with it an application that you’ve developed it’s not purely on force calm and visual force so an example of this might be if you were a electronic signature provider and you wanted to have the ability to do signatures from your customers in your opportunity objects or your sales objects in Salesforce and touch a third system where you’re doing all that so one of the big things you’re going to need is a way to map Salesforce user identity and data to these external systems that might be mapping the opportunity objects to the actual signatures or the files in the other system sending the data out there about the sales opportunity so that you can automatically generate a contract or someone to sign electronically all these things for a connected flow that you have a lot of data in Salesforce you want to get out to this third party system but we need to find a way for you to do that and have access to that Salesforce data without breaking our security model or the implicit trust that our customers have and everything on the Salesforce platform so there are several methods you can use to actually integrate your apps with Salesforce the most common of these is the API method using OAuth credentials now OAuth is an open authentication service that allows you to delegate the authority for someone to use your user account to an external system without actually giving them your user credentials including your password what’s going to happen as a token will be generated that should be treated with the same sensitivity as a password because it does allow you to do things with that person’s user account but the OS scope can be limited so that you can delegate only certain permissions to that external service you can then use sales forces public-facing api’s to share data back and forth grab data out of Salesforce push data into Salesforce and as developers you can also develop custom apex endpoints that you can call in that same API rest interface another option that we’ve made available is the connected app which actual runs within the salesforce com application canvas so this is not so much something that has access to the Salesforce Dom it doesn’t necessarily allow you to make new pages within Salesforce like visualforce or force com would but it does let you essentially frame your application into Salesforce so it has the ability to make it look very integrated within the Salesforce wrapper you can click a nap tab in Salesforce hop into it and have access to your external system now for that system to actually do anything with the sales force user account you will step still have to authenticate with Oh

author sam’l the first time that someone uses it and get that Oh auth token of the OAuth scope the connected app and that Oh auth scope that you set up as a developer in what you request from the user using your app is going to determine the amount of access that that hap has so just like with straight up Oh auth we would expect you as developers from a secure point of view to delegate the least the minimum viable set of permissions for your application don’t request permissions that you don’t need only request the bare minimum now one of the simpler methods is apex call-outs now the apex call-outs are easy you can have a user triggered action make a post request to some external server however this can only be used to send data out of Salesforce you can’t pull data in with a call out and it’s not going to get you the same level of access at anything with OAuth would so it’s not exactly the preferred flow if you just need to send a trigger to an external system and say hey this action happened in Salesforce I need you to update something you can do that but we would really recommend that you go with one of the OAuth flows as a connected app or as a full third party application purely due to the additional functionality it gives you and also due to the additional security provides to your users so let’s talk a little bit about the difference between authentication and authorization because this is actually one of the things we run into in security review a lot misunderstanding the difference between the two and it actually is a very important difference so authentication is going to refer to you who are you what are you allowed to do what have you been doing on the application so it’s your login your session and your user context it only revolves around i denti authorization on the other hand is what are you allowed to do so that includes your crud and fls settings on your objects it includes what objects you’re allowed to see your access control all the sharing profiles within Salesforce the license type you have within Salesforce all of that so that’s all contained within authorization now when you mistake the difference between authentication and authorization that’s when you run into the issue of saying well someone is logged into Salesforce so I’m going to let them do whatever they want you need to control them in in different spheres of your application you need to log someone in and get their user context in one frame and then when you’re actually performing an access an access or an update to a object that’s when you need to check our eyes ation check the crud net for less settings and make sure that what your third-party app wants to do that user is actually allowed to do within Salesforce because it’s part of the development platform we’re giving you total freedom within Salesforce we’re letting you write your own code we’re letting you do whatever you want as a third-party application so we’re not going to let you list on the appexchange until we’re sure that you’re preserving the Salesforce model of security and Trust because we’re not going to let a third-party application do things with a user account that we wouldn’t let it do on a on the core platform the one other thing I want to talk about when it comes to authentication authorization how to log in as a user how to you know act as a user in the third party application is secure credential storage now when you’re storing a credential to a third party system we want you to use a protected custom setting and that’s something that’s made available to you on the force platform and that’s going to allow users to set the secret in a custom setting so the user will be able to set that information and then you as a developer will be able to access that secret perform the required operations such as logging in to an external API and get the end result of that operation back such as the API session getting the API session back to you without ever actually controlling the secret so you’re not going to have access to dump a user’s token or credentials to the logs but you will have access to do what you need to do to make your app integration work so this this be used to store any API keys that you’re using externally we did have a talk on this from our team earlier in the week specifically 40 minutes of just talking about secure credential storage so if you missed that talk and you are interested more in this I do encourage you to go find the slides for that look up on our twitter account or on the chatter feed and try and get some information about that so i’m going to hand it back over to austin in just a second but to talk about some of our vulnerabilities and she’ll finish up with how to do credentials externally so we talked about well how do you bring in your system how do you integrate your external system its sales force how do you do the authentication and authorization part of it now well you have this iwasa token right and now in your external system you need to call into Salesforce and at once the user has said that it’s okay for you to do that so you have to make sure that you are handling smtc credentials externally correctly what that means is a whenever you’re doing this on whatever platform make sure you’re following industry best practices for secure storage on the platform that you’re using just the way we have custom settings for manage

packages within Salesforce based on the platform you’re on there would be other mechanisms that you can use it’s always advise to never try to reinvent the wheel for standard things like these and try to use the industry best practice standard for that and obviously make sure that whenever you’re integrating with Salesforce don’t try to have user enter their username and password into your external site and store that because when they are giving you an OAuth token that’s when they’re giving you delegated access and when you they’re giving you their username and password first of all they shouldn’t be doing that and second of all they’re giving you the they don’t have the ability to revoke that when it’s an access token they can go ahead and remove that if you know your application gets compromised or if they want to stop trusting your application so and for that same reason it’s also important to follow the principle of least privilege when defining your robot scope and obviously when it comes to access tokens as we said they’re same as your user credentials so never log it internally or externally because you don’t know where your lives are going to end up right so now we talked about how the integration works from the Salesforce and let’s talk a little bit more about what can you do for the external application that you’re integrating with because a lot of times on the appexchange what happens is the event people follow all the guidelines that we have up for secure coding on the platform it’s all good and you know people understand everything that’s going on and they’ve taken all the care they can for ok follow partner for less and make sure there’s no socket injection and make sure i’m using apex tagged for output encoding everything but what about your external application that’s that also becomes a part of the review now that its handling the Salesforce data it’s touching the Salesforce data right so when we’re going to conduct a review on your app exchange application we will conduct an end-to-end review of the whole system what that means is if a little part of your application is something that is i framed into Salesforce or is something where you have yourself or functionality built in that means that your whole external application now becomes a part of your review and obviously the Internet is a dangerous place and web application vulnerabilities are very pervasive and that’s why we need you to do a thorough review off your external app as well before you submit so let’s talk a little bit more about the common vulnerabilities that exist on external web applications and how to avoid them so first of all I have everyone has probably seen this at some point in their life so cross-site scripting what is cross site scripting cross-site scripting means that an attacker is able to execute malicious script in my users Dom what does that mean it means that when an attacker uses a one durable web application to send their malicious code usually in the form of a client-side script which then execute in my users DOM and now my victim end user has unknowingly given this attacker execute on their own Dom right so what’s happening is here one thing to understand is my user did not probably do anything wrong they are just you know legitimately browsing salesforce com or they’re legit removing browse education that they trust the problem here is on the end of the application that they’re browsing where it’s treating the user-supplied data incorrectly meaning now when we say user-supplied in this case there is the victim user and there’s the attacking user right so your attacker user is also a valid user in the system so when the attacker supplied input is reflected back on the web page without encoding it it gets executed on the victim users a page and that’s how that happens because there’s poor separation between data and code context when you’re talking about writing an HTML page what I mean by that is when you’re looking at the context so here for example you have this HTML page right so there is your HTML blogs there’s your script block there is an image source so now if you look at it this is both a data and code meaning there could be part of this page that could be coming from the user that you want to display based on what the user wants to display here right so for example here if you only only wanted the user to be able to specify the name in the scripts and the script block if you only wanted your user to be able to specify the name what’s happening is your user is able to break out of that name context and then like oh ok I’m already in a strip log then that means that I should be able to do something else while I live in a script block because now I am in the current DOM and I’m executing in the current down so now when we talk about HTML pages that’s the problem there there’s a poor separation between code and data and that’s why as

developers we need to make sure that we realize what context we are in and then we treat the user data correctly based on the context we’re in let’s talk a little bit more about the different types of cross-site scripting vulnerabilities that we see okay so first of all reflected exercise is the simplest one I give the server and input it comes back to me with the input in the response and does not encode it and if the input somehow is able to break context and execute in my page it’ll do that so what that requires is for my Victim user I guess it requires my Victim user to go and click on a link which sends that malicious input to the server in the first place right okay well if my users are smart then that might not happen well which is not true because there’s so many cat pictures on the internet and we all click on them all day so let’s assume our users are very smart doesn’t click on random links then they should never have to be attacked by a cross-site scripting vulnerability right no Stuart exercise what a stored XSS mean that means is my user when and my malicious user went in and stored their malicious input as as the normal flow of the application so for example if I am on say forum like if I’m on say stack exchange rate and then people are submitting comments there all day and if there was a cross-site scripting vulnerability there then if I go to search okay how do I encode input on the status change page that opens has a cross-site scripting vulnerability and someone has posted a malicious script that executes on page load then what would happen is as a part of trying to go and find an answer on stack exchange their malicious input is going to execute in my Dom what that means is now they can basically do whatever they want right they can try to send my document our cookie to a third-party they can try to exfiltrate you know anything that my Dom has access to which is pretty much from a browser standpoint that is pretty much the whole context of everything you’re doing on the application right so the thing here is having smart users doesn’t prevent xss so what you need to do is as the web server you need to make sure that there aren’t xss vulnerabilities on your page and then Dom exercises something there then you first load the page it doesn’t the payload doesn’t get executed but the user performs some client side action on the page because of which the dong gets modified and the paler gets executed so for example if there was an XSS on like a non click on the page we’re so when you first load the page nothing happens but then you can click then Dom’s be modified and because of which the payload gets executed so the last ones a little bit harder to detect from the standpoint of just looking at direction request response if you talk about from an automated testing standpoint because because your payload is not malicious when the page is first loaded right your payload you can’t detect that okay you’re trying to break out of context here so that excess is a little bit harder to detect with the automated scanners all right so we talked about context we talked about talking about the different types of injection that can happen so your gmail contacts meaning when I’m in an HTML block what will I do too to execute my script right so like now but I’m in the body of the page all I need to do is I would need to start a new script block and I can do whatever I want and then I’ll close this trip blog the page is going to render correctly nothing Bad’s going to happen my strips going to get executed the users not going to even realize HTML attribute context now when I’m in an attribute context I don’t even need to start a new block right because you can execute script on attribute so what I’ll do is I’ll just close the current attribute that I’m in and then I will have an attribute which is like unload or on click on on error which would you know execute my malicious script when any of those conditions are met so that’s HTML attribute context now javaScript context means well I’m already inside the JavaScript blog so I don’t need to worry about starting a new script block I don’t need to worry about closing out of starting a new handler that would execute my strip right but what I would have to do is I would have to make sure that I close the context of the car in JavaScript string that I’m in right so all I need to do is I’ll close the single tick and then I’m out of the context of their name equals and now I can do whatever my strip wants to do right so based on does it sounds like we have to do different things for exercise based on where my inputs being reflected right so so let’s talk about mitigation how it seems really complicated and this seems like something that should be a very very hard problem to solve because I have to do a different thing

based on where I am so for mitigation of excesses the first thing that you would do is you will constraint your inputs to an expected format and the most important thing there is always having a white list of input a white list of good inputs as opposed to a blacklist stuff oh I don’t want you to enter script plugs guess what if you’re not going to let them enter stripped logs they’re going to find another way to execute a script in your Dom our browsers are really forgiving and a lot of times you can rely on some old version of some browser to execute a certain form of you know weird HTML attributes so the thing to understand there is if you only expect alphanumeric characters in your input make sure that you’re using that as a vital stuff allowed in portray but there can be cases where you’re actually okay with a user entering special characters right were you going to do in that case you can never say something like okay if your name contains an apostrophe too bad sucks to be you and you’re never going to be able to type your name correctly in my application well that’s not okay so in that case what you would do is you would do output encoding because output encoding is the most important defense against XSS what that means is you’re rewriting users applied data so that it cannot break out of the structural contacts that it’s in meaning you’re telling the browser to treat that special character as text and not as code so you’re trying to print the special character on the page and not execute it so again the thing that comes to upper encoding is making sure that you understand what context you’re in and making sure that your encoding correctly for that context so now when you’re writing on the platform the platform provides you a lot of you know built-in defenses when you’re writing code on the platform so you will use the end of a visualforce components to render HTML you will make sure you never set escape equals false you’ll make sure that when you’re writing custom JavaScript or when you’re riding event handlers you’re going and you know explicitly encoding user input and then make sure that you’re calling the correct encoding function now be now when you’re writing using you know the visual for stags you know that okay man i’m writing a visualforce tag then i know that the platform’s already giving me platform protections now when I’m writing custom JavaScript I know that I’m going to be in a JavaScript contact so making sure that i’m using Jason code in that case or you know making sure if there is a case where I’m not using standard version for state tags but I’m writing HTML and you know I did or if I’m using a standard visualforce tag with escape equals falls making sure that I’m HTML encoding the user input part of the whole thing right so make sure to encode explicitly in apex when you’re disabling default escaping first of all please don’t disabled default escaping but if you know there is no other option and you really need to make sure that you’re you know explicitly encoding yourself make sure that you’re calling the correct encoding function based on the context you’re in and make sure for custom JavaScript for merge fields and event handlers make sure your GS encoding correctly and other than that the platform is going to take care of you right so for example in this case and the first one what’s happening is I am getting the current page parameter and I’m displaying the user input back as an output text right but is that going to be wonderful to exercise yes it is because we’re doing escape equals falls right so we’re telling the platform that I got this and you don’t need to encode anything but you’re just taking the parameter for the page and you’re displaying it back directly right now in the second case you know that you’re you’re initializing a JavaScript variable from the current page parameter but you’re doing GSN code because you’re in the JavaScript context now in the third case of what you’re doing is you’re taking the Burchfield message and then you’re calling a display pop up on the message right so in this case what’s happening is you’re doing a custom event handler and we said that in the case of event handler the platforms not going to know the GS encoded so you would have to explicitly go and GS encode the message before you merge it into the call out for display papa so these are things on the platform now when you’re writing code externally what do you do well first of all make sure that you are using all the platform protections that come from the platform that you’re using because obviously SS has existed for way too many years that shouldn’t have been and everyone has built-in protections for from the platform that you’re using so make sure that you’re taking advantage of that make sure you don’t have coding patterns like document dot write or evals we should just not be used it’s 2014 and make sure that you’re not doing innerhtml assignments directly because when you’re doing innerhtml assignments

then if your user input is going to be a part of that HTML element assignment then your browser is going to think okay well you want me to go and you know construct an HTML element with this user-supplied input that’s not going to work because your browser is going to think it is supposed to treat it as code of there’s code in there so make sure that you’re using inner text whenever you can make sure to encode user input as close to the sink as possible what that means is your data might be coming back in multiple contexts right so making sure that your encoding it as close to the sink as possible so that you can encode it in the correct context and then obviously use the security features provided by your platform or the Tampa tech engine instead of building your own the problem with building your own is if you know first of all there’s a problem with being exhaustive in terms of you know okay I got everything that I need to encode and second of all what if something changes tomorrow are you going to go and find all of those encoding function in your whole code base and change them but probably not you’re going to miss some and then that part of your application is going to be one durable to exercise now and then during security review we use a mixture of white box and static analysis and black box techniques to find all of these anti-patterns to find you know a instances like this this is usually like the first pass of the kind of issues that we were looking for all right I’ll hand it over to Tim and he’ll walk us through some more vulnerabilities that TC on external as well as internal applications yeah I’m going to walk through three more vulnerabilities and you’ll notice that each of the ones I walk through gets about twenty percent of the time that hasta gave to xss and there’s a reason for that just doing some back of the napkin math if your application that you submit to security review includes an external component there’s roughly fifty sixty percent chance that we’ll find XSS in it and that’s being conservative with my guessing so it’s really big it’s the number one vulnerability on the web today it’s also easily the number one vulnerability that we find so we find that the application space and enterprise mirrors the consumer one but please please please take what you said to heart because even if you just have that one little reflected XSS and that’s all you have it’s probably another six weeks of your time before you get to your customers on the appexchange so a little bit of due diligence goes a long way next up sachal and sequel injection sachal being the salesforce com version of sequel so sachal or sequel injection is caused by naively concatenating user input with the key with the queries to your database you’ll notice a common theme here trusting your users is a fast way to get compromised using sachal or sequel injection a malicious user can exploit your benign database query to perform arbitrary database operations and retrieve or modify data they should not have access to basically when you trust my name is Tim and I setae that my name is instead the ending Clause of your query and I also would like to dump your database please that’s going to really really set you back I can do almost anything especially when you use my sequel there are some wonderful tools out in the wild one of them is sequel map and when we find sequel injection your report coming back from the appexchange security team is going to list all of your database user passwords and probably your customers passwords and it’ll just really be a bad day for you so whenever possible please please please do not use dynamic database queries use bind variables if your platform supports them if your database language supports them use prepared statements and at the bare bare minimum if you’re using PHP use their sequel libraries to escape every piece of user input that you put into a database query and again whenever possible just like with XSS use a pre-built API if you can there’s no reason for you to reinvent the wheel when it comes to security next up cross-site request forgery this is something that is just pervasive throughout the internet and it it’s hard to wrap your head around for a little while until you really understand it so I’m going to try and use a bank example but to start with let’s lay the groundwork everyone knows of cookies your browser receives them after a website sets them in general they are the most common way to store session ID tokens and your session ID token lets you do everything you want on an application what this means every time your browser makes a request to a domain it’s sending all the cookies for that domain because it’s trying to be helpful it’s trying to follow the rules it’s trying to make sure you have that session ID with you every time you make a request to a website so an attacker can make legitimate requests or make a legitimate requests that appear like a legitimate request with an authenticated session so the bank example I was talking about let’s say so I bank with bank of america i logged in to bank of america’s web interface and they don’t

have any see surf protection so i’m logged in my session is still active and I close out of bank of america and I immediately go over to reddit look at some cat pictures and one of them is on an attackers website now that attacker instead of including a cat picture in the image source tag has included the URL to transfer a thousand dollars out of the account that’s logged in at Bank of America to his account and my browser thinks I’m loading an image from some other server so it makes a request to bankofamerica com / transfer dot aspx gives it all the variables in the URL my browser sends all the cookies with it Bank of America receives it and bam I’ve transferred a thousand dollars to an attacker so how do we stop this it’s actually really simple and almost every platform has a built-in function to do it it’s going to be C surf tokens and it’s something that is included in the post body of your request it’s a unique token per user per session and it verifies that the request actually came from a user action it’s not going to be included in a cookie because you’re not going to set at least you’re not going to check the SI sirve token from the cookie you’re going to check it from the session store on your server the Salesforce platform does automatically add C surf protection to all of our post requests what this means for you perform any user state change requests and user modification to data via a post request make them click a forum button don’t do something when a page loads of you I get requests thanks to test for C surf identify state changing operations and look at those make sure you have that protection use an open source tool like burp or zap or sorry burps not open source use an open source tool like zap or pay for a tool like burp identify the sea surf token and then remove it and then send your request again if it works even once you remove that token unfortunately you are vulnerable to see sir if you should go back and look at where you’re verifying your si sirve token from if it doesn’t work throw an error log the user out do something congratulations you have prevented see surf from occurring now the other thing I want to make you aware of is that reusing see surf tokens across users and across sessions defeats the entire purpose of them so please at least 128 bytes of entropy or 128 bits of entropy sorry 128 bits of entropy in each token per user per session and that will be the industry standard so the last one I would like to talk about is my personal favorite vulnerability on the Internet today it’s remote code execution and it comes from developers just being so trusting of our users let’s say I want to set a profile picture on your forum or your document signing service you let you let me as a user of your document signing service set a picture so that when I sign it you can look in the history and Salesforce that’s connected to your third-party application your third-party application has this picture of me and you want to show this awesome you I that shows my headshot and says Tim box signed you know for this sales order awesome however if you are not verifying what kind of files i’m uploading and you’re serving those files from your server then i will instead of my picture upload a PHP file that is actually an online shell file i will then go to the URL that you are trying to serve my picture from and i will have full web shell running in my browser and i will just start dumping your password files and reading your source code files and when I can read your source code files I can find all the other vulnerabilities in your application and then if I was a real attacker maybe when i’m done i put a little one extra line of code in your source code file so every time a new user tries to sign a document it actually sends all the information to me and then I’m contacting your users with phishing emails and saying it’s from you it’s just bad for everyone so major ways to mitigate this check what kind of file is being uploaded and do not do not serve the file from your main domain serve it from a content distribution network servic from a sub-domain serve it from a third-party domain all together just Salesforce content com or something do one of these things and then even if I do upload that file I won’t be able to run it and I won’t be able to access your code and even better don’t run your web application is root so I believe that is the major bits we have for you today if you have any questions please feel free to ask them now after you wanna take that yep so I think

you’re trying to ask that when you’re trying to integrate an external application into Salesforce and then you’re getting the external user to login and then you need that for the rest of your cells per session how do you store that information is that ok so one thing it depends so if you obviously if you have aught implemented on your external application we would recommend that you get an OAuth token for your external app and then you use protection custom settings in the manage package to store that Oh auth token for your external app inside of Salesforce that would be the best secure storage do you have available on the platform so what that would mean so yea so wats token would basically mean that ok I have given this application running on salesforce com delegated access and now on your serve on the external server event that external server is going to see the hwacha token in the authorization header it’s going to go ok this token has access to these resources so okay I’m allowed to you know return these resources so it’s going to be the same but more tightly controlled you’re just gonna so if you are doing a lot too then if you have a refresh token then you get an access token and then access token is going to act as a session ID not valid passing the session ID from the user context of the sales force application out no we don’t regard that as a secure way of doing things we don’t explicitly prohibit it but it’s definitely not secure and the reason for that is that when you pass a session ID out your you as the application now have full access to the users information you’re essentially them and that’s that’s a poor experience for our users because they cannot revoke that access later so what we prefer to see is the OAuth flow and the kif you want to be inside the Salesforce Dom to connect adapt set up with the OAuth flow would be the way to go for that right that’s one of the that’s one of the big things that the Salesforce platform offers in terms of security for our users is restricting based on IP range so a lot of our clients and I mean Salesforce internally definitely we use IP range restrictions which means that even when I log in from work if I try and go log in off of our VPN I’m not allowed to because that IP is not even in our range we’ll upload the slide on the chatter of the session on the dreamforce app so you should be able to download it from there yeah just log into the dreamforce success community and will yeah so go to the actual session page and we’ll upload the slice of the chatter feed of the session we’ll also tweet the link out from secure cloud dev the sales for security twitter handle every so the review process is not predicated on the type of integration it’s if you are listing on the appexchange publicly period you will go through a security review and the scope of the security review is defined by whether or not any any part of your application touches a third party system if it does we will be reviewing that entire third party system then we will not write the security review is before you are allowed to

publicly list an app on the App exchange yeah sokol does support parameterised queries and if you go into the developer force security pages and the developer force documentation there’s a lot of good stuff there about specifically how to do it okay thanks guys I think you have to clear this room for the next session but we will be right outside if you have anything else