Web Security Fundamentals: What Every Developer Should Know

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.

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.

Additional precautions

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.

An example showing a vulnerable HTML form using the GET method, with a hidden input for the price.

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.

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.

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.

Keep Learning

Stay up to date on the latest web security vulnerabilities and how to address them by checking out the resources below:

Thanks for subscribing

About the Author

Samantha Shea is a Content Marketer for the Shopify Apps Team, as well as a front end developer and wannabe ethical hacker. When she's not writing about web development, she dabbles in poetry and dance.