...
One potential drawback of this approach is that effective sanitization methods can be difficult to write. A benefit of this approach is that it works well in combination with taint analysis (see Risk AssessmentAutomated Detection, below).
Compliant Solution (Built-in File Name and Path)
Sanitization of tainted inputs always carries the risk that the data is not fully sanitized. File Both file and path name equivalence and directory traversal are both common examples of vulnerabilities arising from the improper sanitization of path and file name inputs (see FIO04-J. Canonicalize path names before validating). A design that requires an unprivileged user to access an arbitrary, protected file (or other resource) is always suspect. Instead, you may want to consider Consider alternatives such as using a hard code resource name or only allow permitting the user to select only from a list of options that are indirectly mapped to the resource names.
This compliant solution both explicitly hard codes the name of the file and also confines the variables used in the privileged block to the same method. This ensures that no malicious file can be loaded by exploiting the privileges of the corresponding code.
...
Tools that support taint analysis enable assurance of code usage that is substantially similar to the second first compliant solution. Typical taint analysis assumes analyses assume that a method or methods exist(s) that can "clean" potentially tainted inputs, providing untainted outputs (or appropriate errors). The taint analysis then ensures that only untainted data is used inside the doPrivileged block. Note that the static analysis analyses must necessarily assume that the cleaning methods are always successful; in reality this may not be the case.
...