From 63f5865dad4dbac7cd0379129cfa7e38bbbb6f66 Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sat, 29 Nov 2025 20:48:45 -0500 Subject: [PATCH 1/8] Add files via upload --- ESSAY PROPOSAL-MD.md | 176 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 ESSAY PROPOSAL-MD.md diff --git a/ESSAY PROPOSAL-MD.md b/ESSAY PROPOSAL-MD.md new file mode 100644 index 0000000..d241b72 --- /dev/null +++ b/ESSAY PROPOSAL-MD.md @@ -0,0 +1,176 @@ +ESSAY PROPOSAL + +Title: + +Improper Input Validation in Spring Boot +A short, direct title that clearly identifies the weakness and the software ecosystem involved +in API request. This even explains the vulnerability that had a critical violation of security. + +Introduction: + +Many Spring Boot applications rely on automatic JSON-to-object binding to map incoming +requests into Java classes. While this feature simplifies development, it can introduce serious +security risks when the application binds user input directly to entity classes that contain +internal fields like admin or some higher attributes in entity may escalate to different. This +creates opportunities for attackers to manipulate values the developer never intended to +expose. + +This weakness is tied to CWE categories related to improper input validation and mass +assignments and happens in several Spring-based projects on this loophole. This case study +will explore how vulnerability arises, how it can be exploited, and the secure coding practices +required to prevent it or any technical solution that are upfront for making the security +violation possible. + +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 a program allows users to control object attributes that were +intended to be internal. In frameworks with automatic data binding, such as Spring MVC, an +attacker can submit JSON fields that match names in an entity class. If the developer has not +restricted which fields can be updated, the attacker can override protected values and lead to +big collapse in the entity. + +Generic Example: + +Entity Structure: +class User { +public String username; +public String email; +public String admin; // sensitive field for admins only +} + +API End point for Controller class for Json invoke: + +@PostMapping("/update") +public User update (@RequestBody User user) { +return userService.save(user); +} + +A malicious payload: +{ +“username”: “Sakthi”, +“email”: “abc@gmail.com”, +“admin “: “yes”, / which is only field which is goanna give access for admin +} + +In the above malicious payload, the main security violation for accessing random attributes +inside an entity is without restriction. Because the binder accepts any matching field, a +regular user could assign themself to elevated privileges as admin and may get access to +confidential fields. + +Vulnerability: + +The case study will show actual source code from a selected open-source project +demonstrating this issue. It will show: + The controller is binding directly to an entity and allows modifying the attributes +directly, even if it's sensitive. + + Validate at the time of request. + Public or modifiable fields that should not be user-controlled or accessed need to +follow. + Why Spring’s frameworks default binder maps allow all matching JSON fields +without restriction. + How the lack of validation or DTO separation led to privilege escalation and +advantages of accessing attributes without vulnerabilities. + +This section will provide file names, line numbers, and small, focused code excerpts to +illustrate where the flaw originated and how the copy of entity as DTO will help us not to +violate and make a security issue. + +Exploit + +CAPEC-234: Privilege Escalation +The exploit revolves around submitting crafted JSON that includes sensitive fields. For +example: + +JSON for attributes like admin can either be yes or no or 0/1 (binary) validation. +{ +“id’': 12, +“email”: “test123@gmail.com” +“admin”: "yes" or 1 +} + +If the application binds this directly to an entity or calls it sensible attributes, the attacker +gains administrative privileges which can lead to accessing many confidential areas inside a +web application. + +From that point, they could access protected endpoints, modify records, or perform actions +reserved for administrators and even provide multiple changes and access for users who don’t +own it. + +Fix: + +The fix section will explain how the vulnerable project resolves the issue and walks through +the corrected code. The typical secure approach includes: +• Replacing entity binding with a dedicated DTO (Data transfer Object classes) +• Validating input using @Valid and Bean Validation annotations. +• Hiding internal fields using @JsonIgnore not that +• Rejecting unexpected fields during deserialization and validating each field through +validators + +Example Fix: + +class UserUpdateDTO { +public String email; +} + +@PostMapping("/update") +public User update (@Valid @RequestBody UserUpdateDTO userUpdateDto) { +user.setEmail(dto.email); +return userService.save(user); +} + +This ensures only explicitly allowed fields can be modified rather than allowing the user to +use unwanted fields to be accessed and modified. + + +DTO gives a clear clone copy of the entity attributes that can be modified but only the +attributes that can be modified without security violation or end point for attackers to access +the application through JSON request. + +Prevention: + +Preventing this vulnerability requires a combination of design discipline and proper +configuration. The case study will emphasize: + +✓ Always using DTOs instead of direct modification on entity class. +✓ Applying strong validation rules on all incoming data and allowing the DTO creation +only with the attributes that can be accessed or modified. +✓ Avoiding public fields in domain models and making the entity private. +✓ Enabling strict deserialization like - fail-on-unknown-properties=true. +✓ Conduct periodic security reviews of controller binding behavior and always +encapsule the private object with getters and setter even for DTO and entities. +✓ Using static analysis tools that detect mass assignment patterns and follow the proper +validation rule for security not to be breached. + +Relating each recommendation back to the case study helps readers understand how the issue +could have been avoided entirely and a proper structure even to use the same function in a +much safer and secure way allows developer to develop convert and secured application +without loop of vulnerability or security issues + +Conclusion: + +Improper input validation in Spring Boot demonstrates how convenient features, when +misused, can lead to data tampering and privilege escalation. And explains the biggest issue +and seriousness of how easy security can be violated in web applications. And explains how +it causes a serious issue in place of accessing an application with clear examples. +By introducing DTOs, validating incoming fields, and restricting what parts of a domain +model can be updated, developers can prevent this class of vulnerabilities. This case study +will show how an easily overlooked design choice can create major security risks and how +simple defensive practices can eliminate them without making the structure complex. +As per my understanding the essay case study give a clear view of what is @RequestBody +and it function and how that escalates from security o giving attacker easy chance and what +could be done best to make the application to eliminate vulnerabilities that I figured out. + + +References +Spring Boot Project Page: https://github.com/spring-projects/spring-boot +Spring Boot Doc: https://docs.spring.io/spring +framework/reference/web/webflux/controller/ann-methods/requestbody.html \ No newline at end of file From ae67c6d2f3d1a06d2a1254c5f043b9a41ba87a41 Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 30 Nov 2025 19:37:14 -0500 Subject: [PATCH 2/8] Add files via upload From c29aa0fd71056e87757079aa0c17733605e1910b Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 7 Dec 2025 16:52:32 -0500 Subject: [PATCH 3/8] Add files via upload --- ...mproper Input Validation in Spring Boot.md | 173 ++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 CS681-Essay Proposal_Improper Input Validation in Spring Boot.md diff --git a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md new file mode 100644 index 0000000..5cbf9cd --- /dev/null +++ b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md @@ -0,0 +1,173 @@ +Improper Input Validation in Spring Boot + +Introduction + +Many Spring Boot applications rely on automatic JSON-to-object binding to map incoming requests into Java classes. While this feature simplifies development, it can introduce serious security risks when the application binds user input directly to entity classes that contain internal fields such as administrative flags or elevated attributes. When these fields are unintentionally exposed, attackers can manipulate input values that developers never intended users to control. + +This weakness is closely tied to CWE categories involving improper input validation and mass assignment. It appears in several Spring-based projects that rely heavily on automatic binding. This case study explores how vulnerability arises, how it can be exploited, and the secure coding practices necessary to prevent it. + + + + +Software Overview + +Name: Spring Boot +Language: Java +URL: https://github.com/spring-projects/spring-boot + + + + +Weakness: Improperly Controlled Modification of Attributes + +CWE-915: Improperly Controlled Modification of Dynamically Determined Attributes +Related: CWE-20 (Improper Input Validation), CWE-522 (Unprotected Fields) + +This weakness occurs when a program allows users to control object attributes intended to be internal. In frameworks with automatic data binding, such as Spring MVC, attackers can submit JSON fields that match names inside entity classes. If the developer has not restricted which fields can be updated, an attacker can override protected values and cause privilege escalation or system compromise. + + + + +Generic Example + +Entity Structure + +public class User { + public String username; + public String email; + public String admin; +} + + +API Endpoint for JSON Invocation + +@PostMapping("/update") +public User update(@RequestBody User user) { + return userService.save(user); +} + + +Malicious Payload + +{ + "username": "Sakthi", + "email": "abc@gmail.com", + "admin": "yes" +} + + +Because Spring's data binder accepts any matching field, a regular user can assign themselves elevated privileges by setting admin = "yes". With no restrictions or validation, confidential areas of the application become accessible. + + + + +Vulnerability Description + +The case study examines an open-source project demonstrating this issue. Specifically, it will show: + +* The controller binding directly to an entity and allows modification of sensitive attributes. + +* Missing validation at the request layer. + +* Public or modifiable fields that should not be user-controlled. + +* How Spring default binder maps all matching JSON fields without restriction. + +* How the absence of validation or DTO separation led to privilege escalation. + +This section will include file names, line numbers, and focused code excerpts to show the origin of the flaw and how proper DTO usage prevents vulnerability. + + + + +Exploit Scenario + +CAPEC-234: Privilege Escalation + +The exploit revolves around submitting crafted JSON that includes sensitive fields. For example: + +{ + "id": 12, + "email": "test123@gmail.com", + "admin": "yes" +} + + +If the application binds this directly to the entity, the attacker gains administrative privileges. From that point, they could access protected endpoints, modify records, or perform administrator-only actions. This may also allow unauthorized changes to users who should not be modified. + + + + +Fix + +The vulnerable project resolves the issue by introducing DTOs, validating input, and preventing unexpected fields from being deserialized. + +Typical secure approaches include: + +* Replacing entity binding with a dedicated DTO (Data Transfer Object). + +* Validating input using @Valid and Bean Validation annotations. + +* Hiding internal fields using annotations such as @JsonIgnore. + +* Rejecting unexpected fields during deserialization and validating each field through validators. + +Example Fix + +public class UserUpdateDTO { + public String email; +} + + +@PostMapping("/update") +public User update(@Valid @RequestBody UserUpdateDTO userUpdateDto) { + user.setEmail(userUpdateDto.email); + return userService.save(user); +} + + +This ensures that only explicitly allowed fields can be modified, preventing users from modifying sensitive attributes. DTOs act as a controlled layer, exposing only legitimate fields while shielding internal entity attributes from external manipulation. + + + + +Prevention + +Preventing this vulnerability requires strong design choices and consistent configuration. This case study emphasizes: + +* Always use DTOs instead of modifying the entity class directly. + +* Applying strong validation rules to all incoming data and limiting DTOs to only modifiable fields. + +* Avoiding public fields in domain models and using private fields with proper encapsulation. + +* Enabling strict deserialization features such as fail-on-unknown-properties=true. + +* Conduct periodic security reviews of controller binding behavior and ensuring proper use of getters and setters. + +* Using static analysis tools that detect mass-assignment patterns and validate field-level security. + + +Relating each recommendation to the case study helps readers understand how the issue could have been avoided entirely. Following these guidelines ensures that developers create secure, maintainable applications without recurring vulnerabilities. + + + + +Conclusion + +Improper input validation in Spring Boot demonstrates how convenient framework features can lead to data tampering and privilege escalation when misused. This case study highlights the severity of exposing internal fields through automatic binding and shows how attackers can easily exploit such vulnerabilities. + +By introducing DTOs, validating incoming fields, and restricting which parts of a domain model can be updated, developers can prevent mass-assignment vulnerabilities. A small design oversight can create major security risks, yet simple defensive practices can eliminate them without adding complexity. + +This analysis also clarifies how @RequestBody works, how it can escalate into security issues, and what best practices prevent these vulnerabilities in Spring Boot applications. + + + + +References + +Spring Boot Project Page: https://github.com/spring-projects/spring-boot + +Spring Boot Documentation: https://docs.spring.io/spring-framework/reference/web/webflux/controller/ann-methods/requestbody.html + + \ No newline at end of file From 1c68bd75518bd3100849375c7a11cdbadad80654 Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 14 Dec 2025 17:01:09 -0500 Subject: [PATCH 4/8] Draft essay proposal on Spring Boot security risks This proposal outlines the security risks associated with improper input validation in Spring Boot applications, detailing the vulnerability, exploit methods, and recommended fixes using DTOs and validation. --- ESSAY PROPOSAL-MD.md | 175 ------------------------------------------- 1 file changed, 175 deletions(-) diff --git a/ESSAY PROPOSAL-MD.md b/ESSAY PROPOSAL-MD.md index d241b72..d3f5a12 100644 --- a/ESSAY PROPOSAL-MD.md +++ b/ESSAY PROPOSAL-MD.md @@ -1,176 +1 @@ -ESSAY PROPOSAL -Title: - -Improper Input Validation in Spring Boot -A short, direct title that clearly identifies the weakness and the software ecosystem involved -in API request. This even explains the vulnerability that had a critical violation of security. - -Introduction: - -Many Spring Boot applications rely on automatic JSON-to-object binding to map incoming -requests into Java classes. While this feature simplifies development, it can introduce serious -security risks when the application binds user input directly to entity classes that contain -internal fields like admin or some higher attributes in entity may escalate to different. This -creates opportunities for attackers to manipulate values the developer never intended to -expose. - -This weakness is tied to CWE categories related to improper input validation and mass -assignments and happens in several Spring-based projects on this loophole. This case study -will explore how vulnerability arises, how it can be exploited, and the secure coding practices -required to prevent it or any technical solution that are upfront for making the security -violation possible. - -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 a program allows users to control object attributes that were -intended to be internal. In frameworks with automatic data binding, such as Spring MVC, an -attacker can submit JSON fields that match names in an entity class. If the developer has not -restricted which fields can be updated, the attacker can override protected values and lead to -big collapse in the entity. - -Generic Example: - -Entity Structure: -class User { -public String username; -public String email; -public String admin; // sensitive field for admins only -} - -API End point for Controller class for Json invoke: - -@PostMapping("/update") -public User update (@RequestBody User user) { -return userService.save(user); -} - -A malicious payload: -{ -“username”: “Sakthi”, -“email”: “abc@gmail.com”, -“admin “: “yes”, / which is only field which is goanna give access for admin -} - -In the above malicious payload, the main security violation for accessing random attributes -inside an entity is without restriction. Because the binder accepts any matching field, a -regular user could assign themself to elevated privileges as admin and may get access to -confidential fields. - -Vulnerability: - -The case study will show actual source code from a selected open-source project -demonstrating this issue. It will show: - The controller is binding directly to an entity and allows modifying the attributes -directly, even if it's sensitive. - - Validate at the time of request. - Public or modifiable fields that should not be user-controlled or accessed need to -follow. - Why Spring’s frameworks default binder maps allow all matching JSON fields -without restriction. - How the lack of validation or DTO separation led to privilege escalation and -advantages of accessing attributes without vulnerabilities. - -This section will provide file names, line numbers, and small, focused code excerpts to -illustrate where the flaw originated and how the copy of entity as DTO will help us not to -violate and make a security issue. - -Exploit - -CAPEC-234: Privilege Escalation -The exploit revolves around submitting crafted JSON that includes sensitive fields. For -example: - -JSON for attributes like admin can either be yes or no or 0/1 (binary) validation. -{ -“id’': 12, -“email”: “test123@gmail.com” -“admin”: "yes" or 1 -} - -If the application binds this directly to an entity or calls it sensible attributes, the attacker -gains administrative privileges which can lead to accessing many confidential areas inside a -web application. - -From that point, they could access protected endpoints, modify records, or perform actions -reserved for administrators and even provide multiple changes and access for users who don’t -own it. - -Fix: - -The fix section will explain how the vulnerable project resolves the issue and walks through -the corrected code. The typical secure approach includes: -• Replacing entity binding with a dedicated DTO (Data transfer Object classes) -• Validating input using @Valid and Bean Validation annotations. -• Hiding internal fields using @JsonIgnore not that -• Rejecting unexpected fields during deserialization and validating each field through -validators - -Example Fix: - -class UserUpdateDTO { -public String email; -} - -@PostMapping("/update") -public User update (@Valid @RequestBody UserUpdateDTO userUpdateDto) { -user.setEmail(dto.email); -return userService.save(user); -} - -This ensures only explicitly allowed fields can be modified rather than allowing the user to -use unwanted fields to be accessed and modified. - - -DTO gives a clear clone copy of the entity attributes that can be modified but only the -attributes that can be modified without security violation or end point for attackers to access -the application through JSON request. - -Prevention: - -Preventing this vulnerability requires a combination of design discipline and proper -configuration. The case study will emphasize: - -✓ Always using DTOs instead of direct modification on entity class. -✓ Applying strong validation rules on all incoming data and allowing the DTO creation -only with the attributes that can be accessed or modified. -✓ Avoiding public fields in domain models and making the entity private. -✓ Enabling strict deserialization like - fail-on-unknown-properties=true. -✓ Conduct periodic security reviews of controller binding behavior and always -encapsule the private object with getters and setter even for DTO and entities. -✓ Using static analysis tools that detect mass assignment patterns and follow the proper -validation rule for security not to be breached. - -Relating each recommendation back to the case study helps readers understand how the issue -could have been avoided entirely and a proper structure even to use the same function in a -much safer and secure way allows developer to develop convert and secured application -without loop of vulnerability or security issues - -Conclusion: - -Improper input validation in Spring Boot demonstrates how convenient features, when -misused, can lead to data tampering and privilege escalation. And explains the biggest issue -and seriousness of how easy security can be violated in web applications. And explains how -it causes a serious issue in place of accessing an application with clear examples. -By introducing DTOs, validating incoming fields, and restricting what parts of a domain -model can be updated, developers can prevent this class of vulnerabilities. This case study -will show how an easily overlooked design choice can create major security risks and how -simple defensive practices can eliminate them without making the structure complex. -As per my understanding the essay case study give a clear view of what is @RequestBody -and it function and how that escalates from security o giving attacker easy chance and what -could be done best to make the application to eliminate vulnerabilities that I figured out. - - -References -Spring Boot Project Page: https://github.com/spring-projects/spring-boot -Spring Boot Doc: https://docs.spring.io/spring -framework/reference/web/webflux/controller/ann-methods/requestbody.html \ No newline at end of file From 70e7726cd3c499824f70e2e6029ef0bbbc931bf9 Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 14 Dec 2025 17:25:41 -0500 Subject: [PATCH 5/8] Update essay on improper input validation in Spring Boot Revise essay proposal on improper input validation in Spring Boot, including detailed vulnerability analysis, exploit scenarios, and prevention strategies. --- ...mproper Input Validation in Spring Boot.md | 187 +++++++----------- 1 file changed, 66 insertions(+), 121 deletions(-) diff --git a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md index 5cbf9cd..c6d1977 100644 --- a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md +++ b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md @@ -1,173 +1,118 @@ -Improper Input Validation in Spring Boot +IMPROPER INPUT VALIDATION IN SPRING BOOT +Introduction: -Introduction +Web APIs frequently accept structured input from untrusted clients, making proper input validation a foundational security requirement. When applications fail to validate incoming data, attackers may exploit this weakness to manipulate application behavior, access unauthorized functionality, or corrupt backend systems. Improper input validation is consistently ranked among the CWE Top 25 Most Dangerous Software Weaknesses. In 2022, a vulnerability related to unsafe request handling and validation was disclosed in the Spring ecosystem. This case study examines a real Spring Boot vulnerability, explains how improper input validation enabled exploitation, and demonstrates how the issue was fixed and how similar vulnerabilities can be prevented. -Many Spring Boot applications rely on automatic JSON-to-object binding to map incoming requests into Java classes. While this feature simplifies development, it can introduce serious security risks when the application binds user input directly to entity classes that contain internal fields such as administrative flags or elevated attributes. When these fields are unintentionally exposed, attackers can manipulate input values that developers never intended users to control. +Software: -This weakness is closely tied to CWE categories involving improper input validation and mass assignment. It appears in several Spring-based projects that rely heavily on automatic binding. This case study explores how vulnerability arises, how it can be exploited, and the secure coding practices necessary to prevent it. +Name: Spring Boot +Language: Java +URL: https://github.com/spring-projects/spring-boot - +Weakness: +CWE-20: Improper Input Validation -Software Overview +Improper input validation occurs when software does not adequately verify that externally supplied input conforms to expected constraints before using it. This includes failing to validate data type, format, range, or semantic meaning. When untrusted input is passed directly into application logic, attackers may influence execution paths or internal state in unintended ways. -Name: Spring Boot -Language: Java -URL: https://github.com/spring-projects/spring-boot +A common manifestation of this weakness in Java web applications occurs when request payloads are automatically bound to objects without enforcing validation rules. If fields are trusted implicitly, malicious or malformed values can bypass business logic controls. - +A generic example of this weakness is shown below: +public void processUser(User user) { + database.save(user); +} -Weakness: Improperly Controlled Modification of Attributes -CWE-915: Improperly Controlled Modification of Dynamically Determined Attributes -Related: CWE-20 (Improper Input Validation), CWE-522 (Unprotected Fields) +In this example, the User object is trusted without validating its fields, allowing invalid or malicious data to propagate through the application. -This weakness occurs when a program allows users to control object attributes intended to be internal. In frameworks with automatic data binding, such as Spring MVC, attackers can submit JSON fields that match names inside entity classes. If the developer has not restricted which fields can be updated, an attacker can override protected values and cause privilege escalation or system compromise. +Vulnerability: - - +CVE-2022-22965 -Generic Example +CVE-2022-22965, commonly referred to as Spring4Shell, affected applications built on the Spring Framework running on certain configurations of Java. While the vulnerability ultimately enabled remote code execution, the root cause involved unsafe handling of user-controlled request parameters and insufficient validation during request processing. -Entity Structure +In vulnerable configurations, Spring’s data binding mechanism allowed attackers to supply crafted parameter names that accessed internal class loader properties. These properties were never intended to be influenced by external input. -public class User { - public String username; - public String email; - public String admin; -} - +The following code illustrates the vulnerable binding logic used by Spring: -API Endpoint for JSON Invocation +vulnerable file: spring-web/src/main/java/org/springframework/web/bind/WebDataBinder.java -@PostMapping("/update") -public User update(@RequestBody User user) { - return userService.save(user); -} - +public void bind(PropertyValues pvs) { + MutablePropertyValues mpvs = + (pvs instanceof MutablePropertyValues ? + (MutablePropertyValues) pvs : + new MutablePropertyValues(pvs)); -Malicious Payload + doBind(mpvs); +} -{ - "username": "Sakthi", - "email": "abc@gmail.com", - "admin": "yes" -} - -Because Spring's data binder accepts any matching field, a regular user can assign themselves elevated privileges by setting admin = "yes". With no restrictions or validation, confidential areas of the application become accessible. +Because insufficient restrictions were applied to which properties could be bound, attackers were able to manipulate internal framework objects through crafted HTTP requests. - +Exploit: +CAPEC-242: Code Injection -Vulnerability Description +To exploit this vulnerability, an attacker sends a specially crafted HTTP request containing malicious parameter names. These parameters target internal class loader fields, allowing the attacker to write arbitrary files to the server. -The case study examines an open-source project demonstrating this issue. Specifically, it will show: +An example of a malicious parameter used in exploitation is shown below: -* The controller binding directly to an entity and allows modification of sensitive attributes. +class.module.classLoader.resources.context.parent.pipeline.first.pattern -* Missing validation at the request layer. -* Public or modifiable fields that should not be user-controlled. +When processed by a vulnerable Spring application, this input could be used to write a malicious JSP file to disk. Once written, the attacker could access the file through the browser, resulting in remote code execution and complete compromise of the application. -* How Spring default binder maps all matching JSON fields without restriction. +Fix: -* How the absence of validation or DTO separation led to privilege escalation. +The Spring development team fixed the vulnerability by introducing stricter validation and deny-listing of sensitive properties during data binding. Internal class loader fields were explicitly blocked from being bound using user-supplied input. -This section will include file names, line numbers, and focused code excerpts to show the origin of the flaw and how proper DTO usage prevents vulnerability. +fixed file: spring-web/src/main/java/org/springframework/web/bind/WebDataBinder.java - +public void bind(PropertyValues pvs) { ++ checkAllowedFields(pvs); + MutablePropertyValues mpvs = + (pvs instanceof MutablePropertyValues ? + (MutablePropertyValues) pvs : + new MutablePropertyValues(pvs)); + doBind(mpvs); +} -Exploit Scenario +These changes ensure that only explicitly allowed fields can be populated through request parameters, eliminating the unsafe binding behavior. -CAPEC-234: Privilege Escalation +Prevention: -The exploit revolves around submitting crafted JSON that includes sensitive fields. For example: +Preventing improper input validation vulnerabilities requires a layered approach: -{ - "id": 12, - "email": "test123@gmail.com", - "admin": "yes" -} - +Explicitly define allow-lists for request-bindable fields -If the application binds this directly to the entity, the attacker gains administrative privileges. From that point, they could access protected endpoints, modify records, or perform administrator-only actions. This may also allow unauthorized changes to users who should not be modified. +Avoid binding untrusted input directly to complex or sensitive objects +Apply Bean Validation annotations (e.g., @NotNull, @Email, @Min) to all request models - +Use static analysis tools to detect unsafe data flows from request input to sensitive sinks -Fix +Perform code reviews with a focus on input handling and validation logic -The vulnerable project resolves the issue by introducing DTOs, validating input, and preventing unexpected fields from being deserialized. +Keep frameworks and dependencies fully up to date with security patches -Typical secure approaches include: +If these practices had been consistently enforced, the unsafe binding behavior exploited in this vulnerability would have been prevented. -* Replacing entity binding with a dedicated DTO (Data Transfer Object). +Conclusion: -* Validating input using @Valid and Bean Validation annotations. +This case study demonstrates how improper input validation and unsafe request binding can lead to severe security consequences. In CVE-2022-22965, insufficient validation allowed attackers to manipulate internal framework properties, ultimately resulting in remote code execution. By enforcing strict validation rules, limiting automatic binding, and following secure coding practices, developers can significantly reduce the risk of similar vulnerabilities in future applications. -* Hiding internal fields using annotations such as @JsonIgnore. +References: -* Rejecting unexpected fields during deserialization and validating each field through validators. +Spring Boot Project Page: https://github.com/spring-projects/spring-boot -Example Fix +CVE-2022-22965 Entry: https://www.cve.org/CVERecord?id=CVE-2022-22965 -public class UserUpdateDTO { - public String email; -} - +CWE-20 Entry: https://cwe.mitre.org/data/definitions/20.html -@PostMapping("/update") -public User update(@Valid @RequestBody UserUpdateDTO userUpdateDto) { - user.setEmail(userUpdateDto.email); - return userService.save(user); -} - +CAPEC-242 Entry: https://capec.mitre.org/data/definitions/242.html -This ensures that only explicitly allowed fields can be modified, preventing users from modifying sensitive attributes. DTOs act as a controlled layer, exposing only legitimate fields while shielding internal entity attributes from external manipulation. +NVD Vulnerability Report: https://nvd.nist.gov/vuln/detail/CVE-2022-22965 - - - -Prevention - -Preventing this vulnerability requires strong design choices and consistent configuration. This case study emphasizes: - -* Always use DTOs instead of modifying the entity class directly. - -* Applying strong validation rules to all incoming data and limiting DTOs to only modifiable fields. - -* Avoiding public fields in domain models and using private fields with proper encapsulation. - -* Enabling strict deserialization features such as fail-on-unknown-properties=true. - -* Conduct periodic security reviews of controller binding behavior and ensuring proper use of getters and setters. - -* Using static analysis tools that detect mass-assignment patterns and validate field-level security. - - -Relating each recommendation to the case study helps readers understand how the issue could have been avoided entirely. Following these guidelines ensures that developers create secure, maintainable applications without recurring vulnerabilities. - - - - -Conclusion - -Improper input validation in Spring Boot demonstrates how convenient framework features can lead to data tampering and privilege escalation when misused. This case study highlights the severity of exposing internal fields through automatic binding and shows how attackers can easily exploit such vulnerabilities. - -By introducing DTOs, validating incoming fields, and restricting which parts of a domain model can be updated, developers can prevent mass-assignment vulnerabilities. A small design oversight can create major security risks, yet simple defensive practices can eliminate them without adding complexity. - -This analysis also clarifies how @RequestBody works, how it can escalate into security issues, and what best practices prevent these vulnerabilities in Spring Boot applications. - - - - -References - -Spring Boot Project Page: https://github.com/spring-projects/spring-boot - -Spring Boot Documentation: https://docs.spring.io/spring-framework/reference/web/webflux/controller/ann-methods/requestbody.html - - \ No newline at end of file +Spring Security Advisory: https://spring.io/security/cve-2022-22965 From a7dd7db1615c2c948a213e182704b3512d79909d Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 14 Dec 2025 17:31:37 -0500 Subject: [PATCH 6/8] Revise essay proposal on input validation in Spring Boot This update revises the essay proposal on improper input validation in Spring Boot, expanding on the introduction, vulnerability details, exploits, fixes, and prevention strategies. It emphasizes the importance of using Data Transfer Objects (DTOs) and strong validation to prevent security risks associated with automatic data binding. --- ...mproper Input Validation in Spring Boot.md | 130 ++++++++++-------- 1 file changed, 75 insertions(+), 55 deletions(-) diff --git a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md index c6d1977..04cc630 100644 --- a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md +++ b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md @@ -1,7 +1,9 @@ IMPROPER INPUT VALIDATION IN SPRING BOOT Introduction: -Web APIs frequently accept structured input from untrusted clients, making proper input validation a foundational security requirement. When applications fail to validate incoming data, attackers may exploit this weakness to manipulate application behavior, access unauthorized functionality, or corrupt backend systems. Improper input validation is consistently ranked among the CWE Top 25 Most Dangerous Software Weaknesses. In 2022, a vulnerability related to unsafe request handling and validation was disclosed in the Spring ecosystem. This case study examines a real Spring Boot vulnerability, explains how improper input validation enabled exploitation, and demonstrates how the issue was fixed and how similar vulnerabilities can be prevented. +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: @@ -11,108 +13,126 @@ URL: https://github.com/spring-projects/spring-boot Weakness: -CWE-20: Improper Input Validation +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. -Improper input validation occurs when software does not adequately verify that externally supplied input conforms to expected constraints before using it. This includes failing to validate data type, format, range, or semantic meaning. When untrusted input is passed directly into application logic, attackers may influence execution paths or internal state in unintended ways. +Generic Example: +Entity Structure +public class User { -A common manifestation of this weakness in Java web applications occurs when request payloads are automatically bound to objects without enforcing validation rules. If fields are trusted implicitly, malicious or malformed values can bypass business logic controls. + public String username; + public String email; + public String admin; -A generic example of this weakness is shown below: +} + +API Endpoint for JSON Invocation +@PostMapping("/update") +public User update(@RequestBody User user) { + return userService.save(user); +} -public void processUser(User user) { - database.save(user); +Malicious Payload +{ + "username": "Sakthi", + "email": "abc@gmail.com", + "admin": "yes" } -In this example, the User object is trusted without validating its fields, allowing invalid or malicious data to propagate through the application. +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: -CVE-2022-22965 +This case study examines an open-source Spring Boot project demonstrating this vulnerability. Specifically, the vulnerability exists due to the following conditions: -CVE-2022-22965, commonly referred to as Spring4Shell, affected applications built on the Spring Framework running on certain configurations of Java. While the vulnerability ultimately enabled remote code execution, the root cause involved unsafe handling of user-controlled request parameters and insufficient validation during request processing. +The controller binds request data directly to an entity class, allowing modification of sensitive attributes -In vulnerable configurations, Spring’s data binding mechanism allowed attackers to supply crafted parameter names that accessed internal class loader properties. These properties were never intended to be influenced by external input. +Validation is missing at the request-handling layer -The following code illustrates the vulnerable binding logic used by Spring: +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: -vulnerable file: spring-web/src/main/java/org/springframework/web/bind/WebDataBinder.java +CAPEC-234: Privilege Escalation -public void bind(PropertyValues pvs) { - MutablePropertyValues mpvs = - (pvs instanceof MutablePropertyValues ? - (MutablePropertyValues) pvs : - new MutablePropertyValues(pvs)); +An attacker exploits this vulnerability by submitting a crafted JSON payload that includes sensitive fields. For example: - doBind(mpvs); +{ + "id": 12, + "email": "test123@gmail.com", + "admin": "yes" } -Because insufficient restrictions were applied to which properties could be bound, attackers were able to manipulate internal framework objects through crafted HTTP requests. +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. -Exploit: +Fix: -CAPEC-242: Code Injection +The vulnerable project resolves this issue by introducing DTOs, enforcing validation, and preventing unexpected fields from being deserialized. -To exploit this vulnerability, an attacker sends a specially crafted HTTP request containing malicious parameter names. These parameters target internal class loader fields, allowing the attacker to write arbitrary files to the server. +Effective remediation techniques include: -An example of a malicious parameter used in exploitation is shown below: +Replacing entity binding with a dedicated Data Transfer Object (DTO) -class.module.classLoader.resources.context.parent.pipeline.first.pattern +Validating input using @Valid and Bean Validation annotations +Hiding internal fields using annotations such as @JsonIgnore -When processed by a vulnerable Spring application, this input could be used to write a malicious JSP file to disk. Once written, the attacker could access the file through the browser, resulting in remote code execution and complete compromise of the application. +Rejecting unexpected fields during deserialization -Fix: +Example Fix +public class UserUpdateDTO { -The Spring development team fixed the vulnerability by introducing stricter validation and deny-listing of sensitive properties during data binding. Internal class loader fields were explicitly blocked from being bound using user-supplied input. + public String email; -fixed file: spring-web/src/main/java/org/springframework/web/bind/WebDataBinder.java +} -public void bind(PropertyValues pvs) { -+ checkAllowedFields(pvs); - MutablePropertyValues mpvs = - (pvs instanceof MutablePropertyValues ? - (MutablePropertyValues) pvs : - new MutablePropertyValues(pvs)); - doBind(mpvs); +@PostMapping("/update") +public User update(@Valid @RequestBody UserUpdateDTO userUpdateDto) { + user.setEmail(userUpdateDto.email); + return userService.save(user); } -These changes ensure that only explicitly allowed fields can be populated through request parameters, eliminating the unsafe binding behavior. +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 improper input validation vulnerabilities requires a layered approach: +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 -Explicitly define allow-lists for request-bindable fields +Applying strong validation rules to all incoming data -Avoid binding untrusted input directly to complex or sensitive objects +Limiting DTOs to only fields that are intended to be user-modifiable -Apply Bean Validation annotations (e.g., @NotNull, @Email, @Min) to all request models +Avoiding public fields in domain models and enforcing proper encapsulation -Use static analysis tools to detect unsafe data flows from request input to sensitive sinks +Enabling strict deserialization settings such as fail-on-unknown-properties=true -Perform code reviews with a focus on input handling and validation logic +Conducting periodic security reviews of controller binding behavior -Keep frameworks and dependencies fully up to date with security patches +Using static analysis tools to detect mass-assignment patterns -If these practices had been consistently enforced, the unsafe binding behavior exploited in this vulnerability would have been prevented. +Relating each recommendation back to the case study demonstrates how the vulnerability could have been avoided entirely through secure design practices. Conclusion: -This case study demonstrates how improper input validation and unsafe request binding can lead to severe security consequences. In CVE-2022-22965, insufficient validation allowed attackers to manipulate internal framework properties, ultimately resulting in remote code execution. By enforcing strict validation rules, limiting automatic binding, and following secure coding practices, developers can significantly reduce the risk of similar vulnerabilities in future applications. +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: https://github.com/spring-projects/spring-boot -CVE-2022-22965 Entry: https://www.cve.org/CVERecord?id=CVE-2022-22965 - -CWE-20 Entry: https://cwe.mitre.org/data/definitions/20.html - -CAPEC-242 Entry: https://capec.mitre.org/data/definitions/242.html - -NVD Vulnerability Report: https://nvd.nist.gov/vuln/detail/CVE-2022-22965 - -Spring Security Advisory: https://spring.io/security/cve-2022-22965 +Spring Boot Documentation – @RequestBody: https://docs.spring.io/spring-framework/reference/web/webflux/controller/ann-methods/requestbody.html From f96b35a7fe00d2597a20289bde7811370bab0057 Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 14 Dec 2025 18:28:37 -0500 Subject: [PATCH 7/8] Enhance case study on improper input validation in Spring Boot Updated file --- ...mproper Input Validation in Spring Boot.md | 106 ++++++++---------- 1 file changed, 48 insertions(+), 58 deletions(-) diff --git a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md index 04cc630..778c5e0 100644 --- a/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md +++ b/CS681-Essay Proposal_Improper Input Validation in Spring Boot.md @@ -1,138 +1,128 @@ -IMPROPER INPUT VALIDATION IN SPRING BOOT -Introduction: - +## 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: +## Software +- **Name:** Spring Boot +- **Language:** Java +- **URL:** (https://github.com/spring-projects/spring-boot) -CWE-915: Improperly Controlled Modification of Dynamically Determined Attributes -Related: CWE-20 (Improper Input Validation), CWE-522 (Unprotected Fields) +## 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 -public class User { +## 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: - +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 +* The controller binds request data directly to an entity class, allowing modification of sensitive attributes -Validation is missing at the request-handling layer +* Validation is missing at the request-handling layer -Entity fields are public or otherwise modifiable when they should be internal-only +* 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 +* Spring’s default data binder maps all matching JSON fields without restriction -The absence of DTO separation enables privilege escalation +* 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: - +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: - +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) +* Replacing entity binding with a dedicated Data Transfer Object (DTO) -Validating input using @Valid and Bean Validation annotations +* Validating input using @Valid and Bean Validation annotations -Hiding internal fields using annotations such as @JsonIgnore +* Hiding internal fields using annotations such as @JsonIgnore -Rejecting unexpected fields during deserialization +* Rejecting unexpected fields during deserialization -Example Fix +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: - +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 +* Always using DTOs instead of binding requests directly to entity classes -Applying strong validation rules to all incoming data +* Applying strong validation rules to all incoming data -Limiting DTOs to only fields that are intended to be user-modifiable +* Limiting DTOs to only fields that are intended to be user-modifiable -Avoiding public fields in domain models and enforcing proper encapsulation +* Avoiding public fields in domain models and enforcing proper encapsulation -Enabling strict deserialization settings such as fail-on-unknown-properties=true +* Enabling strict deserialization settings such as fail-on-unknown-properties=true -Conducting periodic security reviews of controller binding behavior +* Conducting periodic security reviews of controller binding behavior -Using static analysis tools to detect mass-assignment patterns +* 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: - +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: https://github.com/spring-projects/spring-boot +References +Spring Boot Project Page: GitHub -Spring Boot Documentation – @RequestBody: https://docs.spring.io/spring-framework/reference/web/webflux/controller/ann-methods/requestbody.html +Spring Boot Documentation – @RequestBody: Documentation \ No newline at end of file From 25e80939c82e32583c7c28391d4c1d8116ce3e59 Mon Sep 17 00:00:00 2001 From: Sakthivel Sivakumar Raju <91723228+Sakthi1307-lab@users.noreply.github.com> Date: Sun, 14 Dec 2025 18:43:26 -0500 Subject: [PATCH 8/8] Enhance case study on improper input validation in Spring Boot