【Web安全】CRLF注入攻击深度解析:原理、场景与安全测试防御指南

文章目录

    • 前言:为什么CRLF注入是安全测试不可忽视的威胁?
    • [1. CRLF注入核心原理:从字符定义到协议依赖](#1. CRLF注入核心原理:从字符定义到协议依赖)
      • [1.1 什么是CRLF?](#1.1 什么是CRLF?)
      • [1.2 CRLF在HTTP协议中的关键作用](#1.2 CRLF在HTTP协议中的关键作用)
      • [1.3 CRLF注入的本质:格式混淆攻击](#1.3 CRLF注入的本质:格式混淆攻击)
    • [2. CRLF注入典型利用场景与安全测试方法](#2. CRLF注入典型利用场景与安全测试方法)
      • [2.1 反射型XSS:通过CRLF分隔HTTP头与体注入恶意代码](#2.1 反射型XSS:通过CRLF分隔HTTP头与体注入恶意代码)
        • [2.1.1 漏洞原理](#2.1.1 漏洞原理)
        • [2.1.2 测试案例与步骤](#2.1.2 测试案例与步骤)
        • [2.1.3 测试注意事项](#2.1.3 测试注意事项)
      • [2.2 绕过浏览器XSS Filter:注入HTTP头禁用防护机制](#2.2 绕过浏览器XSS Filter:注入HTTP头禁用防护机制)
        • [2.2.1 漏洞原理](#2.2.1 漏洞原理)
        • [2.2.2 测试案例与步骤](#2.2.2 测试案例与步骤)
        • [2.2.3 测试扩展](#2.2.3 测试扩展)
      • [2.3 日志注入:伪造日志记录干扰安全审计](#2.3 日志注入:伪造日志记录干扰安全审计)
        • [2.3.1 漏洞原理](#2.3.1 漏洞原理)
        • [2.3.2 不同环境下的日志注入特征](#2.3.2 不同环境下的日志注入特征)
        • [2.3.3 测试案例与步骤](#2.3.3 测试案例与步骤)
    • [3. Java生态下的日志注入:不仅是CRLF](#3. Java生态下的日志注入:不仅是CRLF)
      • [3.1 漏洞根源:字符串拼接与未过滤的用户输入](#3.1 漏洞根源:字符串拼接与未过滤的用户输入)
      • [3.2 主流日志框架的CRLF注入风险对比](#3.2 主流日志框架的CRLF注入风险对比)
      • [3.3 测试Java日志注入的实操步骤](#3.3 测试Java日志注入的实操步骤)
        • [3.3.1 信息收集:确定日志框架与输入点](#3.3.1 信息收集:确定日志框架与输入点)
        • [3.3.2 漏洞验证:注入CRLF构造恶意日志](#3.3.2 漏洞验证:注入CRLF构造恶意日志)
        • [3.3.3 漏洞利用:构造复杂攻击场景](#3.3.3 漏洞利用:构造复杂攻击场景)
    • [4. CRLF注入防御机制与安全测试验证](#4. CRLF注入防御机制与安全测试验证)
      • [4.1 通用防御原则:输入验证与输出编码](#4.1 通用防御原则:输入验证与输出编码)
        • [4.1.1 输入验证](#4.1.1 输入验证)
        • [4.1.2 输出编码](#4.1.2 输出编码)
      • [4.2 Log4j2的防御配置与测试验证](#4.2 Log4j2的防御配置与测试验证)
        • [4.2.1 安全配置示例](#4.2.1 安全配置示例)
        • [4.2.2 防御验证测试](#4.2.2 防御验证测试)
      • [4.3 Logback的防御实现与测试验证](#4.3 Logback的防御实现与测试验证)
        • [4.3.1 自定义转换器代码](#4.3.1 自定义转换器代码)
        • [4.3.2 配置与验证](#4.3.2 配置与验证)
      • [4.4 JUL的防御实现与测试验证](#4.4 JUL的防御实现与测试验证)
        • [4.4.1 自定义Formatter代码](#4.4.1 自定义Formatter代码)
        • [4.4.2 配置与验证](#4.4.2 配置与验证)
    • [5. CRLF注入安全测试 checklist](#5. CRLF注入安全测试 checklist)
      • [5.1 信息收集阶段](#5.1 信息收集阶段)
      • [5.2 漏洞探测阶段](#5.2 漏洞探测阶段)
      • [5.3 漏洞验证阶段](#5.3 漏洞验证阶段)
      • [5.4 防御验证阶段](#5.4 防御验证阶段)
    • 结语:CRLF注入的防御核心与测试价值

前言:为什么CRLF注入是安全测试不可忽视的威胁?

在Web安全领域,XSS、SQL注入等漏洞往往是安全测试的重点,但CRLF注入作为一种利用特殊字符实现攻击的漏洞,常因隐蔽性强、利用场景多样而被忽视。事实上,CRLF注入可通过篡改HTTP响应、伪造日志记录、绕过安全防护等方式,对系统的机密性、完整性和可用性造成严重威胁。

1. CRLF注入核心原理:从字符定义到协议依赖

1.1 什么是CRLF?

CRLF是"回车(Carriage Return)+换行(Line Feed)"的缩写,对应ASCII字符集中的\r(十六进制0x0d)和\n(十六进制0x0a)。在计算机发展早期,这两个字符的组合被用于表示文本中的"换行"操作------其中\r让光标回到行首,\n让光标下移一行,两者配合实现了文本排版的换行效果。

不同操作系统对"换行"的表示存在差异:

  • Windows系统使用\r\n(即CRLF)作为换行符;
  • Linux、Unix系统使用\n(仅换行)作为换行符;
  • 早期Mac OS使用\r(仅回车)作为换行符,现代macOS已与Linux统一为\n

这种差异看似微小,却为CRLF注入提供了基础------当系统对用户输入的特殊字符处理不当,攻击者可通过注入CRLF(或单一\r/\n)篡改数据格式,实现恶意操作。

1.2 CRLF在HTTP协议中的关键作用

CRLF的危险性核心源于其在HTTP协议中的"格式定义"作用。HTTP协议明确规定:HTTP头部(Header)与消息体(Body)通过两个连续的CRLF(即\r\n\r\n)分隔 ,而头部内部的字段(如LocationSet-Cookie)则通过单个CRLF分隔。

例如,一个标准的HTTP响应格式如下:

http 复制代码
HTTP/1.1 200 OK\r\n
Date: Fri, 27 Jun 2024 10:00:00 GMT\r\n
Content-Type: text/html\r\n
Content-Length: 100\r\n
\r\n  <!-- 两个CRLF分隔Header与Body -->
<html><body>Hello World</body></html>

在这个结构中,CRLF是协议解析的"锚点":浏览器或服务器通过识别CRLF的位置,确定头部字段的边界和消息体的起始。一旦攻击者能够控制HTTP消息中的部分内容(如URL参数、表单输入),并将其注入到HTTP头部中,就可以通过插入CRLF改变协议结构------例如,在头部中注入新的字段,或提前分隔头部与体,从而执行恶意操作。

1.3 CRLF注入的本质:格式混淆攻击

CRLF注入的本质是"格式混淆攻击":攻击者通过注入特殊控制字符(CRLF),破坏数据的预期格式,使解析器(如浏览器、日志系统)将恶意内容误认为合法结构的一部分。

这种攻击的成功依赖两个前提:

  1. 用户输入可控 :攻击者能够向系统传入包含CRLF(或\r/\n)的恶意数据;
  2. 输入未被过滤:系统未对用户输入中的CRLF进行转义或删除,直接将其嵌入到协议头部、日志等结构化数据中。

理解这一本质,是安全测试人员挖掘CRLF注入漏洞的核心思路------即寻找"用户输入直接进入结构化数据(如HTTP头、日志行)且未过滤特殊字符"的场景。

2. CRLF注入典型利用场景与安全测试方法

CRLF注入的利用场景广泛,涵盖Web应用、日志系统、网络协议等多个层面。对于安全测试人员而言,需针对不同场景设计专属测试用例,精准验证漏洞是否存在。

2.1 反射型XSS:通过CRLF分隔HTTP头与体注入恶意代码

2.1.1 漏洞原理

当Web应用将用户输入(如URL参数)直接作为HTTP响应头的字段值(如LocationRefresh)时,攻击者可注入CRLF强制分隔头部与体,在消息体中插入HTML/JavaScript代码,触发反射型XSS。

典型场景:URL跳转功能。例如,应用通过http://example.com/redirect?url=xxx接收跳转地址,并在响应头的Location: xxx中返回。若xxx未被过滤,攻击者可构造包含CRLF的url参数,使Location字段被截断,后续内容被解析为消息体。

2.1.2 测试案例与步骤

测试目标 :某网站的URL跳转功能(参数为url),响应头中包含Location: {url参数值}

测试步骤

  1. 构造恶意URL参数,注入两个CRLF(%0d%0a%0d%0a,URL编码后的\r\n\r\n)分隔头部与体,后续拼接XSS代码:

    复制代码
    http://example.com/redirect?url=%0d%0a%0d%0a<img src=x onerror=alert(document.domain)>
  2. 使用Burp Suite等工具发送请求,查看响应结构。若响应如下,则漏洞存在:

    http 复制代码
    HTTP/1.1 302 Found\r\n
    Date: Fri, 27 Jun 2024 10:30:00 GMT\r\n
    Location:\r\n  <!-- 注入的第一个CRLF截断Location字段 -->
    \r\n  <!-- 注入的第二个CRLF分隔Header与Body -->
    <img src=x onerror=alert(document.domain)>\r\n  <!-- 恶意代码被解析为Body -->
  3. 在浏览器中访问该URL,若弹出包含域名的对话框,证明XSS触发成功。

2.1.3 测试注意事项
  • 部分服务器会对Location字段进行合法性校验(如限制为http://开头),需先通过测试确认参数是否完全可控;
  • 若直接注入\r\n无效,可尝试单独注入\r%0d)或\n%0a),因部分系统可能仅过滤其中一种字符;
  • 需结合浏览器类型测试:不同浏览器对HTTP协议的解析严格度不同,部分浏览器可能忽略不规范的CRLF分隔。

2.2 绕过浏览器XSS Filter:注入HTTP头禁用防护机制

2.2.1 漏洞原理

现代浏览器(如Chrome、IE)内置XSS Filter防护机制,当检测到URL或响应中包含明显的XSS特征(如<script>标签)时,会拦截并阻止恶意代码执行。但该机制可被CRLF注入绕过------通过注入X-XSS-Protection: 0头部字段,强制浏览器关闭XSS Filter。

X-XSS-Protection是浏览器提供的防御头,其取值含义如下:

  • 0:禁用XSS Filter;
  • 1:启用XSS Filter(默认),检测到XSS时阻止页面加载;
  • 1; mode=block:启用XSS Filter,检测到XSS时不渲染恶意部分。

若应用允许用户输入注入到HTTP头部,攻击者可先注入X-XSS-Protection: 0,再注入XSS代码,绕过浏览器防护。

2.2.2 测试案例与步骤

测试目标 :某应用的用户输入(如username参数)被嵌入到HTTP响应头的X-User字段中(X-User: {username})。

测试步骤

  1. 构造包含CRLF和X-XSS-Protection: 0的参数:

    复制代码
    http://example.com/profile?username=%0aX-XSS-Protection:%200%0d%0a%0d%0a<script>alert(1)</script>

    (注:%0a\n%0d\r%20为空格)

  2. 发送请求后,若响应头中新增X-XSS-Protection: 0,且消息体包含<script>alert(1)</script>,则防护被绕过:

    http 复制代码
    HTTP/1.1 200 OK\r\n
    X-User:\r\n  <!-- 注入的\n截断X-User字段 -->
    X-XSS-Protection: 0\r\n  <!-- 注入的新头部 -->
    \r\n  <!-- 分隔Header与Body -->
    <script>alert(1)</script>\r\n
  3. 在浏览器中访问该URL,若成功弹出对话框,证明绕过成功。

2.2.3 测试扩展
  • X-XSS-Protection外,还可尝试注入其他恶意头部,如Set-Cookie(篡改会话)、Content-Security-Policy(禁用CSP防护)等;
  • 部分服务器会限制自定义头部的注入(如禁止包含:的输入),需通过URL编码(如%3a替代:)绕过;
  • 测试不同浏览器的兼容性:Chrome对X-XSS-Protection的支持已逐步弱化,而IE仍依赖该机制,需针对性验证。

2.3 日志注入:伪造日志记录干扰安全审计

2.3.1 漏洞原理

日志系统(如Web服务器日志、应用程序日志)通常按固定格式记录信息(如时间、用户ID、操作内容),每行代表一条记录。若日志内容包含用户可控数据且未过滤换行符(CRLF或\n),攻击者可注入换行符伪造新的日志记录,干扰安全审计或掩盖攻击痕迹。

例如,某应用的日志格式为:

复制代码
[2024-06-27 10:00:00] User [username] performed action [action]

username可控,攻击者输入admin\n[2024-06-27 10:00:01] User [attacker] performed action [delete],日志将被拆分为两条记录:

复制代码
[2024-06-27 10:00:00] User [admin
[2024-06-27 10:00:01] User [attacker] performed action [delete]

从而伪造"攻击者执行删除操作"的虚假记录。

2.3.2 不同环境下的日志注入特征
  • Linux/Unix环境 :日志换行符为\n%0a),部分系统支持\t(制表符,%09)对齐伪造内容,\x7F(删除符,%7F)可擦除前一个字符;
  • Windows环境 :日志换行符为\r\n%0d%0a),需注入完整CRLF才能正确拆分记录;
  • Web服务器日志(如Nginx、Apache):通常包含客户端IP、请求方法、URL等,若URL参数可控,可注入换行符伪造"正常请求"记录。
2.3.3 测试案例与步骤

测试目标 :某Java Web应用使用Log4j记录用户登录日志,格式为"User login: " + username + ", IP: " + ip

测试步骤

  1. 在登录页面的username字段输入恶意内容:

    复制代码
    normal_user\n[2024-06-27 11:00:00] INFO User login: admin, IP: 192.168.1.100\n[2024-06-27 11:00:01] ERROR Database deleted by user: admin
  2. 提交登录请求后,查看应用日志文件。若日志中出现三条记录(正常记录+两条伪造记录),则漏洞存在:

    复制代码
    [2024-06-27 10:59:59] INFO User login: normal_user
    [2024-06-27 11:00:00] INFO User login: admin, IP: 192.168.1.100
    [2024-06-27 11:00:01] ERROR Database deleted by user: admin
  3. 进一步验证:注入包含特殊格式的内容(如\t对齐字段),观察日志是否被完美伪造。

3. Java生态下的日志注入:不仅是CRLF

Java作为主流的Web开发语言,其日志框架(如Log4j2、Logback、JUL)的CRLF注入风险尤为突出。由于Java应用常将用户输入直接拼接至日志消息,若未过滤CRLF和其他特殊字符,极易引发日志伪造等问题。

3.1 漏洞根源:字符串拼接与未过滤的用户输入

Java日志注入的典型不安全代码如下:

java 复制代码
// 危险示例:直接拼接用户输入到日志消息
String userInput = request.getParameter("username");
logger.info("User login attempt: " + userInput);

userInputadmin\n[INFO] User login successful: attacker时,日志将被拆分为两行,伪造"attacker登录成功"的记录。

漏洞根源在于:

  • 使用字符串拼接(+)将用户输入嵌入日志消息,而非参数化日志;
  • 日志框架默认不会过滤\r\n等控制字符,直接按原始内容输出。

3.2 主流日志框架的CRLF注入风险对比

日志框架 默认是否过滤CRLF 内置防护机制 风险等级
Log4j2 支持%encode转换器(可指定CRLF编码) 中(可通过配置防御)
Logback 无内置防护,需自定义转换器 高(依赖手动开发)
JUL 无内置防护,需自定义Formatter 高(依赖手动开发)

安全测试人员需根据目标应用使用的日志框架,设计针对性的测试方案。

3.3 测试Java日志注入的实操步骤

3.3.1 信息收集:确定日志框架与输入点
  1. 识别日志框架

    • 查看应用部署包中的JAR包:Log4j2包含log4j-core-*.jar,Logback包含logback-classic-*.jar,JUL为Java原生(无额外JAR);
    • 通过错误页面或调试信息获取框架类型(如Log4j2的错误日志会包含org.apache.logging.log4j包名)。
  2. 定位用户输入日志点

    • 常见场景:登录日志(用户名、IP)、操作日志(用户ID、操作内容)、异常日志(错误信息包含用户输入);
    • 测试方法:在所有用户可控参数(URL、表单、Cookie)中传入特殊标记(如test_log_injection),搜索日志文件确认是否被记录。
3.3.2 漏洞验证:注入CRLF构造恶意日志
  1. 构造包含换行符的测试输入:

    • Linux环境:normal_input%0a[INFO] Fake log from attacker%0a\n);
    • Windows环境:normal_input%0d%0a[INFO] Fake log from attacker%0d%0a\r\n)。
  2. 将输入传入已识别的日志点(如登录用户名),查看日志文件:

    • 若日志中出现两行记录(原始记录+伪造记录),则漏洞存在;
    • 进阶测试:注入包含日志级别(如ERROR)、时间戳的内容,验证是否能伪造高优先级日志。
3.3.3 漏洞利用:构造复杂攻击场景
  • 权限混淆 :伪造[ADMIN] User [attacker] granted root access日志,误导管理员;
  • 攻击溯源干扰 :注入[INFO] Attack source IP: 192.168.1.100(伪造他人IP);
  • 日志溢出 :注入大量换行符(如%0a重复1000次),使日志文件体积暴增,消耗磁盘空间。

4. CRLF注入防御机制与安全测试验证

防御CRLF注入的核心是"过滤或转义用户输入中的特殊控制字符"。安全测试人员不仅需要挖掘漏洞,还需验证防御措施的有效性,确保修复方案切实可行。

4.1 通用防御原则:输入验证与输出编码

4.1.1 输入验证
  • 白名单校验 :仅允许符合预期格式的输入(如URL跳转参数限制为http://https://开头,用户名限制为字母数字组合);
  • 长度限制:限制用户输入长度,降低长字符串注入的危害。

测试验证方法 :向参数传入包含CRLF的超长字符串(如1000个%0a),若被拦截或截断,则验证通过。

4.1.2 输出编码

根据输出场景对特殊字符进行编码:

  • 嵌入HTTP头部时:将\r编码为%0d\n编码为%0a(URL编码);
  • 嵌入日志时:将\r替换为\\r\n替换为\\n(转义为可见字符)。

测试验证方法 :注入\r\n后,查看输出结果是否被转义(如日志中显示\\r\\n而非实际换行)。

4.2 Log4j2的防御配置与测试验证

JSON 格式当前最常用,官方强烈建议使用 JSON 模板布局接收 JSON 输出(参考:https://logging.apache.org/log4j/2.x/manual/pattern-layout.html)。

需要注意的是,%encode{%msg}{CRLF}%n 仅能针对 CRLF(\r\n)进行编码防御,无法处理其他特殊字符(如 JSON 中的引号、反斜杠等)的注入风险。因此在选择编码方式时,需结合实际打印内容的场景:

  • 若仅需防御 CRLF 注入,可使用 %encode{%msg}{CRLF}%n
  • 当打印内容为 JSON 字符串时,%encode{%msg}{JSON}%n 是更安全的选择,因为它能对 JSON 格式中所有特殊字符(包括引号、反斜杠、控制字符等)进行合规编码,避免破坏 JSON 结构或引入注入风险。

编码方式的通用格式如下:

shell 复制代码
# [HTML|XML|JSON|CRLF] 表示根据场景选择一种对应的编码类型
enc{pattern}{[HTML|XML|JSON|CRLF]}
encode{pattern}{[HTML|XML|JSON|CRLF]}
4.2.1 安全配置示例
xml 复制代码
<!-- log4j2.xml 配置 -->
<Appenders>
    <Console name="Console" target="SYSTEM_OUT">
        <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5level %logger{36} - %encode{%msg}{JSON}%n" />
    </Console>
</Appenders>
4.2.2 防御验证测试
  1. 注入包含CRLF的日志内容:test%0a%0dmalicious_log
  2. 查看日志输出,若显示test\r\nmalicious_log(无换行),则编码生效;
  3. 测试边界情况:注入混合特殊字符(如\t\x7F),确认是否被一并处理。

4.3 Logback的防御实现与测试验证

Logback无内置CRLF编码机制,需通过自定义转换器实现过滤。

4.3.1 自定义转换器代码
java 复制代码
// SafeLogConverter.java
package com.example.security;

import ch.qos.logback.classic.pattern.ClassicConverter;
import ch.qos.logback.classic.spi.ILoggingEvent;

public class SafeLogConverter extends ClassicConverter {
    @Override
    public String convert(ILoggingEvent event) {
        String message = event.getFormattedMessage();
        if (message == null) {
            return "";
        }
        // 转义CRLF及其他控制字符
        return message
            .replace("\r", "\\r")
            .replace("\n", "\\n")
            .replace("\t", "\\t")
            .replace("\u007F", "\\x7F");
    }
}
4.3.2 配置与验证

logback.xml中注册转换器:

xml 复制代码
<configuration>
    <conversionRule conversionWord="safeMsg" converterClass="com.example.security.SafeLogConverter" />
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %safeMsg%n</pattern>
        </encoder>
    </appender>
    <root level="info">
        <appender-ref ref="CONSOLE" />
    </root>
</configuration>

测试验证

  1. 注入user\nadmin作为日志内容;
  2. 若日志显示user\\nadmin(无换行),则转换器生效;
  3. 检查代码覆盖率:验证转换器是否对所有日志字段(如线程名、MDC数据)生效(需根据业务需求扩展代码)。

4.4 JUL的防御实现与测试验证

Java原生日志框架JUL需通过自定义Formatter实现CRLF过滤。

4.4.1 自定义Formatter代码
java 复制代码
// SafeFormatter.java
import java.util.logging.Formatter;
import java.util.logging.LogRecord;

public class SafeFormatter extends Formatter {
    @Override
    public String format(LogRecord record) {
        String message = record.getMessage();
        if (message == null) {
            message = "";
        }
        // 过滤CRLF
        String safeMessage = message
            .replace("\r", "\\r")
            .replace("\n", "\\n");
        // 格式化日志(包含时间、级别等)
        return String.format("[%tF %tT] %s: %s%n",
            record.getMillis(), record.getMillis(),
            record.getLevel(), safeMessage);
    }
}
4.4.2 配置与验证

logging.properties中配置:

properties 复制代码
handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.formatter=com.example.security.SafeFormatter

测试验证

  1. 使用JUL记录包含\r\n的消息:logger.info("Input: " + "test\r\nattack")
  2. 若控制台输出[2024-06-27 15:00:00] INFO: Input: test\\r\\nattack,则防御生效。

5. CRLF注入安全测试 checklist

为帮助安全测试人员系统化开展测试,以下提供CRLF注入测试 checklist,涵盖从信息收集到防御验证的全流程:

5.1 信息收集阶段

  • 确定目标应用使用的HTTP服务器(Nginx/Apache/IIS)及操作系统(Windows/Linux);
  • 识别应用使用的日志框架(Log4j2/Logback/JUL)及版本;
  • 梳理用户可控输入点(URL参数、表单字段、Cookie、请求头);
  • 确认输入是否被传入HTTP响应头(如LocationSet-Cookie)或日志系统。

5.2 漏洞探测阶段

  • 对每个输入点注入%0d%0a(CRLF)、%0a(LF)、%0d(CR),观察响应头是否新增字段;
  • 注入%0d%0a%0d%0a测试是否能分隔HTTP头与体,插入HTML代码;
  • 注入%0aX-XSS-Protection: 0测试是否能添加HTTP头,绕过浏览器防护;
  • 向日志输入点注入\n[INFO] Fake log,检查日志是否被拆分。

5.3 漏洞验证阶段

  • 复现反射型XSS场景,确认恶意代码在浏览器中执行;
  • 验证日志注入能否伪造不同级别(INFO/ERROR)的日志记录;
  • 测试不同浏览器/操作系统下的漏洞触发情况(兼容性验证)。

5.4 防御验证阶段

  • 检查输入是否被过滤(CRLF是否被删除);
  • 检查输出是否被编码(CRLF是否被转义为\\r\\n);
  • 验证日志框架的安全配置(如Log4j2的%encode是否生效);
  • 测试边界输入(超长字符串、混合特殊字符)的处理效果。

结语:CRLF注入的防御核心与测试价值

防御CRLF注入的关键不在于"消灭CRLF字符",而在于"明确输入边界"------通过严格的输入验证、场景化的输出编码,确保用户输入无法篡改数据的预期格式。

本文是「Web安全」系列内容,点击专栏导航查看全部内容。

相关推荐
drjava_20196 小时前
DeFi代币授权安全指南:保护您的数字资产
安全·区块链
Akshsjsjenjd6 小时前
Ansible 变量与加密文件全解析:从基础定义到安全实践
前端·安全·ansible
云盾安全防护6 小时前
WAF与CDN在网络安全中的协同作用
网络·安全·web安全
喜葵8 小时前
前端安全防护深度实践:从XSS到CSRF的完整安全解决方案
前端·安全·xss
饮长安千年月8 小时前
第四章 windows实战-emlog
windows·web安全·网络安全·github
Sh3r10ck9 小时前
【Hack The Box】Puppy Write Up
安全
荣淘淘9 小时前
互联网大厂Java面试三大回合全解析:从语言特性到性能安全
java·安全·面试·性能优化·互联网·多线程·语言特性
李白你好10 小时前
一款高效、强大的子域名爬取工具,帮助安全研究者和渗透测试人员快速收集目标域名的子域名信息
安全
wanhengidc10 小时前
徐州服务器:机柜租用具体包含哪些内容?
运维·服务器·安全