作者：(美)Ryan Barnett
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
网站安全攻防秘笈：防御黑客和保护用户的100条超级策略试读：
前言
本书是一本网络安全防护基本操作手册。书中介绍的策略用于解决最严重的漏洞及对抗当今网络罪犯使用的攻击方法。无论你是在处理针对电子商务网站上的拒绝服务攻击，抑或在对你负责的银行系统的造假事件进行应急响应，还是在你新上线的社交网站上保护用户数据，翻阅本书都能找到相应场景下有效的应对方案。本书主要针对安全防护中的实际策略，会尽量少讲解安全理论，当然针对每个防护策略，为了让读者清楚攻击及漏洞原理，还是会提到一些相关背景知识。这些防护策略会一步一步地教你如何针对网站中的恶意行为进行防护。
这本书总结了我多年来在政府、教育、商业网站中，在对抗大量攻击者的多种攻击手法时所获取的信息和经验。Web的攻击方法非常复杂，本书提供的对应方案也同样复杂。不过，所有的安全防护方案，都基于以下的技能与技术（按相关性排序）：
·网站的漏洞与攻击
·HTTP协议
·Perl兼容正则表达式（Perl Compatible Regular Expression，PCRE）
·编程（Lua、Python与Perl）
·Web服务器管理（Apache服务器）
·Web浏览器
·UNIX操作系统（shell命令行与vim编辑器）
·HTML
·事件响应流程
·网络与TCP/IP协议
·一些基础的SQL（Structured Query Level）
本书所提到的安全防护策略包含了许多网站攻击的基本元素，但书中不会全面地讲解网站的脆弱性、攻击手法或者网站的开发安全问题。有很多其他的书籍与资料可以帮助开发者开发安全的网站。
概览
本书的目的是使你的网站更难被攻陷。网站（抑或所有的软件）都不是完全安全、无任何缺陷的。只要花上足够的时间，攻击者总能找到你网站的漏洞或配置错误，从而入侵网站或利用网站的用户信息。在继续阅读本书之前，你应该花点时间来接受这个事实。有许多人错误地认为，雇佣聪明的开发者或者部署商业安全产品可以避免他们的网站遭受攻击，可惜这不现实。比较现实的网站安全策略是了解你的网站交互流程，然后让你的网站更耐于攻击。如果你能让攻击者不得不花费更多的时间来探测你的站点，寻找漏洞，你就给了安全操作人员更多的机会去执行相应的防护策略。
本书提供相关知识以帮助你提高保护网站的技能，你将能够执行如下关键的网站安全相关任务：
·识别非正常访问的用户。
·关联用户与其在网站的行为。
·网站异常监控。
·判断网站是否泄漏敏感的用户或技术信息。
·发现新的或错误配置的网站资源。
·快速修复已发现漏洞。
·为已发现漏洞打虚拟补丁。
·以多种响应策略应对不同的攻击方法。
目标读者
本书的目标读者是网站防护人员。防护人员是指那些在黑客攻击下保护线上站点的人，他们不开发网站，但他们在网站上线之后负责维护。网站防护人员是提高网站安全性的三个主要的人群之一，另外两个人群是开发人员与审计人员。开发人员编写网站代码与功能实现，并负责未来的功能强化与维护。审计人员则是负责审计源代码和线上网站的渗透测试的信息安全团队。这三类人群的工作都是为了提高网站的安全性，不过本书主要针对网站防护人员。
本书架构
本书根据具体的网站安全问题将安全策略分成几个大部分。大多数的安全策略单独就能够解决一类安全问题，但仍有一些安全策略只能解决一大类问题中的一小部分，所以有必要实施多条安全策略以降低安全风险。
本书从高度抽象的角度来将内容分为三个部分：
·第一部分：“准备战场”
·第二部分：“非对称战争”
·第三部分：“战略反攻”
这几大部分的顺序基于逻辑流程与每个主题间的关系。如果你刚开始要部署一个新的网站，我们建议你从头读到尾。如果你已经有线上运行的网站，你可以跳到你关注的问题所对应的安全策略。在必要之处会提供相关章节的索引、策略或外部的资料。下面介绍每个部分及其章节。
第一部分：准备战场
如何打造能从容应对必将遭受网络攻击的网站平台，本书从这里开始介绍。当你上线一个新的网站时，你应该实施该部分介绍的安全策略。
·第1章“网站驻防”，列举了必须的步骤，以实现攻击识别告警，与管理适当的Web交互审计日志。你也会学到如何构建统一数据存储以在企业中实现攻击情报共享。
·第2章“漏洞检测与修复”，介绍了主动发现网站中漏洞的关键方法，以及在漏洞被发现之后，如何用一种叫“虚拟补丁”的方式临时修复漏洞。
·第3章“给黑客的陷阱”，介绍了几种在网站中构建陷阱的方法来快速而准确地识别恶意用户。
第二部分：非对称战争
在网站上线提供给真实用户之后，第二部分的安全策略将派上用场。这些安全策略都用于分析网站的执行，寻找恶意的行为。
·第4章“信用度与第三方信息关联”，描述了如何通过第三方的地理信息与IP地址黑名单来识别一些已知的恶意源并限制其访问。
·第5章“请求数据分析”，描述了多种防御，用于获取、归整化与分析入流量的HTTP请求；也会谈到如何识别构造出来的常见畸形请求。
·第6章“响应数据分析”，会讲解与第5章类似的技术，不过这次是分析出流量的HTTP响应数据。该章介绍的安全策略识别出来的异常通常意味着程序错误或者攻击已经成功。
·第7章“身份验证防护”，介绍如何识别暴力破解用户凭证、追踪成功与失败的认证尝试、追踪用户操作等。
·第8章“防护会话状态”，展示了与会话管理相关的安全问题，会讨论如cookie污染、会话劫持等攻击。
·第9章“防止应用层攻击”，关注接受外部用户输入但又没有进行任何校验而引发的问题；这里会提供应对如SQL注入攻击、远程文件包含、系统命令执行等攻击的防护手段。
·第10章“防止客户端攻击”，把视线转移到保护用户免受诸如跨站脚本、CSRF与点击劫持的攻击。同时也会关注如何对抗如Zeus等银行木马。还会介绍你的网站与浏览器如何协同实施安全策略。
·第11章“文件上传功能防护”，描述了黑客是如何利用你提供给用户的上传文件的功能，来把恶意代码注入到你的站点。这里的安全策略会介绍如何分析上传的附件来阻断恶意的数据。
·第12章“限制访问速率及程序交互流程”，介绍如何通过关联客户端请求的多个属性来识别出异常请求频率、异常交互流程与非常规使用方式。
第三部分：战略反攻
一旦你发现在网站上出现了恶意行为，下一步就是如何应对这些攻击。本书的最后一部分主要关注怎样高效地使用不同的响应方式来应对攻击。
·第13章“被动的响应动作”，介绍了对最终用户透明的应用程序快速修改，如增加系统日志等。
·第14章“主动的响应动作”，关注更主动地干扰针对最终用户的攻击。其中包括中断连接，暂时把源IP加入黑名单，或让用户强制退出等。
·第15章“侵入式响应动作”，介绍注入一些信息到客户端Web浏览器来执行防御或者获取攻击源的更多信息。
可能用到的工具
本书展示了在应对网站攻击时的实操性技巧。请记住，你是网站的防护者，你的工具集与提供给网站开发人员的工具是不一样的。你的主要工具是如Apache Web服务器或微软的IIS Web服务器之类的应用平台本身。可惜的是，网站漏洞与漏洞的防护需要较高级的逻辑与分析能力，而通常这些标准的Web服务器软件是不提供的。为了达到本书提到的这些高级防护能力，你需要在Web服务器上安装更多的模块或过滤器软件。[1]
本书介绍的防护策略用到了一个叫ModSecurity的开源网站防火墙（Web Application Firewall，WAF），可以用于Apache、Microsoft IIS与Nginx等Web服务器平台。也有其他的软件可用于网站架设基本的输入过滤功能，但都没能达到ModSecurity所能达到的水平。它能提供健壮的规则语言、数据修改、内容注入，甚至Lua的API，用于实现定制化的逻辑，或用于与其他工具进行集成。当阅读完本书后，我相信你会赞同我的观点：ModSecurity确实在网站防护上表现非常出色。当然，我们在相关地方也会介绍能提供类似功能的其他工具。
虽然本书提到的安全策略使用ModSecurity进行实施，但其本质的检测技术当然也适用于其他工具或者类库。比如OWASP的[2]AppSensor项目（我也是其贡献者）就包含本书提到的技术的Java代码例子。
在本书中你将要防护的网站使用了OWASP的Broken Web [3]Application（OWASP BWA）项目。这里提供虚拟机镜像提供下载，它包含许多有缺陷的网站供使用者学习与测试Web的漏洞与攻击，同时也提供许多真实应用流程的网站（如WordPress）。如果你在学习本书安全策略的同时想亲手实践的话，可以下载那个虚拟机镜像。
格式约定
为了协助读者从这些安全策略中学习到尽可能多的知识，本书中使用如下约定：
策略X-X：策略名
安全策略解决具体的Web应用安全问题，演示如何使用工具或脚本，通常也会提供一些调试与警告的信息样例。每一条安全策略都包含如下要素：
·外部软件的索引链接；
·可供下载的规则文件；
·可安装的第三方数据文件；
策略可能会包含其他关于该主题的扩展阅读材料的脚注。注意 这部分内容包括提示、线索、技巧等信息。重要提示 这部分内容包含重要的、不能忘记的信息。
文本格式所代表的意义：
·Ctrl+A表示键盘操作；
·我们用特殊字体表示代码：persisstence.properties；
·大部分的代码使用普通字体，粗体强调上下文中的重要代码或者与之前代码的差别。
源代码
当你实践本书讲解的例子时，可以手动输入代码，也可以使用本书附带的源代码文件。本书使用的所有源代码都可以从www.wiley.com/go/webappdefenderscookbook下载。
也可以在www.wiley.com上搜索本书。注意 由于许多书籍使用了类似的书名，使用ISBN可轻易地搜索到本书。本书英文版的ISBN是978-1-118-36218-1。
致谢
我必须首先感谢我的妻子Linda。当我第一次告诉她我想写另一本书的时候，虽然她知道这会牺牲很多，但还是非常支持我。非常感谢她的耐心及多个晚上不得不忍耐“刺耳的打字声”。无论在工作还是在生活上她都经常鼓励及支持我。完成这本书的写作不仅仅是我，同时还是我家人的功劳，因为这确实是多人努力的结果。Linda，我爱你，非常感谢你能成为我生活中的一分子。
然后要感谢Nick Percoco，Trustwave SpiderLabs的高级副总裁，感谢他对ModSecurity项目的支持及指派我为该项目的负责人。我非常荣幸能与我那些聪明有趣的朋友们共事，但我无法完全列举他们的名字，但我还是必须提到Breno Silva Pinto。Breno是ModSecurity的主要开发者，我们共同在这个项目上投入了两年的时间，我经常被他的洞察力、独特见解及高超的Web安全技术能力所折服，如果没有Breno对ModSecurity的贡献，就不会有这本书。
同时我也要感谢两位ModSecurity社区成员，他们身上有着突出的开源社区精神。感谢Christian Bockermann开发了诸如AuditConsole等支持工具，感谢Josh Zlatin经常在邮件列表里对用户的帮助，及对OWASP ModSecurity CRS的贡献。
最后，我想特别感谢OWASP的成员：Tom Brennan、Jim Manico及Sarah Baso，感谢他们不知疲倦的工作精神及对OWASP的奉献。同时我要感谢Michael Coates启动了AppSensor项目，以及Colin Watson和John Melton对该项目功能的扩展。
[1] http://www.modsecurity.org/
[2] https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project
[3] http://code.google.com/p/owaspbwa/作者简介
Ryan Barnett在网站安全业内非常有名气，因为他非常专业。他有10年的政府及商业网站防护经验，之后加入Trustwave SpiderLabs研究团队。他专注于应用层的防护研究，并负责开源的ModSecurity网站防火墙项目。
Ryan除了在Trustwave公司工作，同时也是开源社区中安全相关项目的积极参与者。他是OWASP的ModSecurity核心规则集项目负责人，同时也是OWASP Top Ten和AppSensor项目的参与者。他是网站安全联盟的成员，同时负责Web Hacking Incident Database及分布式Web蜜罐项目。他在SANS协会中担任导师，并参与整理Top 20 Vulnerabilities及CWE/SANS Top 25 Most Dangerous Programming Errors项目。
Ryan经常给那些对网站安全攻击、趋势及防护技术比较感兴趣的人提供咨询。他同时也是一些著名的业内会议的演讲者，如Black Hat、SANS AppSec会议、OWASP AppSecUSA等。
技术编辑简介
Michael Gregg是总部位于休斯敦的IT安全咨询公司Superior Solutions Inc（www.thesolutionfirm.com）的CEO。他的公司主要为财富杂志的Top 1000公司提供安全评估及渗透测试服务。他是著名的网络安全专家，他的文章经常被主流的出版物引用，经常担任网络广播节目的评论员及在出版物上发表文章。他也经常在诸如HackerHalted、Fusion及CA World等会议上发表演讲。 第一部分准备战场
·第1章 网站驻防
·第2章 漏洞检测与修复
·第3章 给黑客的陷阱
故用兵之法，无恃其不来，恃吾有以待之。——孙子《孙子兵法》“我们的网站安全吗？”如果你们公司的首席执行官这样问你，你会怎么回答？如果你回答说“是”，CEO可能会说：“证明给我看”。你会怎样证明你的网站防护得很好了呢？这里列举了部分回答并说明了每一个回答的缺陷。第一个：
我们的网站符合支付卡产业数据安全标准（Payment Card Industry Data Security Standard，PCI DSS），所以是安全的。
与其他标准一样，PCI DSS是最低限度的标准。这意味着，达到了标准并不能确保你的站点不会被入侵。PCI DSS本质上是关于风险转移而不是风险消除（从信用卡公司转移到商业银行）。如果企业不真正的接受通过加固他们的应用环境来消除风险这一观念，而只是做到PCI DSS要求的，这一套标准认证流程只不过是一纸空文。虽然PCI是值得信赖的，但请记住：
如果你的站点是安全的，通过PCI审计很容易，而只是通过了PCI审计，却不一定代表你的站点就是安全的。
通常来讲，标准都是以控制为目的的，往往以实际的措施为中心，但不分析或者监控这些措施在实际操作中能产生的效果。一位德高望重的安全领域领袖Richard Bejtlich，生动地说明了这个问题：
想象一个场景：一只美式足球队想要在一个季度赛中评估他们成功的概率。足球队管理人员决定量取每位球员的身高和体重、记录40码冲刺的速度、记录每位球员毕业的大学，他们收集了许多各方面的统计数据，并且花时间来讨论哪一个指标能最好地衡量他们球队取胜的概率。是需要体重超过300磅呢？还是接球员的鞋子要大于11码呢？抑或是首发阵容的球员都来自东北部呢？这些因素从分析来看似乎都与这支队伍的成败极其相关。但如果一名旁观者看到这种情况只会说：“看看计分板吧，你们的分数落后了42比7，你们有个1胜6败的记录了。真是一群失败者。”
这就是安全领域投入导向与输出导向的本质区别。只有到了线上环境，你才能知道为安全所做的准备是有用的，还是毫无用处的。由于开发环境与预发布环境很少能保持与线上环境完全一致，只有到了真正有恶意用户攻击的时候，你才能真正知道你的网站的安全性。
我们的网站部署了商业的Web安全设备，所以我们的Web应用是安全的。
如此回答是对安全厂商的过度信任而导致的。安全厂商的网站或产品说明书上说他们的产品会使网站更安全，而在实际环境中并非如此。如果使用不当，安全产品与其所防护着的网站一样会有问题。如果不恰当地配置和部署，它们甚至可能成为攻击者操纵或绕过的潜在问题。
由于我们使用了SSL，所以我们是安全的。
许多电子商务网站在显眼的地方显示一张锁的图片。这表明他们使用了从权威的认证授权机构（CA）购买的Secure Socket Layer（SSL）证书来确保网站安全。使用SSL证书有助于避免如下攻击：
·网络层截取。没使用SSL的话，数据是通过非加密通道在网上传输的。这意味可以从传输通道的路径的任意节点上截取到完整的网络流量。
·网络诈骗。没有有效的SSL站点的证书，攻击者很难模仿真正的站点进行钓鱼诈骗。
SSL的使用有助于缓解这两类问题，但有一个明显的弱点：SSL完全无法阻止一个恶意用户直接攻击网站。事实上，许多攻击者更喜欢把目标锁定在使用了SSL的网站上，因为这些加密通道可以在其他网络监控设备的监控下掩护他们的攻击。
我们有警报显示我们阻断了Web攻击，所以我们的Web应用是安全的。
阻断攻击尝试的证据有说服力但并不足够。当管理人员询问网站是否安全时，他们真正想知道的是，在网络攻防战中表现如何。CEO想要知道的是能否成功地在攻击中防护住网站的安全。从这个角度来讲，你并没有正面回答这个问题。再一次拿Richard Bejtlich的美式足球的例子来说明，这样的回答就像有人问你“谁赢得了超级碗美式足球赛”，你却用比赛的统计数据来回答，比如比赛局数，比赛耗时，取得的码数，而不是直接告诉他最终的分数。这不是真正需要的答案吧？提供被阻断的攻击的证据是一个有用的指标，但管理人员真正想要知道的是，有没有发生过成功的入侵。
有了这些概念作为背景知识，下面我列举一些对于衡量网站安全策略效果的最重要指标：
·日请求量，以数值（#）表示。它是网站流量的基准，提供其他指标的基础。
·检测到的攻击（真正），以数值（#）和占日总请求数的百分比（%）表示。通常这个指标表示网站的恶意流量与安全检测的准确性。
·未检测到的攻击（漏报），以数值（#）和占日总请求量的百分比（%）表示。通常这个指标能说明安全检测准确度的有效性。这就是在回答网络攻防战中表现如何时，被回避的关键指标。
·误拦截的请求量（误报），以数值（#）和占日总请求量的百分比（%）表示。这个数据也能说明安全检测的准确性。这个数据对于许多企业来说非常重要，因为阻断了正常的流量意味着可能会影响收入。企业必须有一套有效地追踪误报率的方法，这会干扰到网站正常的请求流量。
·攻击检测失败率，以百分比（%）表示。通常等于误报量与漏报量的和除以真正攻击量。这个百分比提供了你的网站安全检测准确率的总体衡量指标。
攻击检测失败率提供了在整个攻防战中表现的数据。可是，大部分企业都没有收集到足够获得此类安全衡量标准的数据。
我们没有检测到任何非正常行为，所以我们的站点是安全的。
退一步来讲，识别出网站中的异常行为似乎是对的。这种策略的不足就是需要收集到用于识别异常行为的数据。而大部分企业都没有恰当地配置他们的网站来收集足够的日志信息。他们默认使用Web服务器的如Common Log Format（CLF）的日志机制。这里是两条从Apache服务器拿来的CLF日志：
查看这日志，我们可以看到一些可疑的或异常行为的迹象。第一个可疑点是User-Agent字段是一种已知的WordPress攻击程序，WordPress Hash Grabber。第二个疑点是HTTP状态码，第一条日志是500系统内部异常的状态码，而第二条是200状态码。第一条日志的请求是用什么数据使网站产生一个错误呢？由于POST请求使用请求体来传递数据，而不是CLF日志格式记录的QUERY_STRING字段，我们无法知道攻击者传递了什么参数。这些请求服务器的响应内容是什么呢？这些都是很重要的问题，而CLF日志只记录了完整请求相关数据中的一小部分。比如，它不记录如Cookies等的请求头部、POST的请求体，或者其他的响应内容。没有恰当记录HTTP响应信息使我们无法回答关键的问题：“攻击者盗取了什么数据？”企业无法对Web相关安全事件进行恰当的响应的主要原因之一就是：缺乏足够的HTTP的审计日志。
我们在收集到的完整的HTTP审计日志中分析恶意行为的特征，并无发现任何异常行为，所以我们的Web应用是安全的。
很多企业犯的一个最大错误就是只使用以告警为中心的事件来识别潜藏的攻击。如果只记录已知的恶意行为的日志，怎么知道防护是否被绕过呢？新的攻击方式层出不穷。所以，只分析已知的告警问题是不够的。必须把所有HTTP请求的审计日志全部记录这样才能分析出多种特征恶意行为。
我们在收集到的完整的HTTP审计日志中分析恶意行为的特征，并没有发现任何异常行为，同时，我们也会定期地对网站进行测试来查找存在的安全漏洞，所以我们的Web应用是安全的。
识别并阻断网站攻击很重要，但把这些攻击的目标与已知存在的漏洞进行关联更重要。假设你的企业通过安全信息事件管理系统（SIEM）来集中管理安全事件，而你是安全分析人员。有一次针对微软的IIS服务器的漏洞的攻击请求被标注为恶意行为，如果你没有使用IIS服务器的话，应该把这种告警的威胁性调到足够低。如果你看到针对osCommerce程序的漏洞的攻击告警，且你的系统中使用了这个有漏洞的程序，则应该把这种告警的威胁性调高，因为这可能会造成危害。了解到部署了什么程序，以及它们是否存在特定的漏洞对于评估安全事件的危险等级非常重要。即使你对网站的漏洞进行了全面的评估，这个回答也依然不够完整，下面是最终的回答，将会告诉你最终答案：
我们在收集到的完整的HTTP审计日志中分析恶意行为的特征，并没有发现任何异常行为，同时，我们也会定期地对网站进行测试来查找存在的安全漏洞，还有定期测试我们的检测能力和事件响应能力，所以我们Web应用是安全的。
看到这最后的回答，你就会明白为什么前面的回答都是不完整的。即使你知道你的网站哪里有漏洞，你也必须模拟攻击来确认你的安全防御是有效的。安全人员发现了这些攻击吗？是否正确地实施了安全响应策略？他们花了多长时间来实施？实施是否有效？只有回答了这些问题，你才能真正地知道你的防御策略是否有效。第1章网站驻防
凡先处战地而待敌者佚，后处战地而趋战者劳。——孙子《孙子兵法》
本部分的策略将一步一步地引导你为线上网站构筑网络防线。
第一步就是为网站驻防，即分析你当前欲防护的Web应用并增强它的防护能力。1.1 基本防护措施策略1-1：实时网站请求分析
这个策略教你如何使用ModSecurity的Lua API来分析HTTP请求，来获得正常请求的特征。组成要素[1]
·ModSecurity参考手册
·Lua的API支持
·SecRuleScript指令
·Initcol动作
·RESOURCE持久存储[2]
·OWASP的ModSecurity核心规则集
·modsecurity_crs_40_appsensor_detection_point_2.0_setup.conf
·modsecurity_crs_40_appsensor_detection_point_2.1_request_exception.conf
·modsecurity_crs_40_appsensor_detection_point_3.0_end.conf
·appsensor_request_exception_profile.lua请求特征学习
本章介绍如何在网站中动态地创建输入白名单校验层。一旦校验成功，这个附加的安全层会在一些关键地方使用规则，这可以让你发现那些不符合白名单的异常请求。本策略教你如何分析网站中真实Web用户的请求来识别如下的请求每一种网站资源的特征：
·HTTP请求方法
·参数的个数（最多与最少区间）
·参数名
·参数的长度（最长与最短区间）
·参数类型
·标志位（如/path/to/foo.php？param）
·数字（如/path/to/foo.php？param=1234）
·字符（如/path/to/foo.php？param=abcd）
·字符与数字（如/path/to/foo.php？param=abcd1234）
·Email（如/path/to/foo.php？param=foo@bar.com）
·路径（如/path/to/foo.php？param=/dir/somefile.txt）
·URL（如/path/to/foo.php？param=http://somehost/dir/file.txt）
·安全的文本（如/path/to/foo.php？param=some_data-12）注意 为什么需要一个额外的输入校验层呢？网站开发中有一个范式是导致大多数漏洞的核心问题：Web开发人员无法控制Web客户端的软件。可以思考一下这个问题，因为这是导致我们后续遇到的大部分问题的关键因素。Web开发人员通常认为发送给客户端的数据是用户控制不了的，有这种认识是由于Web浏览器的用户接口设置（如数据是存放在隐藏字段或下拉框中）或使用了运行于浏览器端的如JavaScript的安全控制代码。因为这个错误的观念，Web开发人员错误地假定了Web请求中的数据不会被修改，在服务器端的处理程序仅仅简单地接收输入并执行相应操作。事实上，攻击者使用定制的浏览器插件或使用客户端代理很容易就可以绕过浏览器的安全机制。有了这类工具，攻击者很容易绕过浏览器的安全控制代码，并修改浏览器接受或发出的HTTP数据。创建持久化存储
利用ModSecurity，我们可以使用每个资源的持久化存储来对不同的请求和客户端进行关联分析。我们得在请求的早期阶段先初始化RESOURCE持久化存储机制（就是ModSecurity请求hook中的phase：1）：
Initcol:resource动作使用REQUEST_HEADERS：Host和REQUEST_FILENAME变量作为组合键，以避免相似命名的资源冲突。两个setvar动作声明我们所要分析的请求数量以及需要命中多少次才把它们加入到白名单列表中。Post-Process分析
我们希望分析对请求造成的延时最小化，所以是在Http响应已经发送到客户端之后的Post-Process阶段进行的（ModSecurity中的phase：5）。我们需要做一些安全检查，来确定我们分析的无恶意输入的正常请求。我们不想正在分析的数据被攻击的请求所污染。
我们不想分析如下四种场景的请求所产生的数据：
·如果HTTP响应码是404，则请求的资源是不存在的。在这种情况下，我们不进行分析，同时也会把该资源键去掉，删除持久化存储。可以通过setvar：！resource.KEY动作来实现。
·如果HTTP响应码是4xx或者5xx，则是程序发现该请求有异常，所以我们也不分析它。
·我们将在策略1-3中讨论OWASP ModSecurity核心规则集（CRS），它能够对请求分析得出异常权值，如果异常权值大于0，我们也不对其进行分析。
·最后，我们已经介绍了分析模型所需要的足够流量，已经到了实施模式，所以我们跳过分析。
如果这些预检查都通过了，我们就使用appsensor_request_exception_profile.lua脚本对请求特征进行分析，就是SecRuleScript指令。样本测试
为了测试这些分析方法，我们可以看一下WordPress应用中给用户提交博客评论的例子。图1-1显示了一个用户可以发表评论的典型表单。图1-1 WordPress发表评论的表单
当用户点击提交评论的按钮，网站会收到HTTP请求：
我们可以看到REQUEST_METHOD是POST方法，在REQUEST_BODY请求体中有以下6个参数：
·author是发表评论的用户名，每个用户都有不同的值。
·email是发表评论的用户的e-mail地址，每个用户都有不同的值。
·url是发表评论的用户的网址，每个用户都有不同的值。
·comment是用户发表的评论内容文本，每个用户都有不同的值。
·submit是一个固定的文本，每个用户都有相同的值。
·comment_post_ID代表每个评论的唯一值。
我们使用curl HTTP客户端工具向WordPress应用发送两个请求，用带有不同参数值的请求模拟用户的流量。
这些请求会触发Lua脚本分析请求的特征，并且把得到的数据保存在资源持久化存储文件中。当分析单请求数达到了需要的数量阀值后（这里是100个请求），脚本会添加enfourcement变量，会让Lua脚本停止对于此资源的请求流量分析，并激活对后续请求的检查。当分析的阶段结束后，我们可以使用Christian Bockermann中用Java写的工具jwall-tools来查看资源持久化存储中保存的数据。
这里是一个命令行示例，使用了sed命令来规范化输出：
如你所见，我们可以对后续发起的请求进行校验。第5章会用例子来分析如何识别出异常的请求和攻击。重要提示 这个策略仅仅是第一步，从真实流量分析出结果之后对输入进行校验。但这还不全面，主要有如下3个不足：
没有自动重新学习机制
这个实现主要的不足是没有自动重新学习的机制。当规则从分析阶段进入到生效阶段，该实现就固定在那个模式上了。这意味着如果你对于已存在的功能进行更新而重新发布代码，就可能需要把之前的分析去掉，然后重新进行学习。
持久化存储的大小限制
对于每个资源，基于你所需要分析的特征数，SDBM持久化存储可能会达到最大限制。在ModSecurity的持久化存储中，默认可以使用约800字节的存储空间。如果你达到了此限制，就会看到如下错误信息：
在这种情况下，你需要修改Apache Portable Runtime（APR）代码包来变更可用的默认存储限制。如果你需要更多的空间，可以下载APR和APR-Util包，然后在/dbm/sdbm/sdbm_private.h文件中编辑#define PAIRMAX宏的设置：
为了使APR/APR-Util包的修改生效，需要重新编译Apache与ModSecurity。
排除资源
如果你想排除特定的URL不进行分析，你可以使用一些排除规则，这些规则使用@pmFromFile来从外部文件中获取排除的URL。可以把需要排除的URL写入这个文件中。
[1] http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual
[2] https://www.owasp.org/index.php Category:OWASP_ModSecurity_Core_Rule_Set_Project策略1-2：使用加密的哈希值来避免数据篡改
本策略说明如何使用ModSecurity为输出的HTML数据添加额外的哈希值，以避免篡改数据进行攻击。在撰写这本书的时候，ModSecurity 2.7版本已经支持本策略所提到的技术。后续的版本可能会有不同的或更强大的功能。组成要素[1]
·ModSecurity参考手册
·2.7或更高版本
·SecDisableBackendCompression指令
·SecContentInjection指令
·SecStreamOutBodyInspection指令
·SecEncryptionEngine指令
·SecEncryptionKey指令
·SecEncryptionParam指令
·SecEncryptionMethodRx指令
正如前面所提到的，Web开发者不能依赖于Web浏览器的安全机制来防止数据篡改。打个比喻，当下一次请求中使用到我们上一次返回的响应数据时，该如何使用另外的方法来避免我们返回的响应数据被篡改呢？一种方法就是解析返回的HTML响应体，在选择框的地方插入额外的字符串。我们插入的数据将作为请求参数校验字符串。它们是选择框的元素的哈希值并经过必要的加密处理。这个方法可以检测到客户端是否尝试篡改数据。下面是一些ModSecurity实现基本的哈希保护的指令和规则。
第一个指令SecDisableBackendCompression只有在反向代理中才需要。当网站使用gzip格式压缩响应内容时，需要使用此指令，这样我们才能解析HTML数据并对其进行修改。ModSecurity的默认配置是在内存中复制一份请求数据，并在真实连接中修改这些数据。接下来的两个指令是一起使用的，这样原来缓存着的响应数据才能被修改并替换。接下来的4个SecEntryption指令是基本配置。在这个配置中，ModSecurity使用一个随机的加密因子作为哈希盐值，并依次把符合正则表达式的HTML的href相关信息进行哈希处理。最后的SecRule用于校验该哈希值。
让我们看一个实际的例子。图1-2现实的是一个WordPress页面的HTML，其中包含href超链接。这个链接包含一个URL以及请求参数p，其中p值为4。图1-2 WordPress页面的HTML代码，包含一个带参数的Href链接
在加密的规则生效后，ModSecurity解析响应的HTML内容，并根据配置查找需要添加哈希值的元素。这里是从debug日志中取出的内部添加哈希的流程。
完成之后，所有的href链接都被更新为增加一个rv_token字段，这个字段是整个URI（包括所有的请求参数数据）的哈希值，如图1-3所示。图1-3 WordPress页面的HTML代码，包含一个带rv_token字段的已更新href链接
由于存在这层保护，任何对URI或者参数的修改都会引起ModSecurity告警（如果配置了阻断的话，则请求会被阻断）。以下章节介绍两种你可能会遇到的攻击场景。哈希值不匹配
如果攻击者试图修改参数值，ModSecurity会产生一个告警。比如，如果攻击者在参数值中添加一个引号（一种SQL注入攻击测试的常用方法），系统会产生如下告警：丢失哈希值
如果攻击者把rv_token字段删除，该尝试也会引发如下告警：
本书的第二部分的策略会说明这种注入校验值的方法如何应对其他类型的攻击。
[1] http：//sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual策略1-3：安装OWASP的ModSecurity核心规则集（CRS）
本策略展示如何安装OWASP ModSecurity CRS，并快速配置攻击检测规则。撰写本书的时候，CRS的版本是2.2.5。请注意这里所提到的规则逻辑CRS在后续的版本中可能会改变。组成要素[1]
·OWASP ModSecurity CRS版本2.2.5
·modsecurity_crs_10_setup.conf
·modsecurity_crs_20_protocol_violations.conf
·modsecurity_crs_21_protocol_anomalies.conf
·modsecurity_crs_23_request_limits.conf
·modsecurity_crs_30_http_policy.conf
·modsecurity_crs_35_bad_robots.conf
·modsecurity_crs_40_generic_attacks.conf
·modsecurity_crs_41_sql_injection_attacks.conf
·modsecurity_crs_41_xss_attacks.conf
·modsecurity_crs_45_trojans.conf
·modsecurity_crs_47_common_exceptions.conf
·modsecurity_crs_49_inbound_blocking.conf
·modsecurity_crs_50_outbound.conf
·modsecurity_crs_59_outbound_blocking.conf
·modsecurity_crs_60_correlation.confOWASP ModSecurity CRS简介
ModSecurity本身并无内置的防护功能，必须有规则配置才有用。每个用户都可以自己配置规则，但是大部分用户没那么多时间或者没有足够的经验来根据所面对的攻击开发规则。因此Trustwave SpiderLab研究团队开发了OWASP ModSecurity CRS。与其他基于已知漏洞的特征的攻击检测与防护系统不同，CRS提供了通用攻击检测来应对一些Web网站中的未知漏洞。这种通用的方法的好处就是可以防护外部提供的软件与自有编码实现的网站。核心规则集内容
针对通用的网站，核心规则集提出了如下技术：
·HTTP防护检测那些违反HTTP协议与使用策略的请求。
·实时的黑名单查找表使用了第三方的IP信用度信息。
·基于Web的恶意软件检测通过使用Google Safe Browsing API检测恶意的Web内容。
·HTTP拒绝服务攻击防护阻挡HTTP洪泛攻击，并减缓DoS攻击。
·通用Web攻击防护识别通用的Web安全攻击。
·自动化检测识别机器人、爬虫、扫描器与其他的简单的恶意行为。
·与AV扫描集成识别文件上传攻击识别通过网站上传的恶意文件。
·追踪敏感数据追踪信用卡的使用并阻断信息泄漏行为。
·木马防护检测对木马的访问。
·网站瑕疵识别在网站不正确配置的时候会告警。
·错误信息识别与隐藏会区分服务器发送出去的程序错误信息。配置选项
下载并解压了CRS文件后，你需要在Apache的httpd.conf配置文件中添加如下配置来激活CRS文件：
在重启Apache服务器之前，需要重新检查并上传modsecurity_crs_10_setup.conf.example文件。这是控制CRS工作的最核心的文件。你可以控制如下CRS相关的行为：
·检测的模式：传统的或异常权值模式；
·异常权值的危害等级；
·异常权值的阀值（阻断的阀值）；
·开启/关闭阻断模式；
·选择记录事件的位置（使用Apache的error_log和/或ModSecurity的审计日志）。
我们要尽量利用操作模式的控制能力，对规则做一些更改。大多数规则会使用通用的block动作而不是其他特定的动作。这个变更使用户能够适应SecDefaultAction指令的配置，这些都是从SecRule集成而来的。使用第三方的规则集是比较好的方法，毕竟我们的目标是检测问题，而不是告诉用户如何响应。同时我们会把日志的动作去除掉，这样用户可以控制日志要写到哪个文件中。传统检测模式（独立的规则）
传统检测模式（如IDS/IPS模式）是新的默认检测模式。这是最基本的模式，所有的规则逻辑都是独立的。就像HTTP，单条规则是无状态的。这意味着规则之间不会互相协作，且规则不知道前面的规则匹配了什么。规则仅仅使用它自己的逻辑进行检测。在这种模式下，如果匹配一个规则，就会根据该规则的配置进行阻断或记录日志。
如果你想让CRS以传统检测模式运行，可以看下modsecurity_crs_10_setup.conf文件中的SecDefaultAction是否使用了如deny的干扰动作：
有了这个配置，当请求匹配到一条CRS规则就会被拒绝访问，同时告警信息会记录到Apache的error_log文件及ModSecurity的审计日志文件中。这里是一个SQL注入攻击的告警信息：传统检测模式的优缺点
优点：
·用户很容易理解检测逻辑。
·可以获得更好的性能（更低的访问延迟和资源占用），因为只要匹配了规则，后续的处理流程就不会进行了。
试读结束[说明：试读内容隐藏了图片]