公司最近来了个SR（security architecture），推荐我们看下入门级的web安全。再加上最近刚培训了安全编码，一切也算是机缘巧合吧。不过这本书讲解的确实通俗易懂，安利给大家。
关于这本书的作者，那也是相当传奇。他在阿里面试的时候当着面试官，把阿里网络宕了...高手出手，一招致命。结果呢，阿里当场录用，并更换了网络供应商。
白帽子和黑客都是网络高手一类的头衔。黑客这个在生活中都有所耳闻，而白帽子则低调了很多，白帽子讲究的是安全防范领域的专家。黑客讲究的是搞破坏，找到一个漏洞，就能肆无忌惮的窃取“好处”，白帽子则是修复这些漏洞，不仅要fix已知的，还要防范未知的。以前国内还有网站专门科普类似网络技术，比如“红黑联盟”，“看雪学院”等，现如今可能是利益的驱使，单纯的传授经验知识的已经很少。所以这本书对于普及知识，防范漏洞还是很有帮助的。
安全三要素：机密性，完整性，可用性
机密要求保护数据内容不被泄漏，通常做法加密。
完整性要求保护数据内容的完整，没有被篡改。做法数字签名。
可用性要求保护的资源“随需而得”。
白帽子兵法：secure by default原则，纵深防御原则，数据与代码分离原则，不可预测原则
secure by default原则讲的是不要随意的更改系统的设置，比如我们经常在server开各种端口来提供服务。像ftp默认是22端口，但是有时候由于某种原因改成5222，这种。类似的中间件默认提供服务的是8080，然后为了可以提供多种服务，开了其他端口等。这种都绕开了默认的安全设置。容易被黑客攻击。
纵深防御原则好理解，设置多层关卡，每关检测不同的安全漏洞。
数据与代码分离原则适用于各种注入而引发的安全问题的场景，XSS，SQL 注入，X-path注入等。
不可预测性与上面不同，讲究的是从攻击方法的角度看问题。它的实现往往需要用到加密算法，随机数算法，哈希算法。
客户端脚本安全
1.浏览器的同源策略：限制来自不同源的document或脚本，对当前document读取或设置某些属性。
2.sandbox：chrome采用的是多进程架构的浏览器。主要进程分为：浏览器进程/渲染进程/插件进程/扩展进程。插件进程如：flash/java/pdf等与浏览器进程隔离，因此不会相互影响。多进程架构有个好处：相当于单进程，在发生崩溃时，多进程浏览器只会崩溃当前的tab页，而单进程浏览器会崩溃整个浏览器进程。
3.恶意网址拦截。攻击者会在网页上插入<script>或者<iframe>等标签加载一个恶意网址，实行“挂马”，为了免于攻击，浏览器会将这些恶意网址进行拦截。做法也很简单就是设置黑名单，只是这个黑名单要定期进行更新。
跨站脚本攻击（XSS）
英文：cross site script，本来缩写是CSS，为了跟样式表区分，改成XSS。黑客通过“HTML注入”篡改网页，插入恶意的脚本，从而在用户浏览网页的时候，控制用户浏览器的一种攻击。
1.反射性XSS，简单把用户输入的数据反射给浏览器。黑客往往需要诱使用户点击一个恶意链接，才能攻击成功。
2.存储性XSS，会把用户输入的数据存储在服务器端。这种具有很强的稳定性。
3.DOM based XSS，效果来看也是反射性XSS，单独划分的原因是形成原因比较特别，通过修改页面的dom。
常见的XSS，就是通过读取浏览器的Cookie对象，从而发起“Cookie劫持”攻击。通过插入一段看不见的img，把document.cookie作为参数传回服务器端。XSS 还可以通过模拟GET和POST请求，进行攻击。window对象是浏览器的窗体，不是document对象，因此window对象不受同源策略的限制。攻击者可以利用这个对象实现跨域/跨页面传递数据。
XSS的防御
1.HttpOnly，可以解决XSS劫持cookie攻击。可以选择性的加载设置cookie。
2.输入检查。规避特殊标签符号。
3.输出检查。在变量输出到页面时，编码或转义。HtmlEncode，URLEncode等函数。针对富文本集可以使用白名单，允许用户提交仅限的字符标签。
4.针对dom based XSS，要特别小心，首先需要javascriptEncode，然后输出页面的时候也需要不同语境的encode函数（htmlEncode...）。
5.业务规避。可以在需要的地方减少用户的交互行为。分析哪些页面受攻击的可能性大。
跨站点请求伪造CSRF
全名：cross site request forgery。攻击者诱使用户访问一个页面，酒可以以该用户的身份在第三方站点里执行一次操作。攻击者能够成功的原因是因为浏览器成功的发送了cookie。浏览器所持有的cookie分为两种：一种是“session cookie“，也称临时cookie。还有一种是Third-party cookie，也称为本地cookie。区别在于本地cookie是服务器在set-cookie时指定了expire的时间，保存在本地。session cookie没有指定expire，他是保存在浏览器进程的内存空间里。浏览器关闭，它也就失效了。目前firefox是可以跨域发送认证的third-party session。 这样就易导致了CSRF。
P3P头的副作用，也易导致CSRF。它是W3C制定的关于隐私的标准。如果网站返回的给浏览器的HTTP头中包含P3P头，则在某种程度上来说将允许浏览器发送第三方Cookie。它的业务主要用在广告等跨域的页面上。
CSRF防御
1.验证码被认为是防御CSRF最简洁有效的方法。CSRF攻击的过程往往是在用户不知情的情况下构造了网络请求，而验证码则强制用户必须与应用进行交互，才能最终完成请求。但是也有缺陷，不能给网站上每个操作都加上验证码，它是一种辅助手段。
2.referer check：防止图片盗链。用于检查是否来自合法的源。常见的互联网应用，页面与页面之间具有一定的逻辑关系。他的缺陷在于服务器并非什么时候都能取到referer。某些情况下，浏览器不会发送referer，比如从https到http。
3.Token。CSRF的本质是重要操作的所有参数都是可以被攻击者猜测到的。基于这可以把参数加密，或者使用随机数，让攻击者无法猜测到参数值。比如一个删除操作：
http://host/path/delete?username=abc&item=123，把其中的username参数改成哈希值：
http://host/path/delete?username=md5(salt+abc)&item=123。这样攻击者就不好构造出这个URL，也就无法发起CSRF攻击了。但是这样也有个不好的地方，首先url一直在变，用户想保留是不可能的，然后数据分析对用户也不少很友好。那么引出的方法就是加个token（http://host/path/delete?username=abc&item=123&token=13243fstertetdf）。token需要随机，必须使用足够安全的随机数生成算法。token是服务器与用户之间的“秘密”，不能被第三方知晓。在实际应用中，可以放在session和cookie里。那么当用户发送请求时只需要验证服务器端的token和用户cookie或session种的token是否一致就行。不一致或者为空，则认为CSRF。
Token使用原则
a.足够随机，使用安全的随机数生成器生成token。
b.token目的不是为了防止重复提交，为了使用方便，允许在一个用户的有效生命周期内，在token 消耗前都使用同一个token。
c.如果token保存在cookie，不在服务器端的session中。会存在以下问题：当打开多个页面时，有的页面token过期了，但是其他页面还保存着消耗掉的token。当提交页面时，会报token错误。针对这种情况，可以一次性生成多个有效的token。
d.注意token的保密性。如果出现在某个URL中，可能会被referer的方式暴露。因此在使用token的时候，尽量把它放在表单中。敏感操作由GET改为POST。
CSRF中token 仅仅用于对抗CSRF攻击，当网站还存在XSS漏洞时，这个方案会变得无效。因为XSS会模拟客户端浏览器执行任意操作。在XSS攻击下，攻击者完全可以请求页面后，把token读出来。XSS带来的问题应该用XSS防御方案解决。
点击劫持（ClickJacking）
它是一种视觉上的欺骗手段。攻击者使用一个透明的/不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，常见的就是网站图片，用户点击图片就有可能被链接到钓鱼网站上。它与CSRF有相同的地方在于都是诱使用户完成一些操作。不同的是它利用的就是与用户交互的页面。下图表示的通过一个简单的拖拽动作，窃取了用户邮箱里的邮件数据。用户拖拽的其实是选中了隐藏在iframe的数据，放在小球时把数据也放在隐藏的textarea中，从而完成了一次数据窃取过程。
这种攻击方法手机上比较多，通过劫持用户点击数据，或者伪装链接，从而钓鱼和欺诈。
防御点击劫持
1.一般是禁止跨域的iframe。写段js来防止iframe嵌套。常见的方法：
if(top.location != location){top.location = self.location;}
2.HTTP头：X-Frame-Options，有三个可选值：DENY/SAMEORIGIN/ALLOW-FROM。deny禁止iframe加载。SAMEORIGIN允许同源的iframe加载；ALLOW-FROM则是不做限制。
服务器端应用安全
注入攻击：本质是把用户输入的数据当作代码执行。两个关键条件：1.用户能够控制输入。2.原本程序要执行的代码，拼接了用户的数据。
sql注入：基本上都是由于写原生sql，拼接字符导致。通过在字符后面加上and 1=1，或者and 1=2来得到数据库回显的消息，从而进一步判断是否存在注入漏洞。这种是基于数据库开启了回显功能，如果没有呢？有人就研究出了“盲注”技巧。“盲注”就是在服务器没有错误回显信息完成的注入攻击。常见的方法就是构造简单的条件语句，根据页面是否变化，来判断SQL是佛得到执行。这部分书中还讲到一个MYSQL的“盲注”。在MYSQL中有个BENCHMARK（）函数，它是用于测试函数性能的。那么就可以利用这个函数执行的时间长短来判断注入语句是否成功。（union select if(substring(current,1,1)=char(119),BENCHMARK(50000,ENCODE( 'MSG','by 5 seconds')),null) from (select Database() as current ) as tb1）。除了上述的攻击方法，还有用户自定义的函数，以及存储过程，字符集都是易受攻击的点。还有我们在生活中经常遇到了插入数据的column太长的问题，这是数据库设置了strict模式，如果sql-mode设置了STRICT-TRANS-TABLES，一旦插入数据过长，则会显示error，并且插入不成功。但是如果没有设置，则仅会显示warning，并且会插入成功。那么问题来了，插入的数据会被截断。设想，如果我建一个用户名，前几位和真正的用户名，一致，那么数据库中是不是就存在两条一样的用户数据，那么我在检索出来，就可以得到的真正用户。书中有例子，感兴趣的可以前往研读，挺有意思的。
防御SQL注入
找到所有SQL注入漏洞，并修复。
1.采用预编译语句，绑定变量。
2.采用安全的存储过程，并使用严格的输入过滤或者编码函数来处理用户的数据。
3.检查数据类型。
4.使用安全函数。
5.使用最小权限原则，避免直接使用root，dbowner等高权限操作数据库。
除了SQL注入外，还有XML注入，代码注入，\r\n等，需要注意的就是在拼接部分要特别关注下。
文件上传漏洞
文件上传漏洞指用户上传了可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。有些检查时通过文件的后缀来判断文件是否安全，但是这种也是能够被攻击者利用。稳重提到的在文件名后添加一个%00字节，这种可以截断某些函数对文件名的判断。在许多语言中0x00被认为是终止符。IIS服务中有个历史漏洞是上传的jpg文件中，构造的文件名为http://www.virtual.com/xx.asp;xy.jpg。由于；是截断符，会导致前面地址被执行。同时IIS中的PUT功能也需要关注下，可能被利用修改HTTP头，一定要正确的设置该功能。
设计安全的文件上传功能
1.文件上传的目录设置为不可执行。
2.判断文件类型，使用白名单。
3.用随机数修改文件名和路径。
4.单独设置文件服务器的域名。
认证会话管理
认证的目的是为了认出用户是谁，授权的目的是为了决定用户能够做出什么。
权限设置管理：应用角色绑定来设置的权限管理，高角色可以访问低角色的功能，低角色不能反过来访问--垂直权限管理。还有水平权限管理，比如同一个角色用户，针对同一个页面都可以看自己的数据，但是url被rewrite后，是不是会带来访问其他用户隐秘数据呢。这种目前的解决办法是用户组的概念，还可以考虑规则引擎。
OAuth
OAuth 是一个不提供用户的用户名和密码的情况下，授权第三方应用访问web资源的安全协议。下图是新浪微博开放平台的OAuth的授权过程。
密码和随机数部分讲了很多破解的算法，总结下来就是密码要足够复杂，然后尽量保证不设置重复密码。
web框架安全
MVC框架，需要在正确的层做正确的事，比如对于注入攻击，如果在View进行修复，攻击者可以通过其他方式如函数等绕过校验，效果会适得其反。正确的应该在Model层进行处理。
在View层可以解决XSS问题，可以使用不同的编码函数，一些模版引擎会默认使用htmlEncode函数，但是这样也是不安全的，可以被攻击者绕过，所以针对不同问题，要设置不同的编码函数。
针对CSRF，可以使用seurity token。
数据持久层应对SQL注入。可以做到统一管理和把控。目前市面上的主流框架都会存在某些漏洞，我们不能完全的信任他们，有时仍然需要实现自己的安全方案。
DDOS攻击
一种是网络层的DDOS攻击，通过大量的流量（僵尸网络）导致提供服务的服务器拒绝服务。
还有一种是应用层的DDOS攻击，通过正常的用户访问，只是数据量很大，会导致服务处理速度变慢，甚至宕机。比如把一个大流量的网站引导到攻击的目标机器上，或者使用sql的查询功能，翻页查询，如果表很大的话，也会导致查询缓慢。应对方法就是：获取设备号和IP地址，如果该设备持续不断的发请求，就拒绝访问。但是还是有瑕疵的，IP地址可以伪造。所以好的做法就是应用代码要做好性能优化，还有网络架构做好优化，还可以限制每个IP地址的请求频率。
书的后半部分还讲解了PHP的安全使用，以及web server容器相关的安全隐患（tomcat和jboss默认端口8080，需要特别注意他的授权访问，以及nginx/Apache的配置）最后部分谈到了企业如何设计安全，定位产品安全...
总的来说，这本开了不少安全方面的眼界，以前写代码可能会觉得这个部分会被攻击，但是并不清楚攻击者是如何攻击的，通过此书受益匪浅。正好上午收到了公司印度同事发的邮件，说获得了安全编码的证书，还是值得开心的事情。
