应用安全越来越重要 —— 互联网上看到的大多数安全事件基本都和应用安全，尤其是 WEB 应用安全有关(随便翻翻 wooyun 之类的就知道了)。最近几年的工作基本都和应用安全有关系，借着这个机会也总结一下自己的一些观点。
WEB 应用安全的常见思路
这篇文章不包含 DDoS 和业务相关的问题 —— DDoS 主要是网络层解决的问题，我没有把放到 WEB 应用安全这个领域讨论;业务相关的安全，特别是业务特性或者业务规则带来的安全问题也不在这个讨论范围之内。
下面只是大概的分类，并不严谨。
通过工具来增强 WEB 应用的安全
工具往往对应用开发过程影响非常小，只需要在部署的时候做些配置通常即可起到防护作用。工具主要以防火墙、WAF 和各类扫描产品为主。这些产品通常基于特征，很难做到深入理解被防护的 WEB 应用，这类产品通常会遇到很多挑战。
由于被保护的 WEB 应用对这些传统工具而言属于“黑盒”，要做到有效防护的代价很高。个人认为目前传统的产品更适合做大范围、简单、一致的控制，作为基础设施提供无差别的防护;也比较适合做应急措施，用来缩短 Heartbleed、Struts2 远程代码执行 这类漏洞的响应时间，为彻底修复赢得足够的时间窗口。
误报率和漏报率：这个大家都懂的，从防病毒软件到 IDS、IPS 到扫描器到 WAF，只要是基于特征库，基本都走在这个“平衡木”上，很难做到既误报低又漏报少。
0day：WEB 应用的 0day 太容易发现，WEB 应用数量又是海量，真正充分考虑到安全的 WEB 应用更是凤毛麟角。因此，无法做到发现 0day 甚至是快速响应 0day，会非常难受，而简单基于规则很难做到发现“未知”。
普适和定制：应用的数量远多于操作系统、数据库这些通用组件，应用层的安全检查或者防护工具无法做到覆盖所有的应用(例如：wordpress 和企业 ERP 就是完全不同的应用)。
难以根除的漏洞：只要不修改代码、不打补丁，这个应用就始终存在安全漏洞。一旦出现盲点，导致攻击者能够直接访问到被保护的 WEB 应用，安全防护措施都失去意义(现在的业务系统都是分布式系统，非常容易出现盲点;尤其是各种 CloudWAF，被绕过的可能性更大)。
通过开发流程控制增强 WEB 应用的安全
SDLC 是 Secure Software Development Life Cycle 的简写，有时候也被称作 SDL 或 SSDLC 。SDLC 的特点是在软件开发的生命周期中都“嵌入”了安全的“基因”，对软件产品的安全性有本质上的提高。业界最成功的案例就是 Microsoft 通过 10 多年持续的实施 SDL 让其 Windows 产品的安全性有了极大地提高。
SDLC 需要安全完全嵌入到软件开发的全部活动中，非常依赖于人员和工具(漏洞扫描、代码审计、……)，也遇到了一些挑战。
从某种意义上来说，SDLC 仅仅适用于部分公司，这类公司往往有稳定的开发组织、流程;业务变化没有那么快，相对比较稳定;业务非常依赖于 IT 或者软件开发。扩展阅读：如何在你的组织内采用 SDL。
时间：业务特性本身的发展非常快，业务特性的开发往往是整个开发团队产出的核心度量指标(特别是互联网公司)。新增的安全特性会延缓产品开发进度，因此开发团队会倾向于事后修复;而持续的业务压力又会让历史遗留问题修复很难获得高优先级。本质上是个“技术债”的问题。
专业知识：开发团队的核心能力并不是安全。即使是 SDLC 中的培训，也是仅以解决常见、通用攻击方式为目标，在面临新型攻击或复杂攻击时，需要对安全领域有全面和深入的了解。很难有开发人员在跟上开发领域技术发展的同时，还能补上安全领域知识，并且跟上安全领域的发展。
资源：大型组织所开发使用的应用往往非常庞大，在开发流程中构建完整的 SDLC 无论是在组织还是技术层面会让大多数的组织难以承受。
误报：SDLC 中使用了非常多的工具，这些工具通常都会产生误报，这些误报非常容易形成开发人员抵制 SDLC 的原因。
流程：SDLC 本质上是让开发人员重视安全，越多开发人员有安全意识公司开发出来的产品就越安全。但坏处是，大多数情况下很难有人能评估安全是否已经足够了(甚至做过头了)。特别是在时间压力很大且缺乏专业知识的情况下，SDLC 非常容易流于形式。
通过增强对应用感知和持续监控增强 WEB 应用安全
核心思路就是在开发过程中引入安全相关的 SDK 或 Plugin。通过这些 Plugin 或 SDK 让应用具备缺省的安全功能，且让安全人员持续的对应用进行监视、响应(可以更深入到应用的运行时)。
这个思路中关键的一项技术目前被 Gartner 定义为 RASP。RASP 是 Runtime Application Self-Protection 的缩写，通过嵌入 Application 的代码让应用程序自身具备一定的威胁感知和防护能力。通常 RASP 天生就可以与其他安全产品集成。Gartner 总结了这个定义，并且在 Hype Cycle for Application Security, 2014 中给把他列入到了 On the Rise 阶段(属于被关注的新技术，但并没有大范围地被验证和接受)。而 Gartner 早在 2012 年就在 Runtime Application Self-Protection: A Must-Have, Emerging Security Technology 介绍过，并预计 2017 年 25% 的应用会具备这个这个能力。目前已经有多家厂商推出了产品，开源社区也有相应的实现。
HP: HP Application Defender
Prevoty: Prevoty Runtime Application Security
waratek: Application Security for Java
OWASP: AppSensor 是一个开源方案。
Shandowd: Shadowd 是一个开源方案。
RASP 相关技术
目前 RASP 还处于一个发展的阶段，尚未像防火墙等常见的安全产品一样有非常明确的功能边界(scope)，我个人认为这样的技术甚至非常有可能会和 WAF 形成一定的融合。因此这里介绍主要是记录自己的理解为主，考虑到 AppSensor 和 Shadowd 的思路并不一样，分开记录。
AppSensor
目前 AppSensor 发展到了第二版，OWASP 这个项目目标一方面是给出完整的指南，另一方面也希望能提供一个完整的实现。目前 AppSensor 的 2.0 版以 Application-Specific Real Time Attack Detection & Response 核心。下面是 AppSensor 的一些核心文档可以看看。
OWASP AppSensor Getting Started
OWASP AppSensor Guide v2.0.1 EN
OWASP AppSensor Reference Implementation
AppSensor DetectionPoints 梳理了 AppSensor 集成到应用后提供实现的监测点，安全人员可以利用这些监测点达到实时监测攻击行为。
AppSensor ResponseActions 梳理了 AppSensor 集成到应用后提供实现的监测点，安全人员可以利用这些监测点达到实时响应攻击行为。
构成部分
AppSensor 一开始遵从的设计理念就包括：语言无关、插件式、为“As A Service” 设计。因此，包括 Analysis Engine 在内的各个部分都可以被替换。
AppSensor Core：必选组件。这个是 AppSensor 的核心，对外提供了 AppSensor 的各种接口。
Analysis Engine：必选组件。这是用来判断是否为攻击行为，如何对此行为进行响应的核心组件，目前还仅仅是个示例的实现。
Storage：用来存储数据的组件。
Configuration：用来对客户端和服务端配置的组件。
Access Controller：仅使用 SOAP、REST 的时候为必须。主要用于对接口进行访问控制。
Reporting：可选组件。这是用于对 AppSensor 进行管理很重要的组件，如果需要利用其他的系统获取 AppSensor 的数据，就需要使用 Reporting 组件。目前支持 Simple Logging、WebSockets、REST API 的方式对外提供数据输出。
部署方式
目前支持四种部署方式：
REST Web Service
SOAP Web Service
Thrift
Local (Embedded Java)
Shadow Daemon
Shadow Daemon 还是个非常早期的项目，目前给自己的定位还是 WAF ，通过嵌入到 WEB 应用中的代码来收集信息，通过这些信息来判断某次访问是否为恶意行为并作出判断。
构成部分
Shadow Daemon 目前由三部分构成。
Shadow Daemon Connector：和语言有关，主要是利用语言特性嵌入到 WEB 应用中收集数据，放到 Shadowd 中进行处理。
shadowd：收集 Shadow Daemon Connector 的数据，根据配置和规则进行响应。
shadow_ui: Shadow Daemon 的用户界面。