Elixir Web服务安全加固：Bandit服务器配置与防护实践

1. 项目概述：为什么Elixir开发者需要关注Bandit的安全？

如果你正在用Elixir构建Web服务，无论是Phoenix应用还是独立的HTTP接口，你大概率听说过或已经在用Bandit。这个纯Elixir实现的HTTP服务器，凭借其卓越的性能——在某些场景下比老牌选手Cowboy快上数倍——正吸引着越来越多的开发者。性能的提升固然诱人，但当我们把承载业务逻辑和敏感数据的服务器暴露在公网上时，一个更根本的问题浮出水面：它足够安全吗？

我经历过不止一次因为服务器配置疏忽导致的安全事件。有一次，一个内部管理界面因为目录列表功能未关闭，被搜索引擎爬虫索引，差点泄露了敏感日志文件。错误信息里那个经典的“403.14 - Forbidden: Web 服务器被配置为不列出此目录的内容”虽然是个安全提示，但它背后暴露的却是服务器对请求处理的细节，本身就是一种信息泄露。Bandit作为后起之秀，其安全模型、默认配置和最佳实践，对于从Cowboy或其他平台迁移过来的团队来说，是一个必须重新审视的领域。

这篇文章不是一份干巴巴的安全清单，而是结合我过去在部署和加固Elixir Web服务时踩过的坑、总结的经验，专门针对Bandit这个服务器，梳理出一套从开发到上线的安全最佳实践。我们会从Bandit的架构特点聊起，明白它为什么快，以及这些特性如何影响安全；然后深入到具体的配置项、代码编写习惯、依赖管理，甚至到部署环境的安全加固。目标很明确：让你在享受Bandit高性能的同时，能睡个安稳觉，知道你的服务器已经穿上了足够的“盔甲”。

2. Bandit安全架构与威胁模型解析

在开始配置防火墙之前，得先了解自家房子的结构和可能被闯入的路径。Bandit的安全架构设计与其高性能目标是紧密绑定的，理解这一点是实施有效安全措施的基础。

2.1 Bandit的进程模型与隔离性

Bandit采用了类似ranch（Cowboy底层使用的连接接收器）但完全用Elixir重写的连接管理机制。它使用一个独立的Bandit.Supervisor来监督整个服务器生态，其下会为每个监听端口（比如标准的4000端口）启动一个Bandit.Server进程。这个Bandit.Server并不直接处理请求，它的核心工作是接受TCP/TLS连接。

每一个被接受的连接，会被移交给一个独立的、由动态监督器管理的Bandit.HTTP1.Handler或Bandit.HTTP2.Handler进程。这就是关键所在：每个HTTP/1.1连接或HTTP/2流都由一个独立的Elixir进程处理。这种“一个连接/流一个进程”的模型带来了巨大的优势：

1. 故障隔离：单个处理进程的崩溃（比如因为一个恶意请求导致的内存耗尽）不会影响其他连接。监督器会重启崩溃的进程，但对于那个特定的恶意连接，可能会因为超时或错误而被关闭，形成了天然的隔离屏障。
2. 资源限制：由于每个处理进程都是独立的，我们可以更容易地通过BEAM VM的进程级机制（虽然有限）或应用逻辑来限制单个请求所能消耗的资源。

然而，这个模型也引入了特有的安全考量。这些处理进程共享同一个Bandit.Server和其配置。如果攻击者能够通过某种方式（比如慢速攻击）耗尽Bandit.Server的接收器进程资源，或者创建海量的处理进程来消耗系统内存，仍然可能导致服务拒绝。因此，我们的安全配置需要同时关注连接层（Bandit.Server）和请求处理层（各个Handler进程）。

2.2 协议实现与常见攻击面

Bandit自己实现了HTTP/1.1和HTTP/2协议栈，这意味着它需要正确处理协议规范中所有复杂的、有时甚至是模糊的边界情况。一个协议解析器的漏洞，可能就是远程代码执行（RCE）的入口。虽然Bandit以其严格的协议一致性测试而自豪，但这并不意味着我们可以高枕无忧。

