新書推薦：
《
投机苦旅：一位投机客的凤凰涅槃
》
售價：NT$
403.0
《
重返马赛渔场：社会规范与私人治理的局限
》
售價：NT$
316.0
《
日子慢慢向前，事事慢慢如愿
》
售價：NT$
254.0
《
场景供应链金融：将风口变成蓝海
》
售價：NT$
509.0
《
汗青堂丛书146·布鲁克王朝：一个英国家族在东南亚的百年统治
》
售價：NT$
418.0
《
人生是旷野啊
》
售價：NT$
332.0
《
甲骨文丛书· “安国之道”：英国的殖民情报系统及其在亚洲的扩张
》
售價：NT$
403.0
《
台北人（2024版）
》
售價：NT$
398.0
|
| 編輯推薦： |
1.
国际信息安全专家10余年网络安全实战经验的结晶，手把手教你如何提高网站的安全性。
2.从网站上线时、上线后到遭受攻击，深入剖析网站常见漏洞、攻击及原理，详细讲解应对各种攻击和漏洞的实用策略。
|
| 內容簡介： |
|
本书全方位介绍网站安全防护措施与策略，这些策略用于解决最严重的漏洞及对抗当今网络罪犯使用的攻击方法。无论你是在处理电子商务网站上的拒绝服务攻击，还是对银行系统的造假事件进行应急响应，或者是对新上线的社交网站保护用户数据，翻阅本书都能找到某种场景下有效的应对方案。本书是作者多年来在政府、教育、商业网站中与大量攻击者的多种攻击对抗中获取的经验总结，内容丰富，实用性强。本书根据网站安全问题的类型将安全策略分为三大部分。第一部分“准备战场”介绍如何打造必将遭受网络攻击的网站平台。当你上线一个新的网站时，应该实施本部分介绍的安全策略。第二部分“非对称战争”介绍如何分析网站的数据，发现恶意行为。第三部分“战略反攻”介绍当发现网站上的恶意行为后如何应对这些攻击，以及怎样高效地使用不同的响应方式来应对攻击。
|
| 關於作者： |
Contents目录
译者序
序 言
前 言
作者简介
第一部分 准备战场
第1章 网站驻防 6
策略1-1：实时网站请求分析 6
策略1-2：使用加密的哈希值来避免数据篡改 13
策略1-3：安装OWASP的ModSecurity核心规则集（CRS） 17
策略1-4：集成入侵检测系统的特征 29
策略1-5：使用贝叶斯分析方法检测攻击数据 33
策略1-6：打开全量HTTP审计日志 42
策略1-7：只记录有意义的请求 45
策略1-8：忽略静态资源的请求 46
策略1-9：在日志中屏蔽敏感数据 47
策略1-10：使用Syslog把告警发送到中央日志服务器 50
策略1-11：使用ModSecurity AuditConsole 53
第2章 漏洞检测与修复 57
策略2-1：被动地识别漏洞 59
策略2-2：主动地识别漏洞 67
策略2-3：手动转换漏洞扫描结果 75
策略2-4：扫描结果自动转换 79
策略2-5：实时资源评估与虚拟补丁修复 86
第3章 给黑客的陷阱 100
策略3-1：添加蜜罐端口 101
策略3-2：添加假的robots.txt的Disallow条目 102
策略3-3：添加假的HTML注释 107
策略3-4：添加假的表单隐藏字段 111
策略3-5：添加假的cookie 114
第二部分 非对称战争
第4章 信用度与第三方信息关联 121
策略4-1：分析用户的地理位置信息 123
策略4-2：识别使用了代理的可疑客户端 128
策略4-3：使用实时黑名单查找（RBL） 131
策略4-4：运行自己的RBL 137
策略4-5：检测恶意的链接 140
第5章 请求数据分析 148
策略5-1：访问请求体的内容 148
策略5-2：识别畸形请求体 154
策略5-3：规范化Unicode编码 158
策略5-4：识别是否进行多次编码 161
策略5-5：识别编码异常 164
策略5-6：检测异常的请求方法 168
策略5-7：检测非法的URI数据 172
策略5-8：检测异常的请求头部 174
策略5-9：检测多余的参数 183
策略5-10：检测缺失的参数 185
策略5-11：检测重复的参数名 187
策略5-12：检测异常的参数长度 189
策略5-13：检测异常的参数字符集 193
第6章 响应数据分析 196
策略6-1：检测异常的响应头部 196
策略6-2：检测响应头部的信息泄漏 206
策略6-3：访问响应体内容 209
策略6-4：检测变更的页面标题 211
策略6-5：检测响应页面大小偏差 214
策略6-6：检测动态内容变更 216
策略6-7：检测源代码泄漏 219
策略6-8：检测技术数据泄漏 223
策略6-9：检测异常的响应时延 226
策略6-10：检测是否有敏感用户数据泄漏 228
策略6-11：检测木马、后门及webshell的访问尝试 231
第7章 身份验证防护 234
策略7-1：检测是否提交了通用的或默认的用户名 235
策略7-2：检测是否提交了多个用户名 238
策略7-3：检测失败的身份验证尝试 240
策略7-4：检测高频率的身份验证尝试 242
策略7-5：规范化身份验证失败的提示信息 247
策略7-6：强制提高密码复杂度 250
策略7-7：把用户名和SessionID进行关联 253
第8章 防护会话状态 258
策略8-1：检测非法的cookie 258
策略8-2：检测cookie篡改 264
策略8-3：强制会话过期 268
策略8-4：检测客户端源位置在会话有效期内是否变更 273
策略8-5：检测在会话中浏览器标识是否变更 279
第9章 防止应用层攻击 288
策略9-1：阻断非ASCII字符的请求 288
策略9-2：防止路径遍历攻击 291
策略9-3：防止暴力浏览攻击 294
策略9-4：防止SQL注入攻击 296
策略9-5：防止远程文件包含（RFI）攻击 299
策略9-6：防止OS命令攻击 302
策略9-7：防止HTTP请求偷渡攻击 305
策略9-8：防止HTTP响应分割攻击 307
策略9-9：防止XML攻击 309
第10章 防止客户端攻击 315
策略10-1：实现内容安全策略（CSP） 315
策略10-2：防止跨站脚本（XSS）攻击 323
策略10-3：防止跨站请求伪造（CSRF）攻击 331
策略10-4：防止UI伪装（点击劫持）攻击 337
策略10-5：检测银行木马（浏览器中的木马）攻击 340
第11章 文件上传功能防护 345
策略11-1：检测文件大小 345
策略11-2：检测是否上传了大量文件 347
策略11-3：检测文件附件是否有恶意程序 348
第12章 限制访问速率及程序交互流程 352
策略12-1：检测高速的应用访问速率 352
策略12-2：检测请求响应延迟攻击 361
策略12-3：识别异常的请求间隔时间 367
策略12-4：识别异常的请求流程 368
策略12-5：识别显著增加的资源使用 369
第三部分 战略反攻
第13章 被动的响应动作 375
策略13-1：追踪异常权值 375
策略13-2：陷阱与追踪审计日志 380
策略13-3：发送E-mail告警 381
策略13-4：使用请求头部标记来共享数据 389
第14章 主动的响应动作 394
策略14-1：跳转到错误页面 394
策略14-2：断开连接 398
策略14-3：阻断客户端的源地址 399
策略14-4：通过变更防护条件（DefCon）级别来限制地理位置访问 404
策略14-5：强制请求延迟 406
策略14-6：假装被成功攻破 412
策略14-7：把流量重定向到蜜罐 418
策略14-8：强制退出网站 420
策略14-9：临时限制账户访问 425
第15章 侵入式响应动作 428
策略15-1：JavaScript cookie测试 428
策略15-2：通过验证码测试来确认用户 430
策略15-3：通过BeEF来hook恶意用户 433
|
| 目錄：
|
Contents目录
译者序
序 言
前 言
作者简介
第一部分 准备战场
第1章 网站驻防 6
策略1-1：实时网站请求分析 6
策略1-2：使用加密的哈希值来避免数据篡改 13
策略1-3：安装OWASP的ModSecurity核心规则集（CRS） 17
策略1-4：集成入侵检测系统的特征 29
策略1-5：使用贝叶斯分析方法检测攻击数据 33
策略1-6：打开全量HTTP审计日志 42
策略1-7：只记录有意义的请求 45
策略1-8：忽略静态资源的请求 46
策略1-9：在日志中屏蔽敏感数据 47
策略1-10：使用Syslog把告警发送到中央日志服务器 50
策略1-11：使用ModSecurity AuditConsole 53
第2章 漏洞检测与修复 57
策略2-1：被动地识别漏洞 59
策略2-2：主动地识别漏洞 67
策略2-3：手动转换漏洞扫描结果 75
策略2-4：扫描结果自动转换 79
策略2-5：实时资源评估与虚拟补丁修复 86
第3章 给黑客的陷阱 100
策略3-1：添加蜜罐端口 101
策略3-2：添加假的robots.txt的Disallow条目 102
策略3-3：添加假的HTML注释 107
策略3-4：添加假的表单隐藏字段 111
策略3-5：添加假的cookie 114
第二部分 非对称战争
第4章 信用度与第三方信息关联 121
策略4-1：分析用户的地理位置信息 123
策略4-2：识别使用了代理的可疑客户端 128
策略4-3：使用实时黑名单查找（RBL） 131
策略4-4：运行自己的RBL 137
策略4-5：检测恶意的链接 140
第5章 请求数据分析 148
策略5-1：访问请求体的内容 148
策略5-2：识别畸形请求体 154
策略5-3：规范化Unicode编码 158
策略5-4：识别是否进行多次编码 161
策略5-5：识别编码异常 164
策略5-6：检测异常的请求方法 168
策略5-7：检测非法的URI数据 172
策略5-8：检测异常的请求头部 174
策略5-9：检测多余的参数 183
策略5-10：检测缺失的参数 185
策略5-11：检测重复的参数名 187
策略5-12：检测异常的参数长度 189
策略5-13：检测异常的参数字符集 193
第6章 响应数据分析 196
策略6-1：检测异常的响应头部 196
策略6-2：检测响应头部的信息泄漏 206
策略6-3：访问响应体内容 209
策略6-4：检测变更的页面标题 211
策略6-5：检测响应页面大小偏差 214
策略6-6：检测动态内容变更 216
策略6-7：检测源代码泄漏 219
策略6-8：检测技术数据泄漏 223
策略6-9：检测异常的响应时延 226
策略6-10：检测是否有敏感用户数据泄漏 228
策略6-11：检测木马、后门及webshell的访问尝试 231
第7章 身份验证防护 234
策略7-1：检测是否提交了通用的或默认的用户名 235
策略7-2：检测是否提交了多个用户名 238
策略7-3：检测失败的身份验证尝试 240
策略7-4：检测高频率的身份验证尝试 242
策略7-5：规范化身份验证失败的提示信息 247
策略7-6：强制提高密码复杂度 250
策略7-7：把用户名和SessionID进行关联 253
第8章 防护会话状态 258
策略8-1：检测非法的cookie 258
策略8-2：检测cookie篡改 264
策略8-3：强制会话过期 268
策略8-4：检测客户端源位置在会话有效期内是否变更 273
策略8-5：检测在会话中浏览器标识是否变更 279
第9章 防止应用层攻击 288
策略9-1：阻断非ASCII字符的请求 288
策略9-2：防止路径遍历攻击 291
策略9-3：防止暴力浏览攻击 294
策略9-4：防止SQL注入攻击 296
策略9-5：防止远程文件包含（RFI）攻击 299
策略9-6：防止OS命令攻击 302
策略9-7：防止HTTP请求偷渡攻击 305
策略9-8：防止HTTP响应分割攻击 307
策略9-9：防止XML攻击 309
第10章 防止客户端攻击 315
策略10-1：实现内容安全策略（CSP） 315
策略10-2：防止跨站脚本（XSS）攻击 323
策略10-3：防止跨站请求伪造（CSRF）攻击 331
策略10-4：防止UI伪装（点击劫持）攻击 337
策略10-5：检测银行木马（浏览器中的木马）攻击 340
第11章 文件上传功能防护 345
策略11-1：检测文件大小 345
策略11-2：检测是否上传了大量文件 347
策略11-3：检测文件附件是否有恶意程序 348
第12章 限制访问速率及程序交互流程 352
策略12-1：检测高速的应用访问速率 352
策略12-2：检测请求响应延迟攻击 361
策略12-3：识别异常的请求间隔时间 367
策略12-4：识别异常的请求流程 368
策略12-5：识别显著增加的资源使用 369
第三部分 战略反攻
第13章 被动的响应动作 375
策略13-1：追踪异常权值 375
策略13-2：陷阱与追踪审计日志 380
策略13-3：发送E-mail告警 381
策略13-4：使用请求头部标记来共享数据 389
第14章 主动的响应动作 394
策略14-1：跳转到错误页面 394
策略14-2：断开连接 398
策略14-3：阻断客户端的源地址 399
策略14-4：通过变更防护条件（DefCon）级别来限制地理位置访问 404
策略14-5：强制请求延迟 406
策略14-6：假装被成功攻破 412
策略14-7：把流量重定向到蜜罐 418
策略14-8：强制退出网站 420
策略14-9：临时限制账户访问 425
第15章 侵入式响应动作 428
策略15-1：JavaScript cookie测试 428
策略15-2：通过验证码测试来确认用户 430
策略15-3：通过BeEF来hook恶意用户 433
|
| 內容試閱：
|
第一部分 Part 1
准 备 战 场
第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应用是安全的。
看到这最后的回答，你就会明白为什么前面的回答都是不完整的。即使你知道你的网站哪里有漏洞，你也必须模拟攻击来确认你的安全防御是有效的。安全人员发现了这些攻击吗？是否正确地实施了安全响应策略？他们花了多长时间来实施？实施是否有效？只有回答了这些问题，你才能真正地知道你的防御策略是否有效。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
