isSafePath checks for "." and ".." paths. Other combinations of these and other characters such as extraneous /, \, and others could be evaluated. Depending on how the resulting string is used, this issue can cause problems such as The attack can be used to : Disclosing physical paths, files and OS-information Truncating strings Paths Files Commands Command parameters Bypass validity checks, looking for substrings in parameters Cut off strings passed to SQL Queries A set of representative attack patterns used for historical directory traversal exploits can be seen at: https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt Resolution: All file paths must be recursively canonicalized into a normalized form before being tested in order to prevent path injection attacks This includes encoding issues, extraneous / \ . characters, control characters which might be processed in ways we don't intend, null bytes, unicode encodings, representations which are decoded into null bytes. We must also be sensitive to how the underlying operating system and filesystem will evaluate filenames handed off to it. Sample of patterns that have historically caused abuse can be seen at https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt

In a nutshell: isSafePath implements a blacklist for a security sensitive operation, which is an insecure design pattern.