Passing Mutable Objects to an Untrusted Method

The program sends non-cloned mutable data as an argument to a method or function.


Description

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.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

The following example demonstrates the weakness.

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 Two

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.

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.

...
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);

}
...

See Also

SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)

Weaknesses in this category are related to the rules and recommendations in the Object Orientation (OBJ) section of the SEI CERT Oracle Secure Coding Standard for Java.

SFP Secondary Cluster: Exposed Data

This category identifies Software Fault Patterns (SFPs) within the Exposed Data cluster (SFP23).

State Issues

Weaknesses in this category are related to improper management of system state.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.

Weakness Base Elements

This view (slice) displays only weakness base elements.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.