|
Rule 9: Don't Store User-Given Mutable Objects
Ensure your Java code is secure
by Adam Kolawa, Ph.D., Gina Assaf, and Roberto Scaramuzzi
Posted May 5, 2004
Editor's Note: Java Pro Online presents a weekly rule for ensuring the security of Java systems. Here's Rule 9 for beginning your strategy for ensuring your Java applications are secure. See the entire index of Java code security rules in this series.
This rule prohibits you from directly storing user-provided mutable objects (including arrays of objects). If you do not follow this rule, a hacker could hand the object to the secure code, let the secure code check the object, and change the data while the secure code is using the data. Here is sample code that violates this rule:
public void useDate (
Date date) {
if (isValid (date)
scheduleTask(date); // date
// could have been changed at
// this point.
}
To correct this code, modify it so that it no longer uses the mutable Date object that was passed directly to that method. Instead, the method should create and use a new object that is a copy of the Date object, which you can implement this way:
public void useDate(Date date) {
Date copied_date = new Date(
date.getTime());
if (isValid(copied_date)
scheduleTask(copied_date);
}
Rule source:
Secure Programming for Linux and Unix HOWTO David A. Wheeler
About the Authors
Adam Kolawa, Ph.D, is the chairman and CEO of Parasoft. He is a writer and speaker on industry issues and in 2001 was awarded the Los Angeles Ernst & Young Entrepreneur of the Year Award in the software category. Gina Assaf has been developing, designing, testing, and implementing applications in Java for over six years, and has researched and developed coding standards for Parasoft, many of which provide security for Java applications. Roberto Scaramuzzi, Ph.D., is a Java and Perl Developer for Parasoft in San Diego, California. Born in Italy, he later moved to the United States to obtain his doctorate in Mathematics from Yale University. Contact the authors at .
Back to top
|