alilleybrinker / pathbuf Goto Github PK

This isn't a particular problem of this crate, rather a missing push_one in the standard library, as push allows multiple components. But it would be good to document it also in this crate, so people don't forget about it.

If you want to add a path traversal protected version, have a look at a implementation by me.
Otherwise I will create a crate with this functionality (w\o macro), when I have time, but it could fit to this crate.

Right now, as discussed in #1, the macro exposed by this crate leaves users vulnerable to path traversal attacks. However, it doesn't have to do so, and could either be modified, or have an alternative macro that protects against the attack, perhaps optionally with an unsafe version as well.

One version I could imagine would look like:

use pathbuf::try_pathbuf;

fn main() -> Result<(), Box<dyn Error>> {
    // This will fail, because "path/with" contains more than one component.
    let path = try_pathbuf!["some", "path/with", "a", "traversal", "issue.md"]?;

    Ok(())
}

This basically just rejects multi-part paths as inputs to the macro.

We could also imagine retaining the current pathbuf macro under a new name, like unsafe_pathbuf or insecure_pathbuf, which would include documentation that it should only be used with trusted (non-attacker-controlled) inputs, or else you'd be vulnerable to a path traversal attack.

The benefit some may see of the insecure macro is that you avoid the cost of single-component checking for each input.