现代框架可让开发人员将来自请求查询和正文的 HTTP 请求参数自动绑定至模型对象，以便于开发和提高生产率。如果绑定器未正确配置为控制将哪些 HTTP 请求参数绑定到哪些模型属性，攻击者可能会滥用模型绑定过程并设置不应向用户控件公开的任何其他属性。即使模型属性未出现在 Web 表单或 API 合约中，也可能会发生这种绑定。

例 1：以下 ASP.NET MVC 控制器方法 (Register) 从 Web 表单进行访问，该表单要求用户通过提供其姓名和密码注册帐户。

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

其中，RegisterModel 类定义为：

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

Details 类定义为：

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

设想Example 1 中的场景，攻击者可能会浏览应用程序并发现 RegisterModel 模型中存在 Details 属性。如果出现这种情况，攻击者可能会尝试覆盖分配给这些属性的当前值。
如果攻击者可以找到这些内部属性，并且框架绑定器未正确配置为禁止绑定这些属性，则攻击者可能会通过发送以下请求注册管理员帐户：

name=John&password=****&details.is_admin=true

示例 1：开发人员学习编写的第一个 .NET 程序如下所示：

public class MyClass {
  ...
    Console.WriteLine("hello world");
  ...
}

当多数程序员深入了解 .NET 的许多精妙之处时，有一部分人仍会依赖于这一基础知识，始终使用 Console.WriteLine() 来编写消息以进行标准输出。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检阅的代码是在初始开发阶段之后生成的，那么 Console.WriteLine 的使用可能会在转向结构化日志记录系统的过程中导致一个漏洞。

示例 1：通常，开发人员学习编写的第一个 Go 程序如下所示：

...

func foo(){
    fmt.Println("Hello World")
}

多数开发人员深入了解 Go 的许多精妙之处后，一部分人员始终使用 fmt.Println() 编写进行标准输出的消息。

问题在于，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标识符、时间戳，以及将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍接受结构化日志记录，但许多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在初始开发阶段之后生成的，那么使用 os.Stdout 或 os.Stderr 进行日志记录使用可能会在转向结构化日志记录系统的过程中导致漏洞。

示例 1：早期的 Node.js 开发人员编写的简单程序可从 stdin 读取并将其再次写回 stdout，可能如下所示：

process.stdin.on('readable', function(){
    var s = process.stdin.read();
    if (s != null){
      process.stdout.write(s);
    }
});

虽然大多数程序员继续学习，尤其是关于 JavaScript 和 Node.js 的细微之处，但很多程序员仍依赖于这一基础知识，始终使用 process.stdout.write() 编写标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在开发阶段的初期生成的，那么对 process.stdout 或 process.stderr 的使用可能会在转向结构化日志记录系统的过程中导致漏洞。

示例 1：开发人员学习编写的第一个 Kotlin 程序如下所示：

class MyClass {
    ...
            println("hello world")
    ...
    }
}

多数程序员深入了解 Kotlin 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终使用 print 或 println 编写进行标准输出的消息。

问题在于，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标识符、时间戳，以及可能最重要的将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在初始开发阶段之后生成的，那么使用标准输出或错误流可能会在转向结构化日志记录系统的过程中导致一个漏洞。

示例 1：开发人员学习编写的第一个 Python 程序通常如下所示：

sys.stdout.write("hello world")

多数程序员深入了解 Python 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终编写进行标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在开发阶段的初期生成的，那么对 sys.stdout 或 sys.stderr 的使用可能会在转向结构化日志记录系统的过程中导致漏洞。

例 1：开发人员学习编写的第一个 Ruby 程序通常将包括如下功能：

...
puts "hello world"
...

多数程序员深入了解 Ruby 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终使用 Kernel.puts 编写进行标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在初始开发阶段之后生成的，那么对 Kernel.puts、Kernel.warn 或 Kernel.printf 的使用可能表示转向结构化日志记录系统过程中的一时疏忽。
如果公司策略规定不能使用这些 API，则仍然可以通过使用日志系统将信息打印到系统输出流来绕过此策略。

例 2：下面的代码使用了 Logger 类，但是将信息记录到系统输出流：

require 'logger'
...
logger = Logger.new($stdout)
logger.info("hello world")
...