本文目录一览：
白帽子讲Web安全的目录
《白帽子讲web安全》第一篇 世界观安全第1章 我的安全世界观 21.1 web安全简史 21.1.1 中国黑客简史 21.1.2 黑客技术的发展历程 31.1.3 web安全的兴起 51.2 黑帽子，白帽子 61.3 返璞归真，揭秘安全的本质 71.4 破除迷信，没有银弹 91.5 安全三要素 101.6 如何实施安全评估 111.6.1 资产等级划分 121.6.2 威胁分析 131.6.3 风险分析 141.6.4 设计安全方案 151.7 白帽子兵法 161.7.1 secure by default原则 161.7.2 纵深防御原则 181.7.3 数据与代码分离原则 19.1.7.4 不可预测性原则 211.8 小结 22（附）谁来为漏洞买单？ 23第二篇 客户端脚本安全第2章 浏览器安全 262.1 同源策略 262.2 浏览器沙箱 302.3 恶意网址拦截 332.4 高速发展的浏览器安全 362.5 小结 39第3章 跨站脚本攻击（xss） 403.1 xss简介 403.2 xss攻击进阶 433.2.1 初探xss payload 433.2.2 强大的xss payload 463.2.3 xss 攻击平台 623.2.4 终极武器：xss worm 643.2.5 调试javascript 733.2.6 xss构造技巧 763.2.7 变废为宝：mission impossible 823.2.8 容易被忽视的角落：flash xss 853.2.9 真的高枕无忧吗：javascript开发框架 873.3 xss的防御 893.3.1 四两拨千斤：httponly 893.3.2 输入检查 933.3.3 输出检查 953.3.4 正确地防御xss 993.3.5 处理富文本 1023.3.6 防御dom based xss 1033.3.7 换个角度看xss的风险 1073.4 小结 107第4章 跨站点请求伪造（csrf） 1094.1 csrf简介 1094.2 csrf进阶 1114.2.1 浏览器的cookie策略 1114.2.2 p3p头的副作用 1134.2.3 get? post? 1164.2.4 flash csrf 1184.2.5 csrf worm 1194.3 csrf的防御 1204.3.1 验证码 1204.3.2 referer check 1204.3.3 anti csrf token 1214.4 小结 124第5章 点击劫持（clickjacking） 1255.1 什么是点击劫持 1255.2 flash点击劫持 1275.3 图片覆盖攻击 1295.4 拖拽劫持与数据窃取 1315.5 clickjacking 3.0：触屏劫持 1345.6 防御clickjacking 1365.6.1 frame busting 1365.6.2 x-frame-options 1375.7 小结 138第6章 html 5 安全 1396.1 html 5新标签 1396.1.1 新标签的xss 1396.1.2 iframe的sandbox 1406.1.3 link types: noreferrer 1416.1.4 canvas的妙用 1416.2 其他安全问题 1446.2.1 cross-origin resource sharing 1446.2.2 postmessage——跨窗口传递消息 1466.2.3 web storage 1476.3 小结 150第三篇 服务器端应用安全第7章 注入攻击 1527.1 sql注入 1527.1.1 盲注（blind injection） 1537.1.2 timing attack 1557.2 数据库攻击技巧 1577.2.1 常见的攻击技巧 1577.2.2 命令执行 1587.2.3 攻击存储过程 1647.2.4 编码问题 1657.2.5 sql column truncation 1677.3 正确地防御sql注入 1707.3.1 使用预编译语句 1717.3.2 使用存储过程 1727.3.3 检查数据类型 1727.3.4 使用安全函数 1727.4 其他注入攻击 1737.4.1 xml注入 1737.4.2 代码注入 1747.4.3 crlf注入 1767.5 小结 179第8章 文件上传漏洞 1808.1 文件上传漏洞概述 1808.1.1 从fckeditor文件上传漏洞谈起 1818.1.2 绕过文件上传检查功能 1828.2 功能还是漏洞 1838.2.1 apache文件解析问题 1848.2.2 iis文件解析问题 1858.2.3 php cgi路径解析问题 1878.2.4 利用上传文件钓鱼 1898.3 设计安全的文件上传功能 1908.4 小结 191第9章 认证与会话管理 1929.1 who am i? 1929.2 密码的那些事儿 1939.3 多因素认证 1959.4 session与认证 1969.5 session fixation攻击 1989.6 session保持攻击 1999.7 单点登录（sso） 2019.8 小结 203第10章 访问控制 20510.1 what can i do? 20510.2 垂直权限管理 20810.3 水平权限管理 21110.4 oauth简介 21310.5 小结 219第11章 加密算法与随机数 22011.1 概述 22011.2 stream cipher attack 22211.2.1 reused key attack 22211.2.2 bit-flipping attack 22811.2.3 弱随机iv问题 23011.3 wep破解 23211.4 ecb模式的缺陷 23611.5 padding oracle attack 23911.6 密钥管理 25111.7 伪随机数问题 25311.7.1 弱伪随机数的麻烦 25311.7.2 时间真的随机吗 25611.7.3 破解伪随机数算法的种子 25711.7.4 使用安全的随机数 26511.8 小结 265（附）understanding md5 length extension attack 267第12章 web框架安全 28012.1 mvc框架安全 28012.2 模板引擎与xss防御 28212.3 web框架与csrf防御 28512.4 http headers管理 28712.5 数据持久层与sql注入 28812.6 还能想到什么 28912.7 web框架自身安全 28912.7.1 struts 2命令执行漏洞 29012.7.2 struts 2的问题补丁 29112.7.3 spring mvc命令执行漏洞 29212.7.4 django命令执行漏洞 29312.8 小结 294第13章 应用层拒绝服务攻击 29513.1 ddos简介 29513.2 应用层ddos 29713.2.1 cc攻击 29713.2.2 限制请求频率 29813.2.3 道高一尺，魔高一丈 30013.3 验证码的那些事儿 30113.4 防御应用层ddos 30413.5 资源耗尽攻击 30613.5.1 slowloris攻击 30613.5.2 http post dos 30913.5.3 server limit dos 31013.6 一个正则引发的血案：redos 31113.7 小结 315第14章 php安全 31714.1 文件包含漏洞 31714.1.1 本地文件包含 31914.1.2 远程文件包含 32314.1.3 本地文件包含的利用技巧 32314.2 变量覆盖漏洞 33114.2.1 全局变量覆盖 33114.2.2 extract()变量覆盖 33414.2.3 遍历初始化变量 33414.2.4 import_request_variables变量覆盖 33514.2.5 parse_str()变量覆盖 33514.3 代码执行漏洞 33614.3.1 “危险函数”执行代码 33614.3.2 “文件写入”执行代码 34314.3.3 其他执行代码方式 34414.4 定制安全的php环境 34814.5 小结 352第15章 web server配置安全 35315.1 apache安全 35315.2 nginx安全 35415.3 jboss远程命令执行 35615.4 tomcat远程命令执行 36015.5 http parameter pollution 36315.6 小结 364第四篇 互联网公司安全运营第16章 互联网业务安全 36616.1 产品需要什么样的安全 36616.1.1 互联网产品对安全的需求 36716.1.2 什么是好的安全方案 36816.2 业务逻辑安全 37016.2.1 永远改不掉的密码 37016.2.2 谁是大赢家 37116.2.3 瞒天过海 37216.2.4 关于密码取回流程 37316.3 账户是如何被盗的 37416.3.1 账户被盗的途径 37416.3.2 分析账户被盗的原因 37616.4 互联网的垃圾 37716.4.1 垃圾的危害 37716.4.2 垃圾处理 37916.5 关于网络钓鱼 38016.5.1 钓鱼网站简介 38116.5.2 邮件钓鱼 38316.5.3 钓鱼网站的防控 38516.5.4 网购流程钓鱼 38816.6 用户隐私保护 39316.6.1 互联网的用户隐私挑战 39316.6.2 如何保护用户隐私 39416.6.3 do-not-track 39616.7 小结 397（附）麻烦的终结者 398第17章 安全开发流程（sdl） 40217.1 sdl简介 40217.2 敏捷sdl 40617.3 sdl实战经验 40717.4 需求分析与设计阶段 40917.5 开发阶段 41517.5.1 提供安全的函数 41517.5.2 代码安全审计工具 41717.6 测试阶段 41817.7 小结 420第18章 安全运营 42218.1 把安全运营起来 42218.2 漏洞修补流程 42318.3 安全监控 42418.4 入侵检测 42518.5 紧急响应流程 42818.6 小结 430（附）谈谈互联网企业安全的发展方向 431· · · · · ·
发现XSS漏洞的一般做法有哪些？
关于发现时间，要具体到是检测什么目标了。找google的，和找腾讯的时间肯定不会一样。 至于“你们一般都是如何发现xss漏洞的？” 不同类型的XSS漏洞，可能不尽相同。
1.对于反射型XSS以及一些DOM XSS，一般建议是开发一些自动化的扫描工具进行扫描，并辅以手工分析。 另外一方面，搜索引擎也是快速寻找具有缺陷参数的好办法。
2.对于存储型XSS，
1) 对于单纯的输入-存储-输出点 的情况 （输入与输出点关系：一个地方输入，会有多个地方输出；不同地方输入，同一地方输出。绕了点 T T ...）。常规测试是正向直接输入内容，然后在输出点查看是否未过滤，当然你也可以先大胆假设输出点未过滤，反向寻找在何处进行输入，进而测试。
2）对于富文本，则需要对过滤器进行fuzz测试（人脑+自动化）了，正好乌云drops上有乌乌发了一篇：fuzzing XSS filter
3）第三类，就是一些WEB应用中所出现的DOM-存储型XSS，即输出点的无害内容，会经过js的一些dom操作变得危险（本质上和 第1点里的dom xss成因是一样的）。这一类的挖掘方法，个人觉得不太好总结。 其一，需要熟悉WEB应用的功能，其二，知道功能所对应的JS代码有哪些，其三，凭直觉猜测程序员会在哪些功能出现可能导致XSS的过滤遗忘或过滤错误（直觉是唬人的，其实就是你知道某些功能会需要某些代码实现，而这些代码常常容易出错），其四，需要有较好的代码阅读跟踪能力（JS一大坨。。还是蛮难读的.... 有些代码被混淆过，十分不易阅读，就会涉及到如何下断点进行调试的小技巧）。 我想，挖掘这一类的前提可能是需要有不错的前端开发经验，写多了，才会有足够的嗅觉。
其实吧，有时候专门去找漏洞会很累的，大什么怡情，小什么伤身，因此，我们还不如开心的敲敲代码，听听歌，静待生命中那些意外的收获。 这些收获经常来自身边的人发给你的一些事物。
最后，不论如何，基础很重要吧，内力不足，招式再多也没用，反之，草木竹石皆可为剑。
什么是xss攻击?
一、什么是跨站脚本攻击
跨站脚本攻击（Cross Site Scripting）缩写为CSS，但这会与层叠样式表（Cascading Style Sheets，CSS）的缩写混淆。通常将跨站脚本攻击缩写为XSS。
跨站脚本攻击（XSS），是最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中，当正常用户访问该页面时，则可导致嵌入的恶意脚本代码的执行，从而达到恶意攻击用户的目的。
二、跨站脚本攻击的种类
从攻击代码的工作方式可以分为三个类型：
1、持久型跨站：最直接的危害类型，跨站代码存储在服务器（数据库）。
2、非持久型跨站：反射型跨站脚本漏洞，最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。
3、DOM跨站（DOM XSS）：DOM（document object model文档对象模型），客户端脚本处理逻辑导致的安全问题。
三、跨站脚本攻击的手段和目的
常用的XSS攻击手段和目的有：
1、盗用cookie，获取敏感信息。
2、利用植入Flash，通过crossdomain权限设置进一步获取更高权限；或者利用Java等得到类似的操作。
3、利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作。
4、利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。
5、在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果。
四、跨站脚本攻击的防御
XSS攻击主要是由程序漏洞造成的，要完全防止XSS安全漏洞主要依靠程序员较高的编程能力和安全意识，当然安全的软件开发流程及其他一些编程安全原则也可以大大减少XSS安全漏洞的发生。这些防范XSS漏洞原则包括：
1、不信任用户提交的任何内容，对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、REFER、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。尽量采用POST而非GET提交表单；对“”，“”，“；”，“””等字符做过滤；任何内容输出到页面之前都必须加以en-code，避免不小心把htmltag显示出来。
2、实现Session 标记（session tokens）、CAPTCHA（验证码）系统或者HTTP引用头检查，以防功能被第三方网站所执行，对于用户提交信息的中的img等link，检查是否有重定向回本站、不是真的图片等可疑操作。
3、cookie 防盗。避免直接在cookie中泄露用户隐私，例如email、密码，等等；通过使cookie和系统IP绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值，很难拿来直接进行重放攻击。
4、确认接收的内容被妥善地规范化，仅包含最小的、安全的Tag（没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和JavaScript），使用HTTPonly的cookie。
几种极其隐蔽的XSS注入的防护
XSS注入的本质
就是: 某网页中根据用户的输入, 不期待地生成了可执行的js代码, 并且js得到了浏览器的执行. 意思是说, 发给浏览器的字符串中, 包含了一段非法的js代码, 而这段代码跟用户的输入有关.
常见的XSS注入防护, 可以通过简单的 htmlspecialchars(转义HTML特殊字符), strip_tags(清除HTML标签) 来解决, 但是, 还有一些隐蔽的XSS注入不能通过这两个方法来解决, 而且, 有时业务需要不允许清除HTML标签和特殊字符. 下面列举几种隐蔽的XSS注入方法:
IE6/7 UTF7 XSS 漏洞攻击
隐蔽指数: 5
伤害指数: 5
这个漏洞非常隐蔽, 因为它让出现漏洞的网页看起来只有英文字母(ASCII字符), 并没有非法字符, htmlspecialchars 和 strip_tags 函数对这种攻击没有作用. 不过, 这个攻击只对 IE6/IE7 起作用, 从 IE8 起微软已经修复了. 你可以把下面这段代码保存到一个文本文件中(前面不要有空格和换行), 然后用 IE6 打开试试(没有恶意代码, 只是一个演示):
+/v8 +ADw-script+AD4-alert(document.location)+ADw-/script+AD4-
最容易中招的就是 JSONP 的应用了, 解决方法是把非字母和数字下划线的字符全部过滤掉. 还有一种方法是在网页开始输出空格或者换行, 这样, UTF7-XSS 就不能起作用了.
因为只对非常老版本的 IE6/IE7 造成伤害, 对 Firefox/Chrome 没有伤害, 所以伤害指数只能给 4 颗星.
参考资料:UTF7-XSS不正确地拼接 JavaScript/JSON 代码段
隐蔽指数: 5
伤害指数: 5
Web 前端程序员经常在 PHP 代码或者某些模板语言中, 动态地生成一些 JavaScript 代码片段, 例如最常见的:
var a = '?php echo htmlspecialchars($name); ?';
不想, $name 是通过用户输入的, 当用户输入a’; alert(1); 时, 就形成了非法的JavaScript 代码, 也就是XSS 注入了.
只需要把上面的代码改成:
var a = ?php echo json_encode($name); ?;
去掉单引号, 利用 PHP 的 json_encode() 函数来生成表示字符串的字符串. 这样做是因为,
最好用 json_encode() 函数来生成所有的 JSON 串, 而不要试图自己去拼接
. 程序员总是犯这样的错误: 自己去解析 HTTP 报文, 而不是用现成的成熟的库来解析. 用 json_encode() 的好处还在于, 即使业务要求我要保留单引号时, XSS注入也可以避免.
隐蔽指数最高级, 伤害所有的通用浏览器
. 这种 XSS 注入方式具有非常重要的参考意义.
最后, 根据工作中的经验, 以及我自己和别人犯过的错, 我总结出一个定理: 没有一劳永逸的单一方法可以解决所有 XSS 注入问题.
有用的经验:输出 HTML 代码时 htmlspecialchars输出JavaScript 代码时 json_encode
输入过滤应该用于解决业务限制, 而不是用于解决 XSS 注入(与严进宽出的原则相悖, 所以本条值得讨论)讨论:上文提到的经验第3条, 是一种宽进严出的原则, 和严进宽出原则是相悖的. 其实, 我认为不应该把严进宽出作为一条伪真理, 好像除了它其它的说法都不对了似的. 宽进严出和严进宽出应该具有完全相等的地位, 根据实现的成本进行取舍.
例如, 用户的名字可以采用严进宽出原则, 不允许用户填写单引号, 大于号小于号等. 但是用户的签名呢? 难道就不能填单引号?
