gpt4 book ai didi

NGINX:在 access_log 中混淆密码

转载 作者:行者123 更新时间:2023-12-03 21:29:18 53 4
gpt4 key购买 nike

我要登录 $request_body在访问日志中。

但是一些请求有一些敏感的 JSON 字段,如密码。

例子:

[2019-03-28] 201 - POST /api/user/add HTTP/1.1 - {\x22email\x22:\x22test@test.com\x22,\x22password\x22:\x22myPassword\x22}

有没有办法混淆密码值,使输出看起来像这样:
[2019-03-28] 201 - POST /api/user/add HTTP/1.1 - {\x22email\x22:\x22test@test.com\x22,\x22password\x22:\x22****\x22}

最佳答案

这里有一些正则表达式模式,可用于混淆各种格式的请求正文数据。

当然,您需要做的第一件事是使用 log_format 将混淆数据添加到日志文件行格式中。指示:

log_format custom '$remote_addr - $remote_user [$time_local] '
'"$request" "$obfuscated_request_body" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

我们来看看下面的 post body 数据格式(假设我们需要混淆的字段是 password )。
  • 请求正文是一个 JSON 字符串(典型的 REST API 请求)

  • JSON 示例:
    {"email":"test@test.com","password":"myPassword"}

    转义的 JSON 字符串:
    {\x22email\x22:\x22test@test.com\x22,\x22password\x22:\x22myPassword\x22}

    nginx map堵塞:
    map $request_body $obfuscated_request_body {
    "~(.*[{,]\\x22password\\x22:\\x22).*?(\\x22[,}].*)" $1********$2;
    default $request_body;
    }
  • 请求正文是 name 的 JSON 数组和 value对(由 jQuery serializeArray() 函数返回)

  • JSON 示例:
    [{"name":"email","value":"test@test.com"},{"name":"password","value":"myPassword"}]

    转义的 JSON 字符串:
    [{\x22name\x22:\x22email\x22,\x22value\x22:\x22test@test.com\x22},{\x22name\x22:\x22password\x22,\x22value\x22:\x22myPassword\x22}]

    nginx map堵塞:
    map $request_body $obfuscated_request_body {
    "~(.*[\[,]{\\x22name\\x22:\\x22password\\x22,\\x22value\\x22:\\x22).*?(\\x22}[,\]].*)" $1********$2;
    default $request_body;
    }
  • 请求正文是一个 urlencoded 字符串(由 HTML 表单提交,带有 enctype="application/x-www-form-urlencoded" )

  • POST 正文示例:
    login=test%40test.com&password=myPassword

    nginx map堵塞:
    nginx map堵塞:
    map $request_body $obfuscated_request_body {
    ~(^|.*&)(password=)[^&]*(&.*|$) $1$2********$3;
    default $request_body;
    }

    如果您需要混淆多个数据字段 ,您可以链接多个 map转换:
    log_format custom '$remote_addr - $remote_user [$time_local] '
    '"$request" "$obfuscated_request_body_2" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

    map $request_body $obfuscated_request_body_1 {
    "~(.*[{,]\\x22password\\x22:\\x22).*?(\\x22[,}].*)" $1********$2;
    default $request_body;
    }

    map $obfuscated_request_body_1 $obfuscated_request_body_2 {
    "~(.*[{,]\\x22email\\x22:\\x22).*?(\\x22[,}].*)" $1********$2;
    default $request_body;
    }

    所有给定的正则表达式仅适用于 escape=default转义模式 log_format nginx 指令!如果由于某种原因您需要将此模式更改为 escape=json (可从 nginx 1.11.8 获得)或 escape=none (可从 nginx 1.13.10 获得),我也为这种转义模式构建了正则表达式,但由于一些奇怪的原因,在指定 pcre_jit on; 之前无法管理它们与 nginx 一起使用。指令(尽管它们通过了其他 PCRE 测试)。对于那些感兴趣的人,这些正则表达式是
  • escape=json转义模式:
  • map $request_body $obfuscated_request_body {
    "~(.*[{,]\\\"password\\\":\\\")(?:[^\\]|\\{3}\"|\\{2}[bfnrt]|\\{4})*(\\\"[,}].*)" $1********$2;
    default $request_body;
    }

    对于 JSON 字符串,以及
    map $request_body $obfuscated_request_body {
    "~(.*[\[,]{\\\"name\\\":\\\"password\\\",\\\"value\\\":\\\")(?:[^\\]|\\{3}\"|\\{2}[bfnrt]|\\{4})*(\\\"}[,\]].*)" $1********$2;
    default $request_body;
    }

    对于 name 的 JSON 数组和 value对。
  • escape=none转义模式:
  • map $request_body $obfuscated_request_body {
    "~(.*[{,]\"password\":\")(?:[^\\\"]|\\.)*(\"[,}].*)' $1********$2;
    default $request_body;
    }

    对于 JSON 字符串,以及
    map $request_body $obfuscated_request_body {
    "~(.*[\[,]{\"name\":\"password\",\"value\":\")(?:[^\\\"]|\\.)*(\"}[,\]].*)" $1********$2;
    default $request_body;
    }

    对于 name 的 JSON 数组和 value对。

    奖励 - 混淆 GET 请求查询参数

    有时人们还需要混淆作为 GET 请求查询参数传递的数据。要做到这一点,同时保留原始的 nginx 访问日志格式,让我们先看看默认的访问日志格式:
    log_format combined '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

    nginx 内置 $request变量可以表示为 $request_method $request_uri $server_protocol变量序列:
    log_format combined '$remote_addr - $remote_user [$time_local] '
    '"$request_method $request_uri $server_protocol" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

    我们需要混淆 $request_uri 的一部分可变数据:
    log_format custom '$remote_addr - $remote_user [$time_local] '
    '"$request_method $obfuscated_request_uri $server_protocol" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

    map $request_uri $obfuscated_request_uri {
    ~(.+\?)(.*&)?(password=)[^&]*(&.*|$) $1$2$3********$4;
    default $request_uri;
    }

    要混淆多个查询参数,您可以链接多个 map翻译如上图。

    更新 - 安全注意事项

    Alvin Thompson评论 OP 的问题,提到了一些攻击媒介,比如非常大的压缩请求。
    值得一提的是,nginx 会以压缩形式“按原样”记录这些请求,因此日志文件不会以不可预测的方式增长。

    假设我们的日志文件具有以下格式:
    log_format debug '$remote_addr - $remote_user [$time_local] '
    '"$request" $request_length $content_length '
    '"$request_body" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

    带有 5,000 个空格的 gzip 正文的请求将被记录为
    127.0.0.1 - - [09/Feb/2020:05:27:41 +0200] "POST /dump.php HTTP/1.1" 193 41 "\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x0B\xED\xC11\x01\x00\x00\x00\xC2\xA0*\xEB\x9F\xD2\x14~@\x01\x00\x00\x00\x00o\x03`,\x0B\x87\x88\x13\x00\x00" 200 6881 "-" "curl/7.62.0"

    如您所见, $request_length$content_length值(193 和 41)反射(reflect)了来自客户端的传入数据的长度和 不是 解压缩数据流的字节数。

    为了过滤异常大的未压缩请求,您还可以按长度过滤请求体:
    map $content_length $processed_request_body {
    # Here are some regexes for log filtering by POST body maximum size
    # (only one should be used at a time)

    # Content length value is 4 digits or more ($request_length > 999)
    "~(.*\d{4})" "Too big (request length $1 bytes)";

    # Content length > 499
    "~^((?:[5-9]|\d{2,})\d{2})" "Too big (request length $1 bytes)";

    # Content length > 2999
    "~^((?:[3-9]|\d{2,})\d{3})" "Too big (request length $1 bytes)";

    default $request_body;
    }

    map $processed_request_body $obfuscated_request_body {
    ...
    default $processed_request_body;
    }

    关于NGINX:在 access_log 中混淆密码,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55396459/

    53 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com