Modern web development comes with a variety of challenges that developers have to consider, such as accessibility, responsive design, and security. Unfortunately, these things sometimes go overlooked or are outright ignored—especially when it comes to security.
In her web security webinar, Kristina Balaam, Application Security Engineer for Shopify, talks about some basic security fundamentals that every developer should know.
“Security breaches don’t just happen to banks and large corporations,” Kristina says. “I’ve heard so many developers say that they don’t need to worry about security issues because they’re not a target, but the truth is that you never really know if you are.”
According to the Cost of Data Breach study done by IBM in 2017, the average size of data being affected in breaches is increasing, and the odds of an organization being breached are now one in four. And it isn’t just Fortune 500 or publicly traded tech companies that are falling victim—data breaches can affect any organization that exists on the web.
Data is a massive asset to hackers, and they are seeking out more than usernames, passwords, and credit card numbers. So even if you don’t think you’re a target, it’s important to protect yourself and your users from vulnerabilities that may be present in your app. This keeps you and your users safe, and builds trust between you and merchants by showing that you take security seriously.
In this post, we’ll cover the most common vulnerabilities you should be aware of as a developer, and what you can do to ensure your application is secure.
You might also like: What App Developers Need to Know About GDPR.
1. Cross site scripting (XSS)
Cross site scripting, or XSS, occurs when code is injected client-side into legitimate websites that would otherwise be trusted. This allows the attacker to execute malicious code on unsuspecting end users. This type of attack often occurs on web applications that include user input that isn’t validated in some way.
This can allow session cookies to be compromised, which means a user’s session can be hijacked. It can also prompt an install-script for a malicious program, or even spoof content.
There are real dangers to this kind of attack. OWASP (Open Web Application Security Project) gives an example of a spoof-type XSS attack, where the website is a brochure-type app for a pharmaceutical company. By cross site scripting, an attacker could change the dosage information on the page, resulting in an overdose by users. While this example is an extreme case, it does demonstrate how an individual with malicious intent can surface false, harmful information to your app users.
There are various types of XSS vulnerabilities. Below are three common ones, and how to protect your app from them.
A. File upload
According to OWASP, uploaded files represent a significant risk to applications. If a file containing HTML content can be uploaded, the malicious script can be injected via this file, and executed when the file is viewed.
When a file containing malicious script is uploaded to an application, the impact has the potential to be high. The consequences range from complete system takeover to client-side attacks.
How to protect your app: The best way to avoid this vulnerability is to restrict the type of file that can be uploaded. Whitelisting filters, limits on file-size, and validating file content are also effective methods.
B. Stored XSS
This type of vulnerability exists when the injected script is stored on the server. The attack commonly targets websites that allow users to share content, such as forums, social networks, blogs, or message boards. If it’s possible for the attacker to embed their script using HTML in a comment or post, the malicious script will run any time the page is opened.
This is different from a reflected XSS attack (which we will look at next) in that it doesn’t require the end user to actually open a link. Instead, the user only needs to visit the page where the XSS payload is stored and rendered.
How to protect your app: Validate any user inputs, and escape on the server-side.
C. Reflected XSS
Reflected XSS occurs when executable code is injected in an HTTP response. The injected script is not stored on the server, but instead impacts users who are lured into opening a malicious link.
When this happens, the injected code travels to the vulnerable application and reflects the attack back to the user’s browser. The browser then executes the code because it appears to have come from a trusted server.
How to protect your app: Use strict input validation, based on the content that the input is expected to contain.
2. Client-state manipulation
Client-state manipulation happens when the server provides state information to a web-client (browser) that is then passed back as part of an HTTP request from that client.
In Kristina’s web security webinar, she uses this code lab to show examples of the various vulnerabilities that can exist in web applications, including an example of client-state manipulation. This code lab is an excellent resource for understanding how these vulnerabilities work, which will help you to make your own apps more secure.
How to protect your app: In order to be secure, web apps should never trust web-clients, and should always validate input received from them. Hidden inputs should not contain sensitive information and should be validated like any other input, even if the server is generating the information stored in this hidden input. Do not use GET requests for sensitive info. Instead, store a session-id and send that to the client, rather than the actual data value. Use ‘signed states’ and validate any input received from the client, including hidden inputs.
You might also like: 4 Must-Read Shopify Docs to Maximize your Success on the Shopify App Store.
3. Cross-site request forgery (CSRF)
CSRF (also commonly referred to as XSRF) is when an attacker uses an HTTP request to access user information from another site on which they are authenticated. These types of attacks target state-changing requests rather than data theft, since the attacker cannot see the response to the forged request.
An example of CSRF might be changing login credentials, or making a purchase. Because a server isn’t smart enough to see if a request was intentional or not, it simply sees the request and performs it.
How to protect your app: We recommend using tokens. Since unique tokens are difficult to spoof, they can be sent with the request and validated by the site, which prevents attempts at CSRF. You can also validate origin headers submitted with requests. OWASP has a great cheat sheet to help you prevent CSRF.
4. SQL injection
SQL injection is a technique that uses code injection to attack database type applications. Malicious SQL queries are inserted via input from the client to the application. Successful attacks of this type can result in:
- Tampering of existing data
- Disclosure of data
- Destroying the data or making it unavailable
- Voiding transactions
- Spoofing identities
The impact of this vulnerability is only limited to the attacker’s skill and imagination, meaning the impact has the potential to be severe.
You can visit w3schools.com for examples of SQL injection.
How to protect your app: The best way to prevent SQL injection attacks is to use prepared statements with variable binding. This allows the database to distinguish between data and code, regardless of the input submitted. Whitelisting is also a good defence, as it specifies what the input should look like and does not allow input that doesn’t match the specified pattern.
Stay up to date on the latest web security vulnerabilities and how to address them by checking out the resources below:
- Peter Yaworski’s Web Hacking 101 (eBook)
- The Web Application Hacker’s Handbook
- Foundations of Security: What Every Programmer Needs to Know
- OWASP Podcast
- The Cyber Wire Podcast
- Smashing Security Podcast
- Stanford’s Advanced Computer Security Certificate
- Ryerson’s Digital Forensics & Cryptography certificate
An evolving world of cyber threats
For web apps of all sizes, it’s important to be aware of web security risks, and take the necessary precautions to avoid attacks.
Remember, falling victim to even the smallest breach is not just a headache for you—it also disrupts your merchants’ workflows, and can erode the trust they have in your app.
Be staying on top of website security trends and taking precautions to keep your app’s data secure, you’ll significantly increase your chance of developing a trustworthy, stable app that merchants can count on.
What steps have you taken to stay secure? Share your experiences in the comments below!