WEB安全【五】：互联网企业的安全运营

    这几天一直在拜读大牛吴翰清的《白帽子讲WEB安全》，一口气读下来，对于WEB安全的大体框架有了了解，了解到了客户端以浏览器为代表的XSS，CSRF等攻击形式，了解到了服务端的SQL注入，DDOS以及PHP漏洞等威胁，最后的一个部分谈到了作为互联网企业的安全问题。自己读到最后最大的感触有两点：一个是“安全”的本质，其实在经典著作《计算机安全学：艺术与科学》中也提到了这个概念，当然当时提的是计算机系统的安全，讲述的是可信计算的相关问题，包括可信内核与可信域的划分等等，“安全”的实现总是以某种“信任”作为前提的，一旦这种“信任假设”被打破，之前的安全策略也就形同虚设了；另一个印象颇深的是“安全运营”，这个观念彻底断绝了所有妄图“一劳永逸做安全”的幻想，安全是与威胁相适应的，威胁不断在变化，因此安全也是一个动态的过程，需要不断根据威胁的特点进行变化。虽然也了解到了一些形形色色的攻击技术，但是最为深刻的还是这亮点体会。下面自己来梳理下第二点：安全运营。

一、互联网的业务安全
   对于一个项目而言，到底“安全”有着怎样的地位呢？一个项目的基本是可用性，这里可以包括其功能的实现以及良好的用户体验和卓越的性能，按照吴大牛的观点，一个产品功能越完善，用户群越多，竞争对手越多，比拼的越是其安全性。此时安全模块的引入必须确保三点：产品功能完善、良好的用户体验、卓越的性能。我们做科研，一般不太关注用户体验和性能，因为我们的用户群体一般不是广大普通用户，而都是专业人员。当然，这也应当是以后我们努力改进的方向。下面分几个方面分别介绍下互联网产品的业务安全：业务逻辑安全、帐户防盗、互联网垃圾、网络钓鱼以及用户隐私保护。
-1. 业务逻辑安全
   业务逻辑安全，直白地讲就是在业务流程逻辑上是否有疏漏可以给攻击者以可乘之机，用来破坏机密性、完整性或可用性。类比一下，就像网络协议分析，大家都知道“中间人攻击”吧，认证和加密的算法应该都是没有问题的，但是使用认证和加密的方式是有问题的，直接导致了存在攻击者在正常用户Alice和Bob之间互相欺骗，作为中间人获取双方的通信秘密。这是一种典型的协议漏洞，放到业务逻辑上就是下面的案例：某购物网站为了应对密码暴力破解，制定了五次登陆失败后帐户被锁定一小时的策略；同时该网站有竞拍业务，报价高的用户会自动替代报价低的用户。
   聪明的你能看出其中的Bug么？没错！问题就出在五次登陆失败后的帐户锁定上，一旦某个帐户被锁定，其参与竞拍的报价也就同时失效。黑客可以先报一个较低的价格，然后利用报价高于自己的用户名五次登陆失败，造成对方帐户锁定竞拍失效，从而自己可以以极低的价格拍得商品，Bingo！改进的方式可以是显示竞拍者的用户ID的匿名或部分信息，使得黑客无法恶意尝试登陆。
   上面的是一个真实的案例，其实像这样的例子还有很多，比如找回密码的单因子或多因子认证问题，单因子的风险肯定高于多因子，但是用户体验要好于后者。像此类的业务逻辑需要设计者和安全工程师仔细地分析论证。
-2. 帐户防盗
   可能很多人都有过帐户被盗的经历，这的确是个很头疼的问题。我们的帐户要么是和资产绑定在一起（手机？网银？），要么是和我们的社交群绑定在一起（IM？）那么一般我们的账号被盗有哪些可能的原因呢？
*1. 网站登陆过程无HTTPS，密码在网络中被嗅探；
*2. 用户电脑中了木马，密码被键盘记录器截获；
*3. 用户被钓鱼网站所迷惑，密码被钓鱼网站所骗取；
*4. 网站某登陆入口可以被暴力破解；
*5. 网站密码取回流程存在逻辑漏洞；
*6. 网站存在XSS等客户端脚本漏洞，用户帐户被间接窃取；
*7. 网站存在SQL注入等服务器漏洞，被拖库了；
   以上几条，除了2-3之外与用户有关，其余均应由网站承担大部分责任。这也就意味着要求互联网企业在维护自身网站时要更加注重安全性，良好的用户体验是网站生存发展的关键。问题发生之后，一是要通过客服或工程师同用户交流，获取全面真实的第一手信息，以此来判断问题可能发生的原因；二是查看分析日志，找到帐户被盗的方式；三是可以登陆黑客群体论坛，从内部打探消息。
