CWE-374: Passing Mutable Objects to an Untrusted Method
View customized information:
Conceptual
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
Operational
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
Mapping Friendly
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
Complete
For users who wish to see all available information for the CWE/CAPEC entry.
Custom
For users who want to customize what details are displayed.
×
Edit Custom Filter
Conceptual
Operational
Mapping Friendly
Select All
Reset
Clear
Submit
Cancel
The function or method that has been called can alter or delete the mutable data. This could violate assumptions that the calling function has made about its state. In situations where unknown code is called with references to mutable data, this external code could make changes to the data sent. If this data was not previously cloned, the modified data might not be valid in the context of execution.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following example demonstrates the weakness. (bad code)
Example Language: C
private:
int foo;
complexType bar; String baz; otherClass externalClass; public: void doStuff() {
externalClass.doOtherStuff(foo, bar, baz) }In this example, bar and baz will be passed by reference to doOtherStuff() which may change them. Example 2 In the following Java example, the BookStore class manages the sale of books in a bookstore, this class includes the member objects for the bookstore inventory and sales database manager classes. The BookStore class includes a method for updating the sales database and inventory when a book is sold. This method retrieves a Book object from the bookstore inventory object using the supplied ISBN number for the book class, then calls a method for the sales object to update the sales information and then calls a method for the inventory object to update inventory for the BookStore. (bad code)
Example Language: Java
public class BookStore {
private BookStoreInventory inventory;
private SalesDBManager sales; ... // constructor for BookStore public BookStore() { this.inventory = new BookStoreInventory(); }this.sales = new SalesDBManager(); ... public void updateSalesAndInventoryForBookSold(String bookISBN) { // Get book object from inventory using ISBN Book book = inventory.getBookWithISBN(bookISBN); // update sales information for book sold sales.updateSalesInformation(book); // update inventory inventory.updateInventory(book); // other BookStore methods ... public class Book { private String title; }private String author; private String isbn; // Book object constructors and get/set methods ... However, in this example the Book object that is retrieved and passed to the method of the sales object could have its contents modified by the method. This could cause unexpected results when the book object is sent to the method for the inventory object to update the inventory. In the Java programming language arguments to methods are passed by value, however in the case of objects a reference to the object is passed by value to the method. When an object reference is passed as a method argument a copy of the object reference is made within the method and therefore both references point to the same object. This allows the contents of the object to be modified by the method that holds the copy of the object reference. [REF-374] In this case the contents of the Book object could be modified by the method of the sales object prior to the call to update the inventory. To prevent the contents of the Book object from being modified, a copy of the Book object should be made before the method call to the sales object. In the following example a copy of the Book object is made using the clone() method and the copy of the Book object is passed to the method of the sales object. This will prevent any changes being made to the original Book object. (good code)
Example Language: Java
...
public void updateSalesAndInventoryForBookSold(String bookISBN) { // Get book object from inventory using ISBN Book book = inventory.getBookWithISBN(bookISBN); // Create copy of book object to make sure contents are not changed Book bookSold = (Book) book.clone(); // update sales information for book sold sales.updateSalesInformation(bookSold); // update inventory inventory.updateInventory(book); ...
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
More information is available — Please edit the custom filter or select a different filter. |
|
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. |
||