- 7 mins
What AppSec Can Learn from Cloud Security
In cloud computing, some of the responsibility for security lies with the cloud provider, and some lies with the cloud account owner. This shared security model can be unclear compared to the days when companies ran their own data centers—you have to expect to have some crossover of responsibility. Software security works the same way.
What a Shared Security Model Means
Even in small software products, there can be cases where security is pushed to the end user, down to the user interface, or even reside on the backend service. To demonstrate how this works, let’s look at a simple example application that:
- Ingests data
- Displays the data in a UI
- Allows another user to export the data to a CSV
Cases of Server Side Responsibility for AppSec
SQL Injection
Description: Upload data into a SQL database.
Input: The inputs can be CSV, JSON, or XML. The source of the data can be from a user file upload, REST API Call, or typed into a UI.
Output: Data is loaded into the database.
Assumptions: Data is validated to conform to business rules. Some of the fields allow content of any kind.
Image credit to SQLshack
The security control needs to be implemented in the backend prior to storing the data, since it has more knowledge of the storage methodologies and can provide the most accurate controls. It can do this by analyzing the files for input validation, then building the database queries with parameterized queries to prevent any crossover between the data plane and the control plane of the SQL commands.
Cross Site Scripting
Description: The User Interface requests data from the backend that is stored in a database.
Input: A returned web page with a content type of “application/html”.
Output: A web browser is to display the content.
Assumptions: This is the old school style of displaying data. The backend server isn’t using a REST API. The data being returned was validated for complying with business requirements.
The responsibility here lies with the backend that generates the HTML. This servlet request must use valid HTML escaping techniquest to protect the client. In this case, the client has no opportunity to protect itself because it has no concept of the data and control planes in the page sent back from the server.
CSV Injection Attack - Backend Responsibility
Description: The User Interface uploads a CSV to be processed by the backend. The file can either be saved or re-generated to be viewed by support staff.
Input: A CSV file.
Output: The data is uploaded. Success is irrelevant. The file can be saved or not.
Assumptions: The support staff has the ability to generate or pull the CSV.
In this case, we know how the data will be used. The only reason to view it is to evaluate whether it’s accurate or what might have triggered an error. As a result, we can expect that there must be some protection for the support staff.
This can be done in a few ways:
- Restrict or train support staff to use a simple text-based tool to view the data.
- Prevent macro execution in more complex spreadsheet tools.
- Encode the CSV appropriately to provide more protection, if the data is returned from an API endpoint which only the support staff can access.
Cases of User Responsibility for AppSec
Cross Site Scripting
Description: The User Interface requests data from the back-end that is stored in a database. The goal is to display it in a grid.
Input: Data is returned from the application using “application/json”.
Output: JSON format of data.
Assumptions: The backend is a REST API which was designed to speak to many types of clients. The calling client is a React front end. The data being returned was validated for complying with business requirements.
Here, there’s no guarantee on what the end client ultimately is, which makes it hard to determine appropriate security decisions. Any of the data being sent to the calling client could be made inaccurate by the API encoding it. The UI or user needs to perform the appropriate security protections.
CSV Injection Attacks
Description: The User Interface requests data from the back-end that is stored in a database for downloading a CSV.
Input: Data is returned from the application using “application/csv” with the appropriate content disposition header.
Output: A downloaded file with the output.
Assumptions: The backend is a REST API which was designed to speak to many types of clients. The calling client is a React frontend. The data being returned was validated for complying with business requirements.
In this complex attack, the CSV files are opened in various spreadsheet apps and execute macros. OWASP even notes that these vulnerabilities are often excluded from bug bounty programs, but this doesn’t mean that third party pen testers won’t try to report it. Like the JSON dataset, it’s unknown what will read the data or how it’ll be used. So while it would be expected that the client would be responsible for securely reading the data, it would also be wise to provide guidance to the end user receiving the file.
Cases of Cloud Owner Responsibility for AppSec
Access Control Bypass
Description: A CSV file with sensitive data resides on a cloud storage device (e.g. S3 bucket)
Input: A CSV file.
Output: The data is successfully uploaded to the cloud storage.
Assumptions: Cloud storage access set to public, but naming scheme is complex
Authentication and authorization controls can be cumbersome. Sometimes, software owners try to create security through obscurity so they can have fewer interactions with IT admins and reduce complex controls. In this case, anyone can access a file at any time, so cloud owners must take responsibility by implementing appropriate access controls, standards, infrastructure as code, and automation.
Cases of Cloud Platform Responsibility for AppSec
Server Side Request Forgery
Description: Leveraging automation and cloud services in a shared tenant environment.
Input: A cloud service which requires a URL.
Output: The service is running on shared resources within the cloud platform.
Assumptions: The service runs as expected.
Autowrap is an example where the cloud platform itself is ultimately responsible for the security control. While there are things an application owner could do to prevent the type of attack that took place, ultimately the cloud platform should have provided better protections around unauthorized access to other tenants’ information.
Fewer Assumptions Lead to Better AppSec
Many systems and people use and have access to any given piece of software, with more complexity and interconnectivity getting added all the time. With so many variables in place, adopting a shared security model for AppSec which has more overlap and fewer assumptions is vital for everyone involved.
And this means that software security professionals, whether they’re the DevSecOps team working with developers, a third party penetration tester coming in after the fact, or a vendor of software tools, must all adapt to this new model too.
Unsure of How Your AppSec Stacks Up?
The software security experts at True Positives keep up with these changes to advise and consult on AppSec, connect you with automation tools that help you avoid vulnerabilities, and manually test environments for breaches.
Contact us today for a free 1-1 AppSec consultation.