-3. 互联网垃圾
   这里的“网络垃圾”涉及两个方面：垃圾注册和垃圾邮件。垃圾邮件大家一定相当熟悉了，比如邮箱中经常能收到广告邮件或者反动宣传邮件，这主要依靠邮件运营商的垃圾邮件过滤机制，必须某种算法，从邮件头、邮件内容上进行过滤，或者使用安全厂商提供的专业垃圾邮件数据库进行筛选，这里不再详述。
   垃圾注册指的则是恶意注册许多账号，但是却并未使用网络提供的正常服务。举个简单的例子，比如投放垃圾广告，自然没有人会傻到用自己的真实帐户来发，自然是注册的批量虚假帐户发布广告或者反动宣传；再一个例子，最近滴滴打车取消了对于乘客的补贴，但是却推出了向朋友分享红包，只是乘客自身无法领取，因此可以注册多个账号，自己打车分享给A，下次用A打车后再分享给B，如此往复，花的一样是滴滴的钱，只是，这样要麻烦许多。
   处理垃圾信息的方式比较简单，禁止通信、封绝账号、添加验证码等，但是关键问题是如何识别这些垃圾账号，这里给出了实践中的经验：
*1. 基于内容的规则：以自然语言分析、关键词匹配为代表；
*2. 基于行为的规则：以业务逻辑规则为代表；
*3. 基于客户端识别的规则：以人机识别为代表，比如验证码，或者让客户端去解析Javascript；
   拦截的时候也有要注意的问题，就是要“隐藏”你的拦截规则，比如打一个时间差，识别出垃圾帐户后，隔一段时间再处理，这样恶意用户就不容易猜到触犯了哪条规则；比如“打压”大部分帐户，放过一小批帐户等等，毕竟，拦截规则都是“见光死”。
-4. 网络钓鱼
   这里涉及的主要问题是攻击者伪造了目标网站，通过此网站套取用户的帐户密码信息。防范的要点是，对于用户而言，要提高警惕，重要甄别域名上的微小差别；对于网站一方，则要同安全厂商合作，获得恶意网站list，进行过滤筛选，同时针对钓鱼网站的特点，建立一套自身的过滤规则，比如钓鱼网站经常使用0与o之间的替换，混淆字母l与数字1等等。
-5. 用户隐私保护
   隐私问题已经成为互联网中越来越重要的问题，我们在使用互联网服务时，“被迫”留下了许多个人的信息，比如QQ、MP、ADDRESS等，这些作为隐私应该是受到严密保护的。然而可惜的是，现实中用户的这些信息并没有得到有效的保护。比如某些网站的管理人员可以看到用户的注册信息，手机号、身份证号等等，这需要建立严格的隐私保护机制，比如：
*1. 确保用户知情权和选择权：网站有义务告知用户获取了什么数据，并公布自己的隐私策略或条款；
*2. 网站应妥善保管收集到的用户数据，不得将数据用于任何指定范围以外的用途；

二、安全运营
   上面简答介绍了安全运营中的业务方面的安全问题，这部分来介绍如何安全运营我们的网站。Aberdeen Group提出了一个观点，安全运营强调三句话：
-1. Secure at the Source;
-2. Find and Fix;
-3. Defend and Defer;
   其实这是一个从下至上的安全运营体系，“安全”的要求贯穿在项目设计开发到上线运行的全过程，并且将伴同项目的生存期一起存在。
   首先，Secure at the Source落实到实际中，推荐SDL，这是微软提出的安全开发编程的框架和标准，由于微软本身的SDL较为厚重，实际中多数使用“敏捷SDL”，总结起来就是一下几条经验：
*1. 与项目经历充分沟通，排除足够的时间（明确安全工程师的介入时机和工作时间）；
*2. 规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏；
*3. 树立安全部门的权威，项目必须由安全部门审核完成后才能发布；
*4. 将技术方案写入开发、测试的工作手册中；
*5. 给工程师培训安全方案；
*6 记录所有的安全bug，激励程序员编写安全的代码；
   在SDL的基础上写出的代码可以最大可能地减少漏洞和bug，但是仍旧不能避免，因为程序员是人，不是神。接下里就需要Find and Fix了，其实就是漏洞修补。这里建议建立一个漏洞管理平台，比如像bugtracker，定义bug类型，同时给出紧急程度来决定其优先级。具体来说就是：
@1. 建立类似bugtracker的漏洞跟踪机制，并为漏洞的紧急程度选择优先级；
@2. 建立漏洞分析机制，并与程序员一起制定修补方案，同时review补丁的代码实现；
@3. 对曾经出现的漏洞进行归档，并定期统计漏洞修补情况；
   Defend and Defer指的是项目上线之后的安全监控、入侵检测与紧急事件响应，这里可以使用开源的或安全厂商的工具进行部署实施，值得一提的是当攻击发生时，首先要保护好安全事件的现场，便于后续安全分析；其次以最快的速度处理问题，流程能省则省，紧急响应小组的成员，一定是最了解公司业务架构的人。