本文转载自微信公众号「虞大胆的叽叽喳喳」，作者虞大胆 。转载本文请联系虞大胆的叽叽喳喳公众号。
今天回忆下web开发安全问题，以前在新浪博客时，遇到最多的攻击是XSS和SQL注入攻击。
博客最核心的功能就是富文本发文，允许执行html语义标签，如果处理不当，就能执行js语句，导致各种的xss攻击。
那时候解析文章内容没有很好的dom解析库，堵住漏洞非常辛苦和被动。
另外攻击就是sql注入，破坏过一些表数据，但大范围的故障没有出现过。
这二个攻击在互联网刚开始的时候非常流行，最重要的原因就是它们的宿主环境是浏览器，浏览器能够执行html和js。SQL攻击同样如此，如果宿主环境不能打印sql执行结果，攻击力度会小很多。
而现在是APP时代，都是接口调用，即使接口中含有html字符，APP也不会去执行;同时API接口的鉴权也非常严格，很少出现SQL注入攻击。
当然HTTPS的推广和普及也让http服务安全提高了不少，至少很难出现残暴的篡改攻击了。
所以现在攻击的土壤就是企业内部网站了，因为它们大多数运行在浏览器之下，那如何解决呢?
从Web安全的角度看，cookie和session的设计本身就是有问题的，以前写过一篇文章，后面可以发到公众号中。
xss攻击本质上也是结合cookie一起形成危害的，今天同事提了个方法，现在很多cookie不会校验它的出处，如果能够绑定cookie和设备(比如设备号或者IP)，那么攻击就小了很多，比如发现攻击者附带的cookie值和IP与存储在redis中的cookie和IP不一致，就拒绝访问。
对于内部系统，可以采取二次auth验证，比如nginx就有http basic auth验证;或者登陆才能访问内部系统。
攻击分为主动攻击和被动攻击，主动攻击不可怕，总能找到方法解决，而被动攻击就非常危险，在关键时刻可以给人致命一击。
在出现安全问题的时候，首先要判断服务器有没有被人控制，如果被控制了，危险非常大;如果仅仅是利用应用程序漏洞，那么危险性就会小很多。
服务器一旦被攻击，那么数据库密码等关键信息就会泄露，数据库就相当于裸奔了，就算数据库隔离的好，还是抵挡不住别人一条DELETE语句;为了减少损失，有两个建议。
第一就是数据库用户授权要做的更精细一点;另外使用proxy代理数据库，通过proxy来抵挡一些攻击。
应用层的攻击主要利用软件的漏洞，或者考验编程人员的能力。所以经常升级系统和软件，使用相对成熟的代码框架，严谨编程，能够减少很多问题，大概90%的安全问题还是由于代码的原因。
当然口令安全也非常重要，有很多理论知识，但只要掌握几点就能解决大部分问题，口令一定要是强口令，避免暴力破解;另外就是口令存储要使用更严格的密码学算法，不要简单的sha1然后存储到数据库中，很容易字典攻击;最后在应用层的防攻击也很重要，不过现在很少直接口令登陆了，都是验证码或者微信授权。
当然很重要的一个习惯就是经常性变更口令，能够解决很多问题，其实有的时候出现一个安全问题，最后才发现，口令泄露了，根本不是技术问题。
对于服务器本身安全，就是尽量少装软件;少开外网端口(比如mongodb，es一定不要绑定外网端口)，即使开了，也要做白名单;使用防火墙做更细颗粒度的控制;服务之间做隔离，比如web服务器被攻击了，但web服务器访问的数据库密码由更安全的硬件存储，这样危险性就少了很多。
有的时候大家很注意外部安全，但内网之间的隔离也非常重要，不能畅通无阻。
隔离还有个好处就是出现问题后，可以快速在其他机房复制服务，从而减少故障的影响。授权也很重要，服务之间的授权方式一定要在云端，不能依赖本地。
当然核心安全还是数据库资源，数据是一切之本。
最后没有绝对的安全，都是博弈，如果网站规模不大，可能没人愿意黑你。而如果规模化了，那么就树大招风了。提前做好准备，以便应对，不至于出现问题的时候手足无措。
