I have an instance where we have an application that requires the ability to set up sftp commands that are specified by administrative users. They are configured through the front-end of the application. Veracode has correctly identified a directory traversal attack here.

I work for a B2B company, and this sftp process is for our clients to send/receive files specifying directory structures on their own system.

The connection is handled through an API and the current library correctly escapes data as input (i.e. if I send "../ && rm * " it gets treated as a directory to "cd" to. The target file to be copied IS controlled explicitly by the system--but that doesn't mean its always the case.

But short of blacklisting certain directories paths like "../" I'm lost as to other strategies at the application level I can possibly use to prevent this attack.

Additional information

I might have miscommunicated: The issue is that our application runs on our servers as its own instance. Chroot jails is fine on our end, but what about the client's server? The business logic is that we'll deposit file(s) to a directory on a system they specify. We have no control over that, and they should have the flexibility to be able to specify precisely what directory they want our application to deposit their files.

I don't like blacklisting approaches because you never know what you missed. And in theory, this process could be set up to point to a Windows box instead of a unix box, and then there's two sets of blacklist rules you suddenly have to code for--not to mention environment detection on the remote server.

2 Answers 2

  1. chroot jails. Each client should connect to a directory hierarchy that cannot be traversed to a) the system or b) other clients.
  2. Input validation. Yeah, you should blacklist things like ../, $, *, etc. If you've got control over the API, you can do even better, such as test for directory existence before trying to pass it to cd. As defensive programming goes, this isn't rocket science, so yeah there's a little drudgery, but it's the right thing to do.
  • I added additional information, from your answer I don't think I fully communicated what the process looks like.
    – avgvstvs
    Commented Mar 21, 2014 at 19:10
  • Ah, yes, that is more complex. Well, without rewriting the system to be able to enforce controls by replacing the server on your client's end with your logic, input validation is probably your best bet. Yes, it's painful, prone to false positives, and susceptible to false negatives. It's probably the better than nothing you're looking for, though.
    – gowenfawr
    Commented Mar 21, 2014 at 19:21

The following logic would typically protect against directory traversal:

  • the directory/filename should be expanded to its absolute+canonical path which resolves ../ and so on, see getCanonicalPath
  • compare the path with a whitelist of allowed paths

No blacklisting involved.

Not sure if I fully understand your case scenario or your specific concern but the above tends to work for a large number of use cases.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .