Imagine you’ve been tasked with designing the layout of a grocery store. With the best intentions in mind, you design it so that customers can easily navigate the aisles and leave raving reviews about their experience. In addition to basing your blueprint on product placement, you commend yourself for also considering how your customers will enter the store, proceed to checkout, and exit. On paper everything seems fine and dandy, so the layout you developed is commissioned.
Once the store is open and customers pour in, unforeseen issues spring up from design flaws in your layout. Some customers notice these flaws and exploit them to shoplift products. Shelves placed in certain positions can’t be properly monitored, so items are easily pocketed. The entrance was placed so that thrifty individuals could easily snatch items and walk out. No locked shelving was installed so high-priced valuables are at risk to be stolen too.
Now, imagine that you’ve been tasked with developing a web app. Are you aware of the security flaws that your design could potentially have, and how malicious users could exploit these flaws at the company’s and other users’ expense?
Women in Cybersecurity Conference
I’m currently a student at the University of Tennessee, studying Computer Science, and I’m also an employee of CodeScience, a company that develops apps for the force.com platform. Whether at school or at work, the issue of security is constantly highlighted in the software development process.
I had the privilege of receiving a scholarship to attend the 2016 WiCyS (Women in Cybersecurity Conference). It’s not breaking news that cybersecurity is a flourishing and crucial field, such that many industries are desperate to employ cybersecurity divisions in order to keep their assets, andparticularly their customers’ personal information, safe. From working at CodeScience, I was already quite aware of this. It’s a well-known cardinal rule in Salesforce software development that all apps intended to be listed on the AppExchange must pass an extensive security review process before they can be deployed. This is so Salesforce’s users can trust that their data is protected.
While at the conference, I had the pleasure of hearing from various speakers from tech powerhouses such as Microsoft, CISCO, Facebook, Bank of America, and Google, along with professors and researchers in the field of cybersecurity. Target was used as a prime example, revealing some of themajor ramifications that could occur to the entire economic system due to poor security practices. (If you’re not familiar with the Target credit card scandal, read this for a brief rundown.)
On the last day of the conference, I attended an especially enlightening workshop held by Google’s Security Engineers and Privacy Engineers of the Information Security and Assurance Team. It was here that the missing link in software development — specifically with UX and UI, Salesforce, and cybersecurity — was revealed to me. The Workshop entitled “Breaking the Bank to Save Web Apps”, touched on subjects revolving around same origin policy and web application vulnerabilities; in particular, a form of Injection called SQL Injection, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (XSRF).
Cross-Site Scripting
Cross-Site Scripting occurs when an attacker causes the user to execute code that’s hidden where data’s expected. It comes in three major forms: reflected, stored and DOM-based XSS. The reflected form of XSS is a type of malicious code that exploits faults in user input from a form field or the URL displayed on the page. The stored version exploits vulnerabilities from user input from other sources displayed on the page. (Think about all of the input fields that are available to be edited on the profile page of a web app.) DOM-based XSS attacks can occur when user input is changed without a page load and may be found in the part of the URL after the hash symbol.
Cross-Site Request Forgery
Cross-Site Request Forgery is a form of malicious attack on a web application using Javascript that causes the user to issue a request to the server without an intention to do so. It causes what is known as a “State Change Request”, which leads to the user being lock out our their account by the hacker because they changed the state of their account information. This could mean logging the user out, changing their password and deleting their account.
Examples
Design Flaws
One of the instructors created an intentionally vulnerable online banking application called MehBank. The instructors had us explore the web app for potential design flaws in the app’s HTML and Javascript design flaws that could leave the user susceptible to XSS attacks or XSRF attacks. We then created malicious code using a website called JSFiddle and then ran that code on MehBank to exploit the vulnerabilities we found. Now, these attacks were far from sophisticated. In fact they could be executed in a few lines of simple Javascript associated with the markup of the webpage that contained a cat picture that was sent to the victim by the attacker. (According to the instructor, the internet is simply an array of intricate tubing used to shuttle adorable cat pictures from one person to another.) The results of running the simple yet ill-intentioned Javascript code allowed us to change the username, password, and other personal information on someone’s banking account.
Reflected XSS Code
In another exercise, we used reflected XSS code to exploit a vulnerability in the search box of the web app. When this Javascript code was executed on the client side, it allowed the attacker to compromise the victim’s cookie session and change the personal information of their banking account. This is the most common type of XSS attack found in the “wild”. In both of these examples, the attacker simultaneously locked the victim out of and took control of their account. Imagine the chaos that would ensue if you were not only unable to have access to your bank account, but also someone else had access to your funds.
Warnings
When designing the front end of a web page, the developer must have the end user in mind. You want your user to flow through the site, experiencing a natural level of interest and engagement. Unlike Google, not every company may have an Information and Assurance Security team extensively combing through their web apps for vulnerabilities. Even if the user’s ignorance about cybersecurity results in their account become compromised, it ultimately falls on the company and its developers to be aware of the potential risks and be responsible for preventing potential attacks. If the user cannot trust the web app, they won’t spend their time or money on it, regardless of the ingenuity of the design.
If a developer is unaware of potential vulnerabilities in the web applications they have designed, theycould be allowing unauthorized users to be able to have access to or modify someone else’s sensitive information. For instance, in the MehBank App, the user has an opportunity to upload an URL when creating a new credit card so that the card has a custom image on it. Although this feature may satisfy users’ needs for the chance to customize their credit card, it could leave them assailable to an attack from a hacker using XSS. If you, as the developer, were conscious to such an event occurring, would you modify the way you would approach implementing this kind of feature to your web app? Would you even take the risk and include it?
The scenarios demonstrated to us in the workshop were executed on a purposely vulnerable app; however, XSS, XSRF, and SQL injection are still very common and relevant forms of attack that occur in actual apps we use today. Even if your app uses a secure protocol (HTTPS) to communicate to the server, malicious attacks, such as DOM-based XSS, can be executed on the client-side only and still compromise a user’s data. It’s essential that companies take extra precautions to keep all information safe in order to maintain trust and integrity with their users.
A Note About SIs
Customers and consultants (SIs) can create just about anything on the Salesforce platform without having to go through a security review. AppExchange products, however, are a bit different in that Salesforce performs a rigorous review (Security Review) on all code within the org to ensure it‘s not susceptible to known threats.
LockerService for Lightning Components
Recently, Salesforce introduced a feature called LockerService for Lightning Components. This is a precaution Salesforce has chosen to take so that they can better ensure customers that they take the safety of their information seriously. By incorporating this feature, Salesforce better sections off the DOM tree and Javascript functions of a Lightning Component so that they function similar to the way an operating system’s kernel mode and user mode functions. This helps prevent the occurrence of XSS attacks, along with other security threats. How can you check that you code is LockerService compliant? Salesforce has provided us with a Lightning CLI tool that can help with that.
Check out our Quick Guide on Defining the Differences in Salesforce Lightning.
Summary
After attending this conference, I learned that despite all of the progress of the internet, it still parallels the uncharted and lawless times of the Wild West when it comes to cybersecurity. Strong efforts are being made by various public and private entities to protect our information from contemporary raiders yet, there still exists uncertainty when it comes to security. For every patch on a newly discovered vulnerability, there is a crafty-minded and adaptive hacker poking around to find another hole to exploit. Being aware of potential breaches should be part of developer best practices to keep the end user safe.
