CWE-915: Improperly Controlled Modification of Dynamically Determined Attributes

CS681-Essay Proposal_Improper Input Validation in Spring Boot.md

@@ -0,0 +1,128 @@
+## Introduction
+Many Spring Boot applications rely on automatic JSON-to-object binding to map incoming HTTP requests into Java classes. While this feature simplifies development, it can introduce serious security risks when applications bind user input directly to entity classes containing internal fields such as administrative flags or privileged attributes. When these fields are unintentionally exposed, attackers can manipulate values that developers never intended to be user-controlled.
+
+This weakness is closely associated with CWE categories involving improper input validation and mass assignment. It has appeared in multiple Spring-based projects that rely heavily on automatic data binding. This case study explains how this vulnerability arises, how it can be exploited, and which secure coding practices are necessary to prevent it.
+
+## Software
+- **Name:** Spring Boot  
+- **Language:** Java  
+- **URL:** (https://github.com/spring-projects/spring-boot)
+
+## Weakness
+- **CWE-915:** Improperly Controlled Modification of Dynamically Determined Attributes  
+- **Related:** CWE-20 (Improper Input Validation), CWE-522 (Unprotected Fields)  
+
+This weakness occurs when software allows users to modify object attributes that were intended to be internal-only. In frameworks that support automatic data binding, such as Spring MVC, attackers can submit JSON payloads containing fields that match attribute names inside entity classes. If developers do not explicitly restrict which fields may be updated, attackers can override protected values and cause privilege escalation or unauthorized behavior.
+
+## Generic Example
+
+### Entity Structure
+```java
+public class User {
+    public String username;
+    public String email;
+    public String admin;
+}
+API Endpoint for JSON Invocation
+java
+Copy code
+@PostMapping("/update")
+public User update(@RequestBody User user) {
+    return userService.save(user);
+}
+Malicious Payload
+json
+Copy code
+{
+  "username": "Sakthi",
+  "email": "abc@gmail.com",
+  "admin": "yes"
+}
+Because Spring’s data binder accepts all matching fields by default, a regular user can assign themselves elevated privileges by setting admin = "yes". Without restrictions or validation, confidential areas of the application become accessible.
+
+Vulnerability
+This case study examines an open-source Spring Boot project demonstrating this vulnerability. Specifically, the vulnerability exists due to the following conditions:
+
+* The controller binds request data directly to an entity class, allowing modification of sensitive attributes
+
+* Validation is missing at the request-handling layer
+
+* Entity fields are public or otherwise modifiable when they should be internal-only
+
+* Spring’s default data binder maps all matching JSON fields without restriction
+
+* The absence of DTO separation enables privilege escalation
+
+The vulnerable source code exposes internal fields through automatic binding, allowing attackers to manipulate application state. Proper use of Data Transfer Objects (DTOs) prevents this vulnerability by explicitly defining which fields may be modified by external input.
+
+Exploit
+CAPEC-234: Privilege Escalation
+
+An attacker exploits this vulnerability by submitting a crafted JSON payload that includes sensitive fields. For example:
+
+json
+Copy code
+{
+  "id": 12,
+  "email": "test123@gmail.com",
+  "admin": "yes"
+}
+If the application binds this payload directly to the entity, the attacker gains administrative privileges. With elevated access, the attacker may reach protected endpoints, modify restricted records, or perform administrator-only actions. In some cases, attackers may also manipulate accounts belonging to other users.
+
+Fix
+The vulnerable project resolves this issue by introducing DTOs, enforcing validation, and preventing unexpected fields from being deserialized.
+
+Effective remediation techniques include:
+
+* Replacing entity binding with a dedicated Data Transfer Object (DTO)
+
+* Validating input using @Valid and Bean Validation annotations
+
+* Hiding internal fields using annotations such as @JsonIgnore
+
+* Rejecting unexpected fields during deserialization
+
+Example Fix – DTO Class
+java
+Copy code
+public class UserUpdateDTO {
+    public String email;
+}
+Fix – Controller Method
+java
+Copy code
+@PostMapping("/update")
+public User update(@Valid @RequestBody UserUpdateDTO userUpdateDto) {
+    user.setEmail(userUpdateDto.email);
+    return userService.save(user);
+}
+This approach ensures that only explicitly allowed fields can be modified. DTOs act as a controlled interface between external input and internal entities, preventing unauthorized modification of sensitive attributes.
+
+Prevention
+Preventing this vulnerability requires deliberate design choices and consistent secure configuration. Effective prevention strategies include:
+
+* Always using DTOs instead of binding requests directly to entity classes
+
+* Applying strong validation rules to all incoming data
+
+* Limiting DTOs to only fields that are intended to be user-modifiable
+
+* Avoiding public fields in domain models and enforcing proper encapsulation
+
+* Enabling strict deserialization settings such as fail-on-unknown-properties=true
+
+* Conducting periodic security reviews of controller binding behavior
+
+* Using static analysis tools to detect mass-assignment patterns
+
+Relating each recommendation back to the case study demonstrates how the vulnerability could have been avoided entirely through secure design practices.
+
+Conclusion
+Improper input validation in Spring Boot illustrates how convenient framework features can lead to data tampering and privilege escalation when misused. This case study demonstrates the severity of exposing internal fields through automatic data binding and shows how attackers can exploit such behavior with minimal effort.
+
+By introducing DTOs, validating incoming data, and restricting which attributes may be updated, developers can eliminate mass-assignment vulnerabilities. Small design decisions can have significant security implications, but straightforward defensive practices can prevent these issues without adding unnecessary complexity.
+
+References
+Spring Boot Project Page: GitHub
+
+Spring Boot Documentation – @RequestBody: Documentation

ESSAY PROPOSAL-MD.md

@@ -0,0 +1 @@
+