使用ByteBuddy Hook捕获WebGoat文件上传攻击参数失败求助

Hey there, let's break down how to fix your ByteBuddy hooking issue for catching path traversal inputs in WebGoat. I've looked at your setup, and here's what's going wrong and how to fix it:

You're running a Python path traversal attack against WebGoat's file upload endpoints (profile-upload and profile-upload-fix), and you're trying to use ByteBuddy to hook underlying methods to capture malicious inputs like ../test_uploadamos_1.jpg. While your SQL injection hook targeting org.hsqldb.jdbc.JDBCStatement works, your file upload hook attempts (targeting java.io.File, org.apache, etc.) are failing to catch the parameters.

Your current approach has two key gaps:

1. Wrong target packages: WebGoat's file upload/path traversal logic lives in its own application code, not in generic java.io or org.apache packages. You're hooking too low in the stack, after the malicious input has already been processed or transformed.
2. Narrow parameter filtering: Your getStrArgs method only checks for java.io.File type arguments, but the path traversal string (../test_uploadamos_1.jpg) is passed as a plain string in the request parsing stage, before it's used to create a File object. You're missing the early stage where the raw input is available.

Here are actionable adjustments to get your hook working:

1. Hook WebGoat's Path Traversal Module Directly #

WebGoat's path traversal functionality is contained in the org.owasp.webgoat.path_traversal package. This is the most precise target because it's where the fullName parameter is received and processed.

Update your AgentBuilder to target this package:

new AgentBuilder.Default()
    .type(ElementMatchers.nameStartsWith("org.owasp.webgoat.path_traversal"))
    .transform((builder, typeDescription, classLoader, module) -> 
        builder.method(ElementMatchers.any())
               .intercept(MethodDelegation.to(Interceptor.class))
    )
    .with(AgentBuilder.RedefinitionStrategy.RETRANSFORMATION) // Ensure retransformation of already loaded classes
    .with(listener)
    .installOn(inst);

2. Expand Parameter Capture in Your Interceptor #

Modify your getStrArgs method to capture string parameters (the raw input) in addition to File objects. This will catch the path traversal string before it's used to create a file:

private static List<String> getStrArgs(@Origin Method method, @AllArguments Object[] args){
    int argsNum = method.getParameterCount();
    List<String> strArgs = new ArrayList<>();
    logger.error("amos-file::::::::::::>>>>>>>>>>>>>>>>>>>>>>"+method.toString());
    for (int i = 0; i < argsNum; i++){
        logger.error("amos-file-arg::::::::::::>>>>>>>>>>>>>>>>>>>>>>"+args[i]);
        // Capture raw string inputs (this is where your ../ path will appear)
        if(args[i] instanceof String){
            strArgs.add((String) args[i]);
        }
        // Keep capturing File objects for later-stage checks
        if(args[i] instanceof File){
            strArgs.add(args[i].toString());
        }
    }
    return strArgs;
}

3. Fallback: Hook Spring's Request Parsing #

If you want a broader hook that works across WebGoat's request handling, target Spring's parameter resolution logic. This will capture all request parameters, including your fullName value:

• Hook org.springframework.web.method.annotation.RequestParamMethodArgumentResolver.resolveArgument()
• Or org.springframework.web.multipart.support.StandardMultipartHttpServletRequest.getParameter()

Your SQL injection hook succeeded because you targeted the exact point where the final SQL statement is executed (JDBC Statement), which is a late-stage, well-defined target. For file upload path traversal, you need to target the early web request parsing stage where the raw input is still a string, not the low-level File class.

内容的提问来源于stack exchange，提问作者amos