常见的针对HTTP服务器协议层的攻击包括：

• 请求走私（Request Smuggling）：利用服务器对Content-Length头和Transfer-Encoding: chunked头处理的不一致性，将一个恶意请求“隐藏”在另一个请求中，从而绕过前端代理（如Nginx）的安全检查，直接攻击后端应用。Bandit需要确保其解析逻辑在任何情况下都无歧义。
• 响应分割（Response Splitting）：通过在请求头中注入CRLF（\r\n）字符，攻击者可以污染HTTP响应头，甚至注入额外的恶意响应。这依赖于服务器对用户输入（如URL参数、头信息）的不当清理。Bandit在构造响应时必须对头值进行严格的过滤。
• HTTP/2 快速重置（Rapid Reset）攻击：这是针对HTTP/2的一种新型DDoS攻击。攻击者快速建立HTTP/2连接，然后发送大量请求并立即发送RST_STREAM帧取消它们，消耗服务器资源。缓解此攻击需要服务器端对并发流数量、请求速率和连接生命周期进行精细控制。

Bandit的配置项，如max_connections、max_keepalive、request_timeout等，正是我们防御这些协议层攻击的第一道防线。我们需要根据业务的实际流量模式，将这些参数调整到一个既保证性能又足够安全的平衡点。

2.3 与Phoenix框架的安全边界

绝大多数Bandit的使用场景是作为Phoenix框架的HTTP适配器。这里存在一个清晰的安全责任划分：Bandit负责传输安全（TLS/SSL）、协议解析、连接管理和基础的头信息处理；Phoenix负责应用层安全，包括路由、会话管理、CSRF保护、参数净化、业务逻辑认证与授权等。

例如，Bandit可以确保TLS版本是1.2以上，并正确配置了加密套件。但用户密码是否正确、当前用户是否有权限删除某条记录、提交的表单是否包含恶意SQL片段，这些完全由Phoenix应用（及其插件，如plug）来负责。

这种分工要求我们进行“纵深防御”。不能因为Bandit配置了强TLS就忽视Phoenix中的SQL注入检查，也不能因为Phoenix有完善的认证就允许Bandit以明文（HTTP）方式传输会话Cookie。两者必须协同工作，覆盖从网络传输到业务逻辑的完整链条。

3. 传输层安全：配置坚不可摧的HTTPS

让所有流量都通过HTTPS传输，这已经是现代Web开发的底线，而非可选项。对于Bandit，这意味着正确配置和启用TLS/SSL。

3.1 获取与部署SSL/TLS证书

除非是严格的内网环境，否则永远不要使用自签名证书。Let‘s Encrypt提供的免费、自动化证书是目前的标准做法。在Elixir项目中，我推荐使用certbot工具获取证书，然后将证书文件集成到发布中。

一个常见的目录结构是将证书放在项目的priv/ssl目录下：

your_app/ ├── priv/ │ └── ssl/ │ ├── fullchain.pem # 证书链（你的证书+中间CA） │ └── privkey.pem # 私钥文件（必须严格保密！）

在config/runtime.exs中（这是Mix 1.11+推荐的方式，用于环境特定的配置），我们可以安全地读取这些路径：

# config/runtime.exs import Config ssl_dir = System.get_env("SSL_CERT_PATH", "/path/to/your/ssl") config :your_app, YourAppWeb.Endpoint, http: [port: 4000], https: [ port: 443, cipher_suite: :strong, # 使用强加密套件列表 certfile: Path.join(ssl_dir, "fullchain.pem"), keyfile: Path.join(ssl_dir, "privkey.pem"), # 关键安全选项： versions: [:tlsv1.2, :tlsv1.3], # 禁用不安全的TLS 1.0/1.1 # 启用服务器密码套件偏好设置，让服务器决定用哪个加密算法 prefer_server_ciphers: true, # 安全重协商设置（对于TLS 1.2很重要） secure_renegotiate: true, # 禁用压缩，缓解CRIME攻击 honor_cipher_order: true, eccs: [:secp256r1, :secp384r1] # 优先使用的椭圆曲线 ]

