CWE-576 is an EJB rule violation: a bean uses the java.io package to access files and directories.
The specification says business components should use a resource manager API such as JDBC to store data, because file system APIs are not well suited to that role. A bean that reads a local file works on one box and fails when the container moves it, scales it out or runs it in a locked down environment.
How it happens
MITRE's example is a mortgage rate bean that loads interest rates from an XML file on the local file system:
// Vulnerable: local file access inside a bean
@Stateless
public class InterestRateBean implements InterestRateRemote {
private Document interestRateXMLDocument = null;
private File xmlFile = null;
public InterestRateBean() {
xmlFile = new File("C:\\rates\\rates.xml");
...
}
}
A hard coded path also invites configuration mistakes and path handling bugs.
What an attacker gains
MITRE lists quality degradation. Local file access in server code can also widen the impact of any later flaw that lets an attacker influence the path.
How to find it
Search bean classes for java.io imports and File usage. The record lists no detection methods.
How to fix it
Store data through a resource manager such as a database via JDBC or JPA, or read configuration through container managed resources.
@Stateless
public class InterestRateBean implements InterestRateRemote {
@PersistenceContext EntityManager em;
public BigDecimal rateFor(int points) {
return em.find(Rate.class, points).getValue();
}
}
MITRE's own mitigation line is: do not use Java I/O when writing EJBs.
Quick check
What should a bean use instead of files?
A resource manager API such as JDBC, through the container.
The free in-browser scan at gold.safeguard.sh/scan lists the dependencies in your manifest. No login is needed, the file stays on your machine, and it handles up to 100 dependencies.
