Mass Assignment
Introduction.
Software frameworks sometime allow developers to automatically bind HTTP request parameters into program code variables or objects to make using that framework easier on developers. This can sometimes cause harm.
Attackers can sometimes use this methodology to create new parameters that the developer never intended which in turn creates or overwrites new variable or objects in program code that was not intended.
This is called a Mass Assignment vulnerability.
Alternative Names
Depending on the language/framework in question, this vulnerability can have several alternative names :
- Mass Assignment: Ruby on Rails, NodeJS.
- Autobinding: Spring MVC, ASP NET MVC.
- Object injection: PHP.
Suppose there is a form for editing a user's account information:
Here is the object that the form is binding to:
Here is the controller handling the request:
Here is the typical request:
And here is the exploit in which we set the value of the attribute isAdmin of the instance of the class User :
Exploitability
This functionality becomes exploitable when:
- Attacker can guess common sensitive fields.
- Attacker has access to source code and can review the models for sensitive fields.
- AND the object with sensitive fields has an empty constructor.
GitHub case study
In 2012, GitHub was hacked using mass assignment. A user was able to upload his public key to any organization and thus make any subsequent changes in their repositories. GitHub's Blog Post .
- Whitelist the bindable, non-sensitive fields.
- Blacklist the non-bindable, sensitive fields.
- Use Data Transfer Objects (DTOs).
General Solutions
An architectural approach is to create Data Transfer Objects and avoid binding input directly to domain objects. Only the fields that are meant to be editable by the user are included in the DTO.
Language & Framework specific solutions
Whitelisting.
Take a look here for the documentation.
Blacklisting
Nodejs + mongoose, ruby on rails, php laravel + eloquent, jackson (json object mapper).
Take a look here and here for the documentation.
GSON (JSON Object Mapper)
Take a look here and here for the document.
JSON-Lib (JSON Object Mapper)
Flexjson (json object mapper), references and future reading.
- Mass Assignment, Rails and You
Authors and Primary Editors
Abashkin Anton - [email protected]
results matching " "
No results matching " ".
All our recent updates - from new features to enhancements!
August 30th, 2024
New Hacking Challenge 🎉
Hack the gradebook.
It's been a while since we launched a new hacking challenge, but the wait is over. Traditionally, hacking challenges—like capture the flag exercises—have been known for their high difficulty and focus on a single vulnerability. However, the Hack the Gradebook challenge is different. This challenge requires learners-turned-hackers to exploit multiple vulnerabilities, all covered by our OWASP Top Ten curriculum, reinforcing key concepts in a hands-on way.
Learner are presented with the login page for an old-school gradebook application inspired by the 1983 Movie WarGames. Check it out here .
May 3rd, 2024
New OWASP Alternative Path 🎉
You asked and we delivered! Our new OWASP Top Ten | Alt 1 course delivers comprehensive lessons aimed at deepening developers' understanding of critical security principles. This can be used alongside the original OWASP Top Ten course or as the next step in their learning. This course introduces alternative lessons that address new Common Weakness Enumerations (such as use of hard coded credentials, overreliance on cookies, authentication bypass by spoofing and others) and offers innovative solutions to strengthen applications against potential attackers.
To learn more, check out our Help Desk article .
January 25th, 2024
Additional Language Support 🎉
Our content team added Ruby to 8 more of our lessons:
Encoding (Cryptography)
Encryption (Cryptography)
Hashing (Cryptography)
Account Lockout (Credential Reuse)
CAPTCHA (Credential Reuse)
Persistant Cookies (Credential Reuse)
Device Fingerprinting (Credential Reuse)
Encoding, Hashing and Encryption (Credential Reuse)
January 18th, 2024
Content Improvements 💪
We continue expand our language support for our lessons:
Security Misconfiguration now supports Ruby
Unsafe Consumption of APIs is available for C++
Unrestricted Access to Sensitive Business Flows is now available for Rust, Perl, C and C++
December 8th, 2023
Updated OWASP API Top Ten 🎉
Our team has been busy and we are ending the year with an important update to the OWASP API Top Ten to be in alignment with the changes made this year!
This includes:
Updated and new Break/Fix lessons:
Broken Object Level Authorization
Broken Authentication
Broken Object Property Level Authorization
Unrestricted Resource Consumption
Broken Function Level Authorization
Unrestricted Access to Sensitive Business Flows
Security Misconfiguration
Improper Inventory Management
Unsafe Consumption of APIs
What will happen to the old API Top Ten course on HackEDU?
It will disappear. The following will happen:
The old API Top Ten course will be hidden.
The old preset plan will be disabled.
A new API Top Ten course will be created.
A new preset plan will be created.
What will happen to HackEDU learners that have been assigned a training plan containing content from the previous course?
Nothing. They will still see their existing training plan. The content will no longer appear in the "All Training" section but will continue to appear in the learners "My Plan" section.
October 6th, 2023
Content Improvements 🚨
We continue expand our language support and you can now use C++ and Kotlin when completing our Credential Reuse lessons .
You can now choose C++ when completing Encoding, Hashing, and Encryption , too .
September 29th, 2023
We continue expand our language support and you can now use C++ when completing:
Persistent Cookies (Credential ReUse)
Device Fingerprinting (Credential ReUse)
We've also added Perl & PHP as language options when completing:
Information Exposure through Query String Parameters
September 9th, 2023
New Content Alert 🚨
We've released a new Break/Fix lessons this week! Information Exposure through Query String Parameters : Lesson showcasing information exposure through query string parameters.
August 3rd, 2023
We continue expand our language support and you can now use C++ when completing these Cryptography lessons:
August 1st, 2023
We've just released new content that covers Credential Reuse and you can find it within our Web Application Security (Extended) Course .
These four lessons will teach you techniques for preventing credential reuse and credential stuffing attacks:
Multi-Factor Authentication
Persistent Cookies
Device Fingerprinting
Account Lockout
July 12th, 2023
Diffie-Hellman Key Exchange
We also made some updates to Insufficient Cryptography Lesson (iOS & Android) and OAuth Implementation Vulnerabilities: Part 2.
July 6th, 2023
Encoding (Cryptography Course)
We also made some updates to our Server Side Request Forgery (SSRF) lesson from the OWASP Top 10.
June 15th, 2023
Secure Password Storage: Part 2
Secure Password Storage: Part 3
Identification and Authentication Failures
May 3rd, 2023
We continue expand our language support and you can now use Kotlin when completing:
OWASP Top 10
Broken Access Control
Command Injection
Insecure Design
OAuth: Part 1
OAuth: Part 2
SQL Injection: Part 1
SQL Injection: Part 2
SQL Injection: Part 3
Secure Side Request Forgery
Reflected Cross-Site-Scripting
Stored Cross-Site-Scripting
Excessive Data Exposure
Mass Assignment
Cryptography
Encoding, Hashing, and Encryption
Digital Signatures
Secure Password Storage: Part 1
April 12th, 2023
We improved our Hashing lesson tests. The Hashing Lesson now verifies that the hash a learner inputs is:
of a fixed length
deterministic
collision resistant
April 3rd, 2023
Our Engineering team was busy making some updates to our content! This week we released:
Updated the example for C# in SQL Injection: Part 1
Fixed an error with the Ruby code in Insecure Design
Added a narrative solution in the Java Spring Coding Challenge for Broken Authentication
Fixed an issue with SSRF Coding Challenge in #C
Fixed an issue with Clojure tests in our Mass Assignment lesson
March 28th, 2023
New Feature & Content Improvements 🚨💪
We have a new data integration with HCL AppScan available in the HackEDU Platform. To learn more about this feature and the benefits, check out this article !
Additionally, we've added C as an option when completing the Hashing lesson !
March 6th, 2023
New Content Alert & Improvements 🚨
We've added a new lesson to our Cryptography Course ! It's called Digital Signatures and it teaches engineers how to use digital signatures to ensure the integrity of messages!
Additionally, we continue to expand our language support and you can now use Scala in these Cryptography lessons:
Encoding, Hashing and Encryption
February 10th, 2023
January 23rd, 2023
Reflected Cross-Site Scripting (XSS)
Stored Cross-Site Scripting (XSS)
You can now use C when completing:
Server Side Request Forgery (SSRF)
To review the full list of HackEDU Break/Fix lessons visit: https://app.hackedu.com/all
January 11th, 2023
Our Help Desk article URL was updated from https://help.hackedu.com/en to https://help.securityjourney.com/en to be more in alignment with our branding changes! Any URLs still using the previous domain will be redirected.
January 5th, 2023
Happy New Year from the Security Journey team! We are starting the year out strong with Rust language support being added to the following lessons:
SQL Injection: Part(s) 1-3
Server-Side Request Forgery
Store Cross-Site Scripting (XSS)
Secure Password Storage: Part(s) 1-3
December 19th, 2022
We are excited to announce that our 9 lesson Cryptography Course is now live in the HackEDU Platform! This content can be added to any current or new Training Plan or assigned as a stand alone course.
The lessons include:
Diffie-Helman Key Exchange
Padding Oracle
December 5th, 2022
We continue to add C language support! You can now use C when completing:
Server Side Request Forgery
November 2th, 2022
We are excited to share that we've added C language support in more lessons this week! You can now use C when completing:
XML External Entities (XXE)
October 7th, 2022
HackEDU now has a Hands-on Blockchain Security lesson which compliments our new Blockchain content in the Security Journey Platform. It's available to be added to any new or existing Training Plan. It's located under our Publicly Disclosed Vulnerabilities course. Check it out ! We also added C language support to the Reflected Cross-Site Scripting (XSS) Lesson!
September 29-30th, 2022
Improvements 💪
We resolved some issues in two of our lessons.
Insecure Design : Our content team updated the hint for Step 4 - Remediation to make it clear that authorize() returns a promise.
Command Injection : A function was changed to return the error (if any) from running the exec.Command function.
September 21st, 2022
We've updated the messaging in our in-app cookies banner to make it more clear to learners and admins what data we collect and why. It now reads: " Our Platform uses cookies to customize your learning experience, however we do not sell any user data. To learn more, please see our privacy policy . "
September 15th, 2022
The following emails from the HackEDU Platform will now be sent from our Security Journey domain:
Password reset
Account Verification
Reminder emails (training assignments)
Onboarding Invitations
All emails will now come from [email protected] .
September 14th, 2022
The HackEDU Platform now supports session timeout. Admins and learners will be logged out of the Platform after 1 day of inactivity. Here, inactivity means that the UI is still open and idle - not that the session tab has been closed. This is how the Security Journey Platform functions so customers will have a consistent experience.
Our latest course, Secure Password Storage is live in the HackEDU platform! These three lessons will teach you how to:
Understand the basics of hashing passwords
Learn how to create and incorporate salts into hashes
Use Argon2 to simplify and strengthen the authentication process
If you would like to take this course or assign it out to your learners it's located under the Web Application Security (Extended) Course!
September 2nd, 2022
Updates and Improvements 🚨💪
Companies who are using SSO & deep-links will now see users being redirected to the initially requested URL after authentication - instead of the "My Plan" or "All Training" page.
We've also updated our branding in the HackEDU Platform to the new joint Security Journey + HackEDU logo!
August 22nd, 2022
Updates and Content Improvements 🚨💪
Our team updated the Safelisting Requirements for our live sandbox application and Platform. For more details, see this Help Desk article . We also made some changes to our Mass Assignment lesson to improve the learner experience when taking the coding exercise at the end.
August 17th, 2022
HackEDU is now Security Journey 🎉
Our transition from HackEDU to Security Journey is well underway! Our HackEDU site now redirects to securityjourney.com. You can find out more about the acquisition and rebrand here !
As you navigate the platform, you’ll likely notice updated Security Journey branding throughout. Rest assured, even though we may look a little different, you’ll still have all the same functionality and features as before.
Should you have any questions along the way, reach out to your Customer Success Manager or drop us a line at [email protected] anytime.
August 12th, 2022
You now have the ability to enable/disable Hacking Challenges just like you can with Coding Challenges. We also added some additional help text to these Admin settings to more clearly define what they do!
August 9th, 2022
Content Update 💪
Our Content Engineers updated the vulnerability code and lesson text in all three SQL Injection lessons as well as in the Functional Level Authorization lesson.
August 5th, 2022
Resolved an issue which was causing the start dates and due dates on our Secure Development Training: 1-Year Plan to be incorrect.
August, 1st, 2022
The HackEDU team wrapped work on updating our lesson infrastructure to improve user experience and performance.
July, 26th, 2022
The HackEDU team updated the XSS in Third-Party Integration (English only) lesson and hacktivity so that the vulnerability and recommended fix were easier to understand.
We also updated our four Memory Managment Lessons (Stack Overflow, Off-By-One, Format String & Heap Overflow) by creating a new vulnerable app and rewriting the lesson text to make things clearer to learners.
July, 18th, 2022
We updated our Security Unit Tests lesson: Restructured app so we can unit test without starting up a live Flask server & added "File Browse" feature.
We corrected a UI issue that was causing our edit buttons on the Users page and "Start Lesson" button to get squished when resizing the browser.
July, 1st, 2022
UI Refresh 👀
Our website's login page and Platform navigation bar now feature the new joint Security Journey + HackEDU logo. Additionally, all of our buttons and links have been updated from blue to green!
June 30th, 2022
Training Plan Improvements: Updated Phase Names 🎉
We discovered that for some of our Preset Training Plans the "phase title" was different from the course title. This was causing unnecessary confusion for Training admins and learners. Now, the phase titles match the Course title:
2021 OWASP Top 10
Old Phase title: Web Application Security
New Phase title: 2021 OWASP Top 10
PCI Compliance
New Phase title: PCI Compliance
OWASP API Top 10
Old Phase Title: API Security
New Phase Title: OWASP API Top 10
June 24th, 2022
New Preset: DevSecOps Preset Plan 🎉
Today, we introduced a brand new training plan to our available presets!
Our DevSecOps training plan is made up of 26 lessons and articles that cover all stages of the DevSecOps lifecycle: Pre-Development, Development, Testing, Deployment and Ongoing maintenance. Although it is a preset, content can be added or removed as needed to meet the specific training needs of your organization.
Today, we released "Kubernetes Security" which is the final lesson in our DevSecOps course! You can find it under the DevSecOps Course in the HackEDU Platform.
June 16th, 2022
New Language Support: TypeScript 🚨
We are so excited to announce the availability of TypeScript as a language! It is now live in 18 of our lessons.
June 14th, 2022
The following lessons had updates to their instructions/text this week:
OAuth Implementation Vulnerabilities
Docker Secret Handling
We also resolved an issue with the Capital One: Part 3 which was causing learners to receive an "import error" when trying to complete the lesson.
June 8th, 2022
Updates this week | New Article & Improvements 🚨💪
HackEDU released the Penetration Testing article which is our final piece of content for our NEW DevSecOps course. You can find the complete course list by visiting All Training > DevSecOps
We also fixed an issue with our user management workflow which was causing the delete function to become unresponsive when attempting to delete multiple users in a row.
June 2nd, 2022
Today, we added four more articles as part of our DevSecOps course which is comprised of 26 pieces of content. You can find these located under All Training > DevSecOps
Security Acceptance Testing
Threat Intelligence
Security Smoke Tests
Blameless Post Mortems
June 1st, 2022
Updates to the All Training Page 🎒
We've updated the DevSecOps Course content into the following sections:
Pre-Development
Development
May 24th, 2022
Login Enhancement ✨
Our team has improved the sign in workflow! All users can now hit ‘enter’ when entering their email and password to login. Previously, we did not support this and you had to manually click into each form to add your information.
May 19th, 2022
All Training UI Update 🚨
HackEDU has renamed the "General Security" section of the "All Training" page to "DevSecOps". The content found in that section will be turned into a Training Plan preset once we've completed all the content for our DevSecOps course.
May 5th, 2022
Today, we released a new article called "Server Hardening."
Included as part of our DevSecOps course. You can find it under the All Training > General Security course list .
April 12th, 2022
Updates to HackEDU's openAPI 💬
You asked and we delivered!
Our openAPI now provides the ability to retrieve license status for users. For full details, see our Developer Documentation here .
April 11th, 2022
Today, we added four more articles as part of our DevSecOps course which is comprised of 25 pieces of content. You can find these located under All Training > General Security
Secrets Management
IDE Plugins
Security Code Review
Introduction to Git Hooks
Do they have coding exercises?
Articles, unlike lessons, do not have a coding exercise or sandbox environment.
Are they assignable?
Yes, they can be assigned as part of a training plan or individually from the user view.
What reporting can I expect?
Articles will have similar reporting to lessons. You can expect to see the time it took for an individual learner to complete an article and view this information in their user report card, the User Report or the Completion report.
April 8th, 2022
New Training Plan Interface 🚨
We rolled out a fresh new look for our Training Plan modal!
Improvement: Checkboxes for creating and editing training plans 💪
The existing drag and drop experience for creating/managing a training plan was cumbersome and had a few issues. We’ve simplified the experience to make it even simpler to create a training plan!
March 17th, 2022
New Preset: Secure Coding Training: 2 Year Plan 🎉
Today, we introduced a brand new training plan to our available presets.
This training plan is made up of 58 lessons over 24 months and focuses on a core set of secure coding best practices and the Open Web Application Security (OWASP) Top 10 vulnerabilities. These lessons are seen as the most critical secure coding training content to keep your organization safe!
This course was created to help customers plan content for years one and two of their secure coding training plan. Although it is a preset, it is able to be edited or adjusted to account to the specific training needs of each customer.
For more information, visit here .
March 4th, 2022
New Lesson Alert! 🚨
Dependency management lesson.
This brand new lesson adds to our DevSecOps course!
Learners will be taught to:
Understand the Phases of Dependency Management:
Enumeration
Investigation
Remediation
Search through source code for a vulnerable dependency
Exploit this dependency in a running app
Remediate the vulnerability and check that the exploit is no longer possible
Available today on the HackEDU Platform under All Training > General Security
March 3rd, 2022
Introducing our new Impact Report 🎉
This report displays vulnerabilities found in your code alongside assigned secure development training to show alignment and impact of Adaptive Training Plans and Application Security Testing Integrations .
What are the benefits?
Allows Learning Administrators to ensure training programs are efficiently addressing current organizational needs
The Report can be shared with internal stakeholders to show the importance of secure coding training programs and their ability to reduce application security risk
The data can be displayed in a customized timeframe, monthly or annually. Filters allow views by vulnerability topic or across the entire training plan all at once.
For more information visit here .
January 25th, 2022
New + Improved OWASP Top Ten 🎉
New content: OWASP Top 10 2021
OWASP has come out with an updated list of top vulnerabilities. Specifically, the addition of Server-Side Request Forgery (SSRF) and Insecure Design
We've added two new lessons that cover SSRF and Insecure Design to our 2021 OWASP Top 10 Training Plan; these can be assigned as part of the new preset plan or as standalone lessons
Existing content was updated with * new names
Sensitive Data Exposure ⇒ Cryptographic Failures
Using Components with Known Vulnerabilities ⇒ Vulnerable and Outdated Components
Broken Authentication ⇒ Identification and Authentication Failures
Insecure Deserialization ⇒ Software and Data Integrity Failures
Insufficient Logging and Monitoring ⇒ Security Logging and Monitoring Failures
*The content description will denote that the names have been updated
XSS Lessons Part 1 & 2 were replaced with Reflected Cross-Site Scripting (XSS), DOM-Based Cross-Site Scripting (XSS) and Stored Cross-Site Scripting (XSS)
Updated preset plans
Option to assign 2017 OWASP Top 10 or 2021 OWASP Top 10 2021
- Browse topics
SNYK LEARN LOGIN
- 🌍 Snyk (recommended)
OTHER REGIONS
For Snyk Enterprise customers with regional contracts. More info
- 🇦🇺 Snyk AUS
Mass assignment
Be careful with parameters that are automatically bound from requests to objects, select your ecosystem, mass assignment: the basics, what are mass assignment vulnerabilities.
To make it easier to save data submitted via an HTML form into a database or object, many web application frameworks have included libraries to automatically bind HTTP request parameters (typically sent via forms) to the fields of database models or members of an object, requiring only minimal coding.
Let’s say we have a (very simple) HTML form:
When the form is submitted to the web application, it will send the form data as HTTP request parameters, and the backend code will have to read each parameter individually into a corresponding variable. Then, once all the fields have been read, the application will usually execute a database update or insert operation to save the data.
Mass Assignment makes it possible to write less code to handle this process - think about how much coding this technique could save if it was an object that had dozens of fields, and multiply this across a complex application that has many of these objects in its database.
Mass assignment vulnerabilities occur when the database model that is being assigned contains security-relevant fields, and the application user can supply values in the POST request that are saved to those fields, even though they are not present in the HTML form.
For example, if the User model contained a field isAdmin: Boolean , the user could add the POST body parameter isAdmin=true and make themselves an administrator.
For this to occur, an attacker would need to guess the names of the sensitive fields, or the source code for the vulnerable application would have to be available to the attacker (allowing them to see what sensitive fields are present in the data model).
Impacts of this attack can include bypassing authentication or authorization logic or elevation of privilege. This could then result in the destruction or disclosure of data within the application.
About this lesson
In this lesson, you will learn how mass assignment vulnerabilities work and how to protect your applications against them. We will begin by exploiting a Mass Assignment vulnerability in a simple application. Then we will analyze the vulnerable code and explore some options for remediation and prevention.
Mass assignment in the wild
In 2012, a GitHub user exploited a Mass Assignment vulnerability in GitHub’s public key update form. The flaw allowed the user to add their public key to another organization they were not a member of. The user added their key to the Ruby on Rails organization. To demonstrate proof of the exploit, the user added a file to the Rails project repository. GitHub responded, quickly fixing the vulnerability and they conducted a wide audit of their code to ensure the issue was detected and fixed if it existed anywhere else.
Mass assignment in action
New SaaS startup SuperCloudCRM recently launched their web platform designed to help businesses boost their sales and marketing efforts.
Setting the stage
SuperCloudCRM recently launched its web platform. Unfortunately, they suffered a security breach, resulting in data being leaked. What went wrong?
Mass assignment details
As mentioned, SuperCloudCRM’s developers had been logging request data for API endpoints like the POST /user/create endpoint, which creates new user accounts when a user submits the signup form.
A typical JSON payload in the request sent to the /user/create endpoint was supposed to look like this:
But a search of the /user/create endpoint’s logs for the [email protected] account around the time the user was created, found JSON POST data starting with the following excerpt:
It was different to the normal requests, and had a long request body with dozens more fields all starting with the letter r . What was the attacker doing? All of these weird field names that weren’t part of the user model schema, which was:
After doing some testing like the scenario above showed, a few things were discovered.
First, the new user account’s password was apparently being saved to the database in plaintext. Not good! But what stuck out was that the application ignored the non-existent fields and just assigned the fields that were actually part of the User model schema.
The data from the new User document was sent back to the API client and the attacker could then infer which of the list of fields starting with r were part of the User model schema, because if a field existed it was saved and echoed back in the response with the other user data.
A search of the /user/create endpoint’s request log entries around the same time revealed that thousands of similar requests had been sent. Each request testing lists of possible field names in the User model schema.
It was concluded that the attackers had brute-forced HTTP requests with various field name guesses to enumerate the organization and role fields in the schema. Despite them not being referred to anywhere in the client-side JavaScript code, the attackers were able to discover these security-related field names.
So, if the attackers knew these field names, what would they do then? Well, this could have led to a possible mass assignment attack. After hours of reviewing logs for the POST /user/create and POST /user/update endpoints the incident response team found dozens of requests had been submitted to the application, which looked similar to:
The requests appeared to be successful. Each of the requests changed the organization to a different customer, essentially giving the attackers access to each of them as admins. The last request was:
This seemed to explain why [email protected] was an administrator in the Cowmoo Industries organization.
By exploiting this mass assignment vulnerability and adding themselves as the administrator for various customers, the attackers were able to access the organizations’ data within SuperCloudCRM and steal it.
Mass assignment by different names
The concept of mass assignment is known by different names in various programming languages or frameworks. NodeJS and Ruby on Rails call it mass assignment. It is referred to as autobinding in Java Spring MVC and ASP NET MVC. PHP calls it object injection.
Mass assignment under the hood
Let’s have a look at this vulnerable application in more detail by going through the server-side code.
The schema for the User model is defined here, with the user’s credentials, email address, plus their role and organization they belong to. During signup, the credentials and email address are the only values that are supposed to be supplied by the user and accepted by the application.
Firstly, let's recap what took place in the example above.
- The User schema consisted of several fields: username, password, email, role and organization.
- Only the username, password and email fields were sent from the web browser to the /user/create endpoint
- The API endpoint used mass assignment to blindly assign any field from the POST request’s JSON data to the User model in the database (if the field existed in the User schema).
- The attackers were able to determine the names of security-related fields in the schema (role and organization)
- The attackers could supply arbitrary values for these fields when creating or updating a user account
- This let the attackers add themselves to other organizations and elevate their privileges to those of an administrator
Here ( $user = new User($request->post()); ), the endpoint creates a new User object and in doing so, passes all contents of the POST request to the constructor. PHP can “smartly” figure out which parameters go to which attributes of the class; however, this isn’t so smart when those attributes are certain things that shouldn’t be assignable! Even if the form only accepts inputs with username , password and email , a malicious actor can guess the other forms and simply add those fields to the JSON manually. As PHP has no way of discerning what it receives from “good” and “bad”, it simply updates them all. If only there were a way to tell PHP exactly which fields we don’t want to be assignable like that!
Impacts of mass assignment
By exploiting mass assignment vulnerabilities, a malicious actor could create multiple security problems including
- Data tampering : Attackers can modify sensitive information in the database, such as password or account balance
- Data theft : Attackers can gain access to confidential information stored in the database
- Elevation of privilege : Attackers can manipulate the properties of an object to gain additional privileges, such as administrator access
- Unauthorized access : Attackers can manipulate the properties of an object to gain unauthorized access to sensitive resources
Scan your code & stay secure with Snyk - for FREE!
Did you know you can use Snyk for free to verify that your code doesn't include this or other vulnerabilities?
Mass assignment mitigation
Use an allowlist of fields that can be assigned to.
Most mass assignment libraries or helper libraries should provide the ability to restrict the fields that will be read from a request and assigned to the data model. By restricting the assignment of user-supplied fields to only fields in the schema that are known safe ones, the values of security-sensitive fields will be prevented from tampering.
Using this strategy, the code for the application would be changed to add an allowlist using the pick() method of the underscore package and listing the allowed fields in the userCreateSafeFields array:
Laravel provides a library, eloquent , which, among other things, introduces object injection protection features! It gives you the ability to indicate variables that can be assigned, or otherwise, you can indicate variables that you don’t want assignable. This means that when you use mass assignment to populate a class with request data, the Laravel backend can (with your guiding hand) separate POST request input data from fields that should be populated and those that should not!
Using this strategy, the code for the application can be changed to add an allow-list of class attributes, enforcing that only these will be updated:
Use a Data Transfer Object (DTO)
Another option is to create an intermediary object (the DTO) that only has safe, assignable properties, which would be a subset of the target object that has those same fields plus any sensitive fields. Using our User example, the DTO would be:
The mass assignment operation can assign any user-supplied data to the DTO without the risk of inadvertently assigning any sensitive fields. The DTO can be copied to the final object, and during this process, any sensitive fields can be set to secure default values.
This method might require much more coding though. DTOs need to be created for all classes with sensitive fields. If there are many schemas with sensitive fields that require corresponding DTOs, then this becomes nearly as much work as not using mass assignment.
Use a denylist to declare fields that can’t be assigned to
The opposite of using an allowlist to define fields that are allowed to be assigned is to use a denylist of fields that shouldn’t be assigned. Security wisdom says to use allowlisting over denylisting because it’s safer to accidentally not include a safe field than to accidentally omit a dangerous field. So, following this advice, a denylist would be the less preferred option of the two. If there are 50 fields in a schema and only one is security-sensitive, then it is obviously much quicker to just denylist the one sensitive field. The danger here though would be if additional sensitive fields were added to the schema later and the developer forgot to add them to the denylist, then you would have a mass assignment vulnerability.
To use denylists, the code for the application would be changed in a similar manner to the code shown in the allow-list strategy shown earlier, except it would use the omit() method of the underscore package and listing the disallowed fields in the userCreateDisallowedFields array:
To use deny-lists, the code for the application would be changed in a similar manner to the code shown in the allow-list strategy shown earlier, the only difference being the User class is changed to have a “hidden” array:
Utilize a static analysis tool
Adding a static application security testing ( SAST ) tool to your devops pipeline as an additional line of defense is an excellent way to catch vulnerabilities before they make it to production. There are many, but Snyk Code is our personal favorite, as it scans in real-time, provides actionable remediation advice, and is available from your favorite IDE.
Keep learning
To learn more about mass assignment vulnerabilities, check out some other great content:
- OWASP guide to mass assignment vulnerabilties
- Find mass assignment in our top 10 list
Congratulations
You have taken your first step into learning what mass assignment is, how it works, what the impacts are, and how to protect your own applications. We hope that you will apply this knowledge to make your applications safer.
What is mass assignment?
Mass assignment is a type of security vulnerability that occurs when an application code allows user-provided data to be used to set properties on an object without verifying that the user has the right to do so.
What to learn next?
Insecure default variable initialization, uncaught exception, insufficient encapsulation.
IMAGES
VIDEO