注意：私钥文件privkey.pem的权限必须设置为仅所有者可读（例如600）。在Docker容器中，也要确保通过密钥管理服务或安全的卷挂载方式注入，而不是直接打包在镜像里。

3.2 强化TLS配置与禁用弱加密

上面的配置片段已经包含了一些关键选项。这里重点解释一下cipher_suite: :strong和手动指定套件的区别。Bandit底层使用Erlang/OTP的:ssl模块，:strong是一个预定义的、相对安全的套件列表。但对于追求最高安全标准的场景（如金融、医疗），你可能需要手动指定并排序套件。

一个经过精心挑选、优先使用前向保密（PFS）套件的配置示例：

https: [ port: 443, certfile: "...", keyfile: "...", versions: [:tlsv1.2, :tlsv1.3], # TLS 1.3自带更多安全特性 ciphers: [ # TLS 1.3 套件 (Erlang/OTP 24+) "TLS_AES_256_GCM_SHA384", "TLS_AES_128_GCM_SHA256", "TLS_CHACHA20_POLY1305_SHA256", # TLS 1.2 套件，优先使用ECDHE实现前向保密 "ECDHE-ECDSA-AES256-GCM-SHA384", "ECDHE-RSA-AES256-GCM-SHA384", "ECDHE-ECDSA-CHACHA20-POLY1305", "ECDHE-RSA-CHACHA20-POLY1305", "ECDHE-ECDSA-AES128-GCM-SHA256", "ECDHE-RSA-AES128-GCM-SHA256", # 以下为较弱的备选，可按需保留或删除 # "DHE-RSA-AES256-GCM-SHA384", # "DHE-RSA-AES128-GCM-SHA256", ] |> :ssl.filter_cipher_suites(:strong), # 使用filter确保可用性 honor_cipher_order: true, # 使用服务器定义的套件顺序 secure_renegotiate: true, # 禁用SSL/TLS压缩，防御CRIME攻击 # (注意：TLS 1.3已移除压缩功能，此选项主要针对1.2) next_protocols_advertised: ["h2", "http/1.1"], alpn_preferred_protocols: ["h2", "http/1.1"] # 启用ALPN，支持HTTP/2 ]

使用:ssl.filter_cipher_suites(:strong)可以确保你列出的套件在当前Erlang/OTP版本中是可用的，避免配置错误导致服务无法启动。

3.3 启用HTTP严格传输安全

配置好HTTPS后，下一步是强制客户端使用它。HSTS（HTTP Strict Transport Security）是一个关键的响应头，它告诉浏览器：“在接下来的一段时间内，对于这个域名，只允许使用HTTPS连接。”

在Phoenix中，你可以通过一个Plug轻松添加此头。我建议将其放在路由管道的最开始，以确保所有响应都包含它：

# lib/your_app_web/router.ex pipeline :browser do plug :accepts, ["html"] plug :fetch_session plug :fetch_live_flash plug :put_secure_browser_headers # 这个Plug默认包含了一些安全头，但需要增强 plug :protect_from_forgery plug :put_remote_ip end # 自定义一个Plug来设置更强的安全头 defmodule YourAppWeb.Plugs.SecurityHeaders do import Plug.Conn @one_year_in_seconds 31_536_000 def init(default), do: default def call(conn, _default) do conn |> put_resp_header("strict-transport-security", "max-age=#{@one_year_in_seconds}; includeSubDomains; preload") |> put_resp_header("x-content-type-options", "nosniff") |> put_resp_header("x-frame-options", "DENY") |> put_resp_header("x-xss-protection", "1; mode=block") # 内容安全策略（CSP）需要根据你的应用具体配置，这是一个严格的示例 |> put_resp_header("content-security-policy", "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;") end end # 然后在router中使用它，放在默认的`put_secure_browser_headers`之后或替换之 pipeline :browser do plug :accepts, ["html"] plug :fetch_session plug :fetch_live_flash plug :put_secure_browser_headers plug YourAppWeb.Plugs.SecurityHeaders # 添加自定义安全头 plug :protect_from_forgery plug :put_remote_ip end

includeSubDomains意味着此策略也适用于所有子域名。preload是一个更严格的选项，允许你将域名提交到浏览器的HSTS预加载列表（如Chrome的列表），即使用户第一次访问，浏览器也会强制使用HTTPS。启用preload需谨慎，一旦提交很难撤销。

4. 连接与请求处理安全配置

传输层安全了，接下来要确保Bandit本身能稳健地处理海量连接和请求，抵御资源耗尽型攻击。

4.1 限制连接与请求参数

Bandit提供了多个关键参数来控制资源使用。这些配置通常在Endpoint的http或https选项中设置。以下是一组针对高并发API服务的推荐配置：

# config/prod.exs 或 config/runtime.exs config :your_app, YourAppWeb.Endpoint, http: [ port: 4000, # 连接层限制 max_connections: 10_000, # 允许的最大并发连接数 # 请求层限制 request_timeout: 10_000, # 单个请求读取超时（毫秒） inactivity_timeout: 30_000, # 连接空闲超时（毫秒） request_line_length_limit: 8_192, # 请求行最大长度 header_length_limit: 16_384, # 单个头字段最大长度 max_header_count: 100, # 最大头字段数量 max_request_body_length: 10_485_760, # 最大请求体大小（10MB） # 协议特定选项 protocol_options: [ # HTTP/1.1 选项 max_keepalive: 100, # 单个连接上允许的最大请求数（keep-alive） # HTTP/2 选项 (Bandit 0.7+) max_concurrent_streams: 100, # 单个连接上允许的最大并发流数 initial_window_size: 65_535, # 流初始窗口大小 max_frame_size: 16_384 # 最大帧大小 ] ]

参数选择背后的逻辑：

• max_connections: 这个值需要根据服务器的内存和文件描述符限制来设定。一个Bandit处理进程大约占用几十KB到几百KB内存。10,000个连接可能占用数百MB到上GB内存。使用ulimit -n检查系统的文件描述符限制，并确保其远大于此值。
• request_timeout与inactivity_timeout: 前者防止客户端发送请求体过慢（慢速攻击），后者关闭空闲连接以释放资源。对于API，10秒请求超时通常足够；对于可能有大文件上传的场景，需要调高或使用更细粒度的超时控制。
• max_request_body_length:必须明确设置。不设置或设置过大，攻击者可以通过上传超大文件耗尽磁盘和内存。根据业务需要设定，例如，头像上传可能只需5MB，而视频处理API可能需要1GB。对于不需要请求体的端点（如GET），这个限制同样适用。
• max_concurrent_streams(HTTP/2): 这是防御HTTP/2快速重置攻击的关键。限制单个连接上的并发流数量，可以防止攻击者用一个连接就耗尽服务器资源。100是一个合理的起始值。

4.2 防御慢速攻击与资源耗尽

慢速攻击（Slowloris, Slow POST）旨在通过极慢的速度发送请求，长时间占用服务器连接，使其无法服务正常用户。Bandit的request_timeout和inactivity_timeout是主要防御手段。

此外，还可以考虑在Bandit前部署一个反向代理（如Nginx或Cloudflare）。这些代理通常有更成熟、更灵活的机制来识别和缓解慢速攻击，例如：

• Nginx的client_body_timeout和client_header_timeout。
• Cloudflare的“I’m Under Attack”模式。

实操心得：对于纯API服务，将request_timeout设置得相对较短（如5-10秒）是安全的。如果遇到合法的慢客户端（如网络状况极差的移动用户），更优的解决方案是让客户端实现分块上传或使用更合适的协议（如WebSocket用于长时交互），而不是一味调高服务器超时。

4.3 正确处理请求头与URL编码

Bandit会自动解码URL编码的路径和查询参数。但作为应用开发者，你必须警惕“双重解码”或特殊字符带来的问题。例如，路径遍历攻击（../../../etc/passwd）可能通过URL编码（..%2F..%2F..%2Fetc%2Fpasswd）来绕过简单的字符串匹配。

Phoenix的路由器本身是健壮的，但如果你需要手动解析conn.request_path或conn.query_string，务必使用标准库函数并注意安全：

# 不好的做法：直接进行字符串操作 malicious_path = "/users/..%2F..%2Fconfig%2Fsecrets.exs" # 如果直接使用，可能产生错误解析 # 好的做法：依赖Plug和Phoenix已提供的解析结果 # conn.path_info 已经是解码后的路径段列表，安全 # conn.query_params 已经是解码后的参数Map，安全 # 如果必须自己处理原始字符串，使用URI模块 original_path = "/users/..%2F..%2Fconfig%2Fsecrets.exs" decoded_path = URI.decode(original_path) # 解码一次 # 然后对decoded_path进行规范化检查，移除`..`等

同样，对于请求头，要警惕换行符注入。Bandit在解析头时应该已经处理了，但当你将用户提供的头值传递给其他系统（如日志、下游API）时，仍需进行清理或编码。

5. 应用层安全加固

Bandit保证了请求能安全、正确地抵达你的Phoenix应用。剩下的，就是应用层自身的安全了。这里有许多最佳实践，其中一些与Bandit间接相关。

5.1 安全相关的Plug与中间件

Phoenix的Plug生态系统是应用安全的核心。除了前面提到的自定义安全头Plug，以下几个是至关重要的：

1. Plug.SSL: 在生产环境中强制使用HTTPS。它可以配置为重定向HTTP到HTTPS，或直接拒绝非HTTPS请求。通常与反向代理（如Nginx）配合使用，因为代理服务器处理SSL卸载，然后以HTTP协议与Bandit通信。此时，Plug.SSL需要信任代理传来的X-Forwarded-Proto头。

   # 在endpoint.ex中 plug Plug.SSL, rewrite_on: [:x_forwarded_proto], # 信任代理头 host: nil # 可选，设置重定向的主机名

2. Plug.Head: 将HEAD请求转换为GET请求并去掉响应体，这是一个标准兼容性Plug，通常已默认启用。

3. Plug.MethodOverride:谨慎使用或完全避免。这个Plug允许通过_method参数覆盖实际的HTTP方法，曾是一些框架的遗留特性。在现代REST API中，它增加了攻击面，建议禁用。

4. Plug.Parsers: 这是请求体解析的大门，必须严格配置。

   plug Plug.Parsers, parsers: [:urlencoded, :multipart, :json], # 只启用需要的解析器 pass: ["*/*"], # 或更具体的Content-Type json_decoder: Phoenix.json_library(), # 使用安全的JSON解码器 length: 10_000_000 # 全局请求体长度限制，与Bandit的配置协同

   • 对于:multipart，要特别注意文件上传。务必设置length限制，并将上传的文件保存到临时目录，及时清理。
   • 对于:json，确保使用的解码器（如Jason）没有已知的安全漏洞，并且能安全地处理深度嵌套或巨大的JSON结构（防止JSON炸弹）。

5.2 会话管理与Cookie安全

会话是攻击者的主要目标。Phoenix默认使用cookie存储会话，密钥由Plug.Session加密。

• 使用强密钥：config/prod.exs中的secret_key_base必须足够长且随机。它用于签名和加密cookie。绝不能将硬编码的密钥提交到版本库。必须使用环境变量或运行时配置。

  # config/runtime.exs config :your_app, YourAppWeb.Endpoint, secret_key_base: System.fetch_env!("SECRET_KEY_BASE")

• 安全Cookie标志：确保生产环境的会话cookie设置了secure: true（仅HTTPS传输）和http_only: true（JavaScript无法访问）。这在Phoenix默认的Endpoint配置中通常是启用的。

  config :your_app, YourAppWeb.Endpoint, session: [ store: :cookie, key: "_your_app_key", signing_salt: "your_signing_salt", # 以下为关键安全设置 secure: true, http_only: true, same_site: "Lax" # 或 "Strict"，防御CSRF ]

  same_site: "Lax"是防御CSRF攻击的有效手段，它限制了第三方网站发起的跨站请求携带Cookie。

5.3 输入验证、输出编码与SQL注入防护

这是Web安全的经典领域，与服务器无关，但至关重要。

• Ecto与参数转换：永远不要将用户输入直接拼接进数据库查询。使用Ecto的查询语法或Repo.insert/update，它会进行参数化，从根本上防止SQL注入。

  # 危险！ query = "SELECT * FROM users WHERE email = '#{email}'" # 安全 from(u in User, where: u.email == ^email) |> Repo.all()

• HTML输出编码：当在模板中渲染用户提供的数据时，Phoenix的.heex模板（或EEx）默认会进行HTML转义。只有在明确使用raw/1或{:safe, ...}时才会渲染原始HTML。绝对不要对来自用户的不受信任数据这样做。

  <!-- 安全：自动转义 --> <div><%= @user_provided_content %></div> <!-- 危险：除非你100%确定内容安全并已清洗 --> <div><%= raw @user_provided_content %></div>

• 内容安全策略：前面在HSTS部分已经提到了CSP头。这是一个强大的防御XSS攻击的工具。它通过白名单机制，告诉浏览器哪些来源的资源（脚本、样式、图片等）可以加载和执行。配置CSP需要仔细测试，因为它可能会阻断你合法的第三方资源（如分析脚本、字体CDN）。建议从严格的策略开始，然后根据控制台报错逐步放宽。

6. 部署、监控与持续安全

安全不是一次性的配置，而是一个持续的过程。将Bandit应用部署到生产环境后，监控和运维实践同样关键。

6.1 生产环境部署考量

• 不要以root身份运行：使用一个专用的、低权限的系统用户来运行你的Elixir/BEAM进程。这可以限制漏洞发生时的破坏范围。
• 使用反向代理：虽然Bandit可以直接面向互联网，但在它前面放置Nginx、Caddy或云负载均衡器（如AWS ALB）是更佳实践。反向代理可以：
  • 处理SSL/TLS终止，减轻Bandit的CPU负担。
  • 提供静态文件服务（效率更高）。
  • 实现缓冲，保护后端应用免受慢客户端攻击。
  • 集中管理访问日志、IP黑白名单、基础速率限制等。
• 配置系统限制：确保操作系统级别的限制足够高，以支持Bandit的配置。特别是：
  • 文件描述符限制：ulimit -n应大于max_connections的两倍以上。
  • Epoll/Kqueue限制：对于高并发，可能需要调整内核网络参数，如net.core.somaxconn（TCP连接队列大小）。

6.2 日志记录与安全审计

Bandit和Phoenix会记录访问日志和错误日志。确保这些日志被妥善收集（使用Logstash、Fluentd等工具），并包含足够的信息用于安全审计，但又不能包含敏感信息。

• 记录关键安全事件：在Plug中记录失败的登录尝试、异常的请求模式（如大量404）、访问敏感路径的请求等。
• 避免记录敏感数据：绝对不要在日志中记录完整的请求体（尤其是包含密码、信用卡号、令牌的POST请求）、完整的授权头、会话Cookie等。Phoenix默认的日志记录器已经过滤了authorization和cookie头，但你需要检查自定义的日志逻辑。
• 使用结构化日志：考虑使用LoggerJSON这样的库，将日志输出为JSON格式，便于后续的日志分析系统（如ELK Stack）进行索引和查询，快速发现攻击模式。

6.3 依赖安全与漏洞管理

你的应用安全也取决于依赖项的安全。Elixir/Erlang生态系统有强大的工具来帮助管理。

1. mix audit：这是最重要的工具。它集成在Mix中，可以检查你的mix.lock文件，对照公共漏洞数据库（如Hex包管理器提供的安全公告），报告存在已知安全漏洞的依赖版本。必须将其纳入CI/CD流水线，每次依赖更新或推送代码时自动运行。

   mix deps.get mix audit

2. mix deps.unlock --check-unused：定期检查并移除未使用的依赖。每个不必要的依赖都可能引入未知的安全风险。

3. 关注安全公告：订阅Elixir论坛、HexPM博客以及你所使用关键库（如Bandit、Phoenix、Ecto）的GitHub发布页面，及时获取安全更新信息。

4. 自动化更新：使用Dependabot（GitHub）或类似服务，为你的项目自动创建依赖更新PR，特别是安全补丁更新。

6.4 常见问题与排查技巧实录

即使配置周全，线上环境仍可能遇到问题。以下是一些常见场景的排查思路：

问题1：服务器在高并发下停止响应，日志显示max_connections错误。

• 排查：首先检查系统当前连接数（netstat -an | grep :4000 | wc -l）和Bandit的max_connections设置。检查系统文件描述符限制（cat /proc/<pid>/limits）。使用观察工具（如:observer或Prometheus/Grafana监控）查看BEAM进程内存和消息队列状态。
• 解决：如果是连接数真的超过了业务需求，考虑扩容或优化客户端连接复用。如果是文件描述符限制，提高系统级限制（/etc/security/limits.conf）并确保启动脚本正确设置了ulimit。也可能是遇到了连接耗尽型DDoS攻击，此时需要结合反向代理的限流和云服务商的DDoS防护。

问题2：出现大量400 Bad Request错误，客户端报告请求被截断。

• 排查：检查错误请求的日志，看是否触发了request_line_length_limit、header_length_limit或max_request_body_length。可能是客户端（或恶意攻击）发送了过长的URL、Cookie头或请求体。
• 解决：确认这些限制是否设置得过低，无法满足合法的业务需求（例如，确实需要上传大文件）。如果业务不需要，保持严格的限制是安全的。对于API，可以给客户端返回明确的错误信息，如413 Payload Too Large。

问题3：在反向代理（如Nginx）后，conn.remote_ip显示的是代理服务器的IP，而非真实用户IP。

• 排查：这是典型配置问题。反向代理需要通过X-Forwarded-For头传递用户IP。
• 解决：
  1. 在Nginx配置中，确保设置了proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;。
  2. 在Phoenix中，使用Plug.Conn.get_peer_data/1或配置Phoenix.Endpoint来信任代理头。更安全的方法是使用remote_ip插件，它可以正确解析X-Forwarded-For并防止IP欺骗。

     # 安装依赖：{:remote_ip, "~> 1.0"} # 在router的pipeline中添加plug plug RemoteIp, headers: ["x-forwarded-for", "x-real-ip"], proxies: [{{10, 0, 0, 0}, 8}, {{172, 16, 0, 0}, 12}, {{192, 168, 0, 0}, 16}] # 信任的内网CIDR

     之后，conn.remote_ip就会是真实的客户端IP了。

问题4：如何验证TLS配置是否安全？

• 工具：使用外部扫描工具，如Qualys SSL Labs的SSL Server Test。只需输入你的域名，它会给出详细的评分和报告，指出TLS版本、加密套件、证书等方面的任何弱点。
• 命令行：使用openssl s_client -connect yourdomain.com:443 -tls1_2等命令测试特定协议版本的支持情况。

安全是一个没有终点的旅程。围绕Bandit和Elixir应用构建防御体系，需要将安全的思维融入到架构设计、编码习惯、部署流程和运维监控的每一个环节。从强制的HTTPS和精细的连接限制开始，到严格的应用层输入输出处理，再到持续的依赖漏洞扫描，每一层都在增加攻击者的成本，保护你的数据和业务。记住，没有绝对的安全，但通过系统性的实践，我们可以将风险降到可接受的水平，让Bandit的高性能真正为业务赋能，而非成为安全的短板。