Potential crash / out-of-bounds iterator dereference in HttpFileImpl::save() #2655

Describe the bug

Found a potential invalid iterator dereference while fuzzing in HttpFileImpl::save(const std::string &path) in lib/src/HttpFileImpl.cc. HttpFileImpl::save(const std::string &path) in lib/src/HttpFileImpl.cc uses the three-iterator overload of std::equal to check whether the canonical destination is inside the configured upload directory:

if (!std::equal(fsUploadDir.begin(),
                fsUploadDir.end(),
                fsSaveToPath.begin()))

This overload requires the second range to contain at least as many elements as the first. That condition is not guaranteed here. When a traversal filename resolves to a strict ancestor of the upload directory, the destination has fewer path components. std::equal may then dereference an iterator past fsSaveToPath.end(), resulting in undefined behavior. With libstdc++ assertions enabled (-D_GLIBCXX_ASSERTIONS), this reproduces as a process abort:

Assertion '_M_cur != _M_path->_M_cmpts.end()' failed.

To Reproduce

1. Set the upload directory to:

   /tmp/drogon_app/a/b/c/upload
   

2. Create an HttpFileImpl with the filename ../../c.

3. Call file.save().

The canonical destination becomes /tmp/drogon_app/a/b/c, which has fewer path components than the upload directory.
Build Drogon's HttpFileImpl.cc with -D_GLIBCXX_ASSERTIONS and run the reproducer. The process aborts during the std::equal comparison.

Expected behavior

The traversal attempt should be rejected safely, with save() returning -1. Valid uploads, including those targeting nested subdirectories, should continue to work.

Environment

• OS: Ubuntu 24.04 (WSL2)
• Compiler: Clang 18.1.3
• Standard library: GCC 13 libstdc++
• Build: -D_GLIBCXX_ASSERTIONS
• Drogon commit: df418bfdd99d4cc1ebd8598b8ced4f74d4f488ce

Suggested fix

Use the four-iterator overload of std::mismatch for a bounds-safe component-wise prefix check:

auto mismatch = std::mismatch(
    fsUploadDir.begin(),
    fsUploadDir.end(),
    fsSaveToPath.begin(),
    fsSaveToPath.end()
);

if (mismatch.first != fsUploadDir.end())
{
    LOG_ERROR
        << "Attempt writing outside of upload directory detected. Path: "
        << fileName_;
    return -1;
}

Unlike four-iterator std::equal, this allows the destination to contain additional components, preserving valid nested uploads while safely rejecting shorter or non-matching paths.
I can submit a PR with the proposed fix and regression tests if this approach looks reasonable.