白帽子讲Web安全读书笔记

• Part1：安全的发展，或者说，黑客的发展
  

  • 黑客是什么？

  1. 互联网本来是安全的，自从有了研究安全的人之后，互联网就变得不安全了。
  2. “root”对黑客的吸引，就像大米对老鼠，美女对色狼的吸引。不想拿到“root”的黑客，不是好黑客。
  3. 在黑客的世界里，有的黑客，精通计算机技术，能够自己挖掘漏洞，并编写“exploit”（黑客们使用的漏洞利用代码叫做exploit）；而有的黑客，只是对攻击本身感兴趣，对计算机原理和各种编程技术的了解比较粗浅，因此只懂得编译别人的代码，自己并没有动手能力，这种黑客被称为“Script Kids”（脚本小子）。在现实世界中，真正造成破坏的，往往并非那些挖掘并研究漏洞的“黑客们”，而是这些脚本小子。

  • 黑客简史

  1. 中国黑客发展分为三个阶段：启蒙时代、黄金时代、黑暗时代
  2. 启蒙时代
  3. ：20世纪90年代，也正是中国互联网刚刚起步阶段，热爱新兴技术的青年收到国外黑客技术影响，开始研究安全漏洞。启蒙时代的黑客大多由于个人爱好走上这条路，好奇心和求知欲是他们前进的动力，没有任何利益瓜葛。这个时期的中国黑客们通过互联网，看到了世界，因此与西方发达国家同期诞生的黑客精神是一脉相传的，他们崇尚分享、自由、免费的互联网精神，并热衷于分钟自己的最新研究成果。
  4. 黄金时代
  5. ：以2001年中美黑客大战为标志（感兴趣的同学可以百度一下“中美黑客大战”，相信大家都记得2001年中国飞行员王伟为了捍卫国家主权，被美国侦察机撞毁事件，起因正是这件事，这次事件中，中国黑客空前团结，与美国黑客开展了一场激烈的黑客大战，非常轰动，也这是世界第一次黑客大战），这次事件大大推动了中国黑客的发展，崛起了一批黑客、红客联盟，也让黑客这个特殊群体一下吸引了社会的眼球，黑客圈子所宣扬的黑客文化和黑客技术的独特魅力也吸引了无数的青少年走上黑客这条道路。这次事件之后，各种黑客组织如雨后春笋般冒出，他们普遍的特点是：年轻、有活力、充满激情，但技术上也许还不够成熟。此时，黑客圈子里贩卖漏洞、恶意软件的现象开始升温，因为黑客群体良莠不齐，开始出现以赢利为目的的攻击行为，黑色产业链逐渐成型。
  6. 黑暗时代
  7. ：这个时代大概从几年前开始一直持续到现在（PS. 是哪一年呢？个人觉得大概是07年底左右开始吧），也许还将继续下去。这个时期的黑客组织也遵循社会发展规律，优胜劣汰，大多数黑客组织没有坚持下去，20世纪非常流行的黑客技术论坛也越来越没有人气，最终走向没落。所有门户型的漏洞披露站点，再也不公布任何漏洞相关技术细节。随着安全产业发展，黑客的功利性越来越强，黑色产业链开始成熟。在20世纪技术还不太成熟的黑客们，凡是坚持下来的，都已经成为安全领域的高级人才，要么，在安全公司贡献自己的专业技能，要么带着非常强的技术进入黑色产业。此时期的黑客群体因为互相之间缺失信任，已经不再具有开放和分享的精神，最纯粹的黑客精神实质上已经死亡。整个互联网笼罩在黑色产业链的阴影之下，每年数十亿经济损失和数千万网民受害，黑客精神的死亡，让我们没有理由不把这个时代称为黑暗时代。也许，黑客精神所代表的Open、Free、Share，真的一去不复返了！

  • 黑客技术的发展历程 

  1. 早期，黑客攻击目标以系统软件居多。一方面，由于这个时期的Web 技术发展还远远不成熟；另一方面，则是因为通过攻击系统软件，黑客们往往能够直接获取root 权限。早期互联网中，Web 并非互联网的主流应用，相对来说，基于 SMTP 、POP3、FTP 等协议的服务拥有着绝大多数的用户。因此黑客们主要的攻击目标是网络、操作系统以及软件等领域，Web 安全领域的攻击与防御技术均处于非常原始的阶段。相对于那些攻击系统软件的exploit 而言，基于Web 的攻击，一般只能让黑客获得一个较低权限的账户，对黑客的吸引力远远不如直接攻击系统软件。
  2. 防火墙技术兴起改变的安全格局，WEB逐渐成为黑客的焦点：随着时代发展，防火墙技术的兴起改变了互联网安全的格局。尤其是以Cisco、华为等为代表的网络设备厂商，开始在网络产品中更加重视网络安全，最终改变了互联网安全的走向。防火墙、ACL技术的兴起，控制只允许信任来源的访问，使得直接暴露在互联网上的系统得到了保护。2003年的冲击波蠕虫是一个里程碑式事件，这个针对Windows 操作系统RPC 服务（运行在445 端口）的蠕虫，在很短的时间内席卷了全球，造成了数百万台机器被感染，损失难以估量。在此次事件后，运营商们很坚决地的骨干网络上屏蔽了135 、445 等端口，此次事件后，整个互联网对于安全的重视达到了一个空前的高度。运营商、防火墙对于网络的封锁，使得暴露在互联网上的非Web 服务越来越少，且Web技术的成熟使得Web 应用的功能越来越强大，最终成为了互联网的主流。黑客们的目光，也渐渐转移到了Web 这块大蛋糕上。 
  3. Web安全的兴起：Web 攻击技术发展的几个阶段：①Web 1.0时代，人们更多的是关注服务器端动态脚本的安全问题，比如将一个可执行脚本（俗称webshell）上传到服务器上，从而获得权限。动态脚本语言的普及，以及 Web 技术发展初期对安全问题认知的不足导致很多“血案”的发生，同时也遗留下很多历史问题，比如PHP 语言至今仍然只能靠较好的代码规范来保证没有文件包含漏洞，而无法从语言本身杜绝此类安全问题的发生。②SQL注入的出现是Web 安全史上的一个里程碑。SQL注入最早出现在 1999年，并很快就成为Web 安全的头号大敌。通过SQL 注入攻击，可以获取很多重要的、敏感的数据，甚至能够通过数据库获取系统访问权限，这种效果并不比直接攻击系统软件差，Web 攻击一下子就流行起来。（SQL 注入漏洞至今仍然是Web 安全领域中的一个重要组成部分。）③XSS （跨站脚本攻击）的出现则是 Web 安全史上的另一个里程碑。实际上，XSS 的出现时间和SQL 注入差不多，但是真正引起人们重视则是在大概  2003年以后。在著名的是2005年的MySpace的XSS 蠕虫事件后，安全界对 XSS 的重视程度提高了很多。④随着Web 2.0 的兴起，XSS 、CSRF（跨站请求伪造） 等攻击已经变得更为强大。Web 攻击的思路也从服务器端转向了客户端，转向了浏览器和用户。黑客们天马行空的思路，覆盖了Web 的每一个环节，变得更加的多样化。⑤互联网的蓬勃发展，也催生出许多新兴的脚本语言，比如Python 、Ruby、NodeJS等，敏捷开发成为互联网的主旋律。而手机技术、移动互联网的兴起，也给HTML 5 带来了新的机遇和挑战。Web安全技术，也紧跟着互联网发展脚步，不断地演化出新的变化。（以上名词：SQL注入、XSS跨站、CSRF跨站伪请求伪造等，不明白意思没关系，先熟悉个名词吧，知道它们是WEB应用安全的重要敌人就行，后面慢慢讲解他们具体是什么，有什么危害，怎么防范）

  4. PS：以上SQL注入、XSS跨站、CSRF跨站伪请求伪造等名词，不明白意思没关系，先熟悉他们的名字吧，知道它们是WEB应用安全的重要敌人就行，后面慢慢讲解他们具体是什么，有什么危害，怎么防范。

  • 白帽子、黑帽子

  
  

  你知道吗，“黑客”是有好坏之分的！

  
  

  白帽子、黑帽子，他们是谁：在黑客的世界中，往往用帽子的颜色来比喻黑客的好坏。白帽子，是指那些精通安全技术，工作在反黑客领域的专家们；而黑帽子，是指利用黑客技术造成破坏，甚至进行网络犯罪的群体。 

  
  

  白帽子和黑帽子工作的心态完全不同：正是因为白帽子和黑帽子的目标不同，所以他们在工作时的心态是完全不同的。对于黑帽子来说，只要能够找到系统的一个弱点，就可以达到入侵系统的目的；而对于白帽子来说，必须找到系统的所有弱点，不能有遗漏，才能保证系统不会出现问题。

  
  

  白帽子要求全面宏观、黑帽子思考问题是有选择性的、微观的：白帽子一般为企业或安全公司服务，工作的出发点就是要解决所有的安全问题，因此所看所想必然要求更加的全面、宏观；黑帽子的主要目的是要入侵系统，找到对他们有价值的数据，因此黑帽子只需要以点突破，找到对他们最有用的一点，以此渗透，因此思考问题的出发点必然是有选择性的、微观的。

  
  

  从对待问题的角度来看，黑帽子是不断组合问题，白帽子是不断分解问题：黑帽子为了完成一次入侵，需要利用各种不同漏洞的组合来达到目的，是在不断地组合问题；而白帽子在设计解决方案时，如果只看到各种问题组合后产生的效果，就会把事情变复杂，难以细致入微地解决根本问题，所以白帽子必然是在不断地分解问题，再对分解后的问题逐个予以解决。这种定位的不对称，也导致了白帽子的安全工作比较难做。“破坏永远比建设容易”，白帽子选择的方法，是克服某种攻击方法，而并非抵御单次的攻击。

  
  

  安全问题往往发生在一些意想不到的地方：上述一切都是理想状态，在现实世界中，存在着各种各样不可回避的问题。工程师们很喜欢一句话：“No Patch For Stupid！”，在安全领域也普遍认为：“最大的漏洞就是人！”。写得再好的程序，在有人参与的情况下，就可能会出现各种各样不可预知的情况，比如管理员的密码有可能泄露，程序员有可能关掉了安全的配置参数，等等。安全问题往往发生在一些意想不到的地方。

  
  

  防御技术在不断完善的同时，攻击技术也在不断地发展。这就像一场军备竞赛，看谁跑在前面。

  
  

  • 返璞归真，安全问题的本质是信任的问题 

  
  

  安全是什么？什么样的情况下会产生安全问题？我们要如何看待安全问题？只有搞明白了这些最基本的问题，才能明白一切防御技术的出发点，才能明白为什么我们要这样做，要那样做。 

  
  

  让我们想想，安全问题是怎么产生的：一个安全问题是如何产生的呢？我们不妨先从现实世界入手。火车站、机场里，在乘客们开始正式旅程之前，都有一个必要的程序：安全检查。机场的安全检查，会扫描乘客的行李箱，检查乘客身上是否携带了打火机、可燃液体等危险物品。抽象地说，这种安全检查，就是过滤掉有害的、危险的东西。因为在飞行的过程中，飞机远离地面，如果发生危险，将会直接危害到乘客们的生命安全。因此，飞机是一个高度敏感和重要的区域，任何有危害的物品都不应该进入这一区域。为达到这一目标，登机前的安全检查就是一个非常有必要的步骤。

  
  

  安全问题的本质是信任的问题：从安全的角度来看，我们将不同重要程度的区域划分出来， 通过一个安全检查（过滤、净化）的过程，可以梳理未知的人或物，使其变得可信任。被划分出来的具有不同信任级别的区域，我们称为信任域，划分两个不同信任域之间的边界，我们称为信任边界。 

  
  

  

   

  
  

  数据从高等级的信任域流向低等级的信任域，是不需要经过安全检查的；数据从低等级的信任域流向高等级的信任域，则需要经过信任边界的安全检查。 就像我们在机场通过安检后，想要从候机厅出来，是不需要做检查的；但是想要再回到候机厅，则需要再做一次安全检查，就是这个道理。

  
  

  所以，安全问题的本质是信任的问题。一切的安全方案设计的基础，都是建立在信任关系上的。我们必须相信一些东西，必须有一些最基本的假设，安全方案才能得以建立；如果我们否定一切，安全方案就会如无源之水，无根之木，无法设计，也无法完成。

  
  

  把握住信任条件的度，是安全的艺术魅力：在现实生活中，我们很少设想最极端的前提条件，因为极端的条件往往意味者小概率以及高成本，因此在成本有限的情况下，我们往往会根据成本来设计安全方案，并将一些可能性较大的条件作为决策的主要依据。

  
  

  从另一个角度来说，一旦我们作为决策依据的条件被打破、被绕过，那么就会导致安全假设的前提条件不再可靠，变成一个伪命题。因此，把握住信任条件的度，使其恰到好处，正是设计安全方案的难点所在，也是安全这门学问的艺术魅力所在。

  
  

  安全的世界里，没有一劳永逸的银弹：在解决安全问题的过程中，不可能一劳永逸，也就是说“没有银弹”。任何人想要一劳永逸地解决安全问题，都属于一相情愿，是“自己骗自己”，是不现实的。

  
  

  安全是一个持续的过程。 自从互联网有了安全问题以来，攻击和防御技术就在不断碰撞和对抗的过程中得到发展。从微观上来说，在某一时期可能某一方占了上风；但是从宏观上来看，某一时期的攻击或防御技术，都不可能永远有效，永远用下去。这是因为防御技术在发展的同时，攻击技术也在不断发展，两者是互相促进的辩证关系。以不变的防御手段对抗不断发展的攻击技术，就犯了刻舟求剑的错误。在安全的领域中，没有银弹。 

  
  

  微软的例子：微软在发布Vista时，曾信誓旦旦地保证这是有史以来最安全的操作系统。我们看到了微软的努力，在Vista下的安全问题确实比它的前辈们（Windows XP、Windows 2000、Windows 2003等）少了许多，尤其是高危的漏洞。但即便如此，在2008年的Pwn2own竞赛上，Vista也被黑客们攻击成功。P wn2own竞赛是每年举行的让黑客们任意攻击操作系统的一次盛会，一般黑客们都会提前准备好0day 漏洞的攻击程序，以求在Pwn2own上一举夺魁。（来大致了解一下0day漏洞：0Day的概念最早用于软件和游戏破解，属于非盈利性和非商业化的组织行为，其基本内涵是“即时性”，所以0Day漏洞指那些已经被发现的（包括有可能未被公开的），而官方还没有出相关补丁的漏洞。由于暂时没有解决的补丁，0Day漏洞可以说是一种“不治之症”，危险程度极高。所以软件公司非常关注涉及自身的0Day漏洞，甚至会高额“悬赏”发现者，以期在这些漏洞被公众于众之前或者之初，尽快知晓并开发出补丁）

  Part 3 安全三要素

  
  

  安全三要素，理解安全问题的组成属性，是正确全面认识安全问题的前提

  
  

  在设计安全方案之前，要正确、全面地看待安全问题。要正确全面的认识一个安全问题，首先要理解安全问题的组成属性。前人通过无数实践，最后将安全的属性总结为安全三要素，简称CIA。安全三要素是安全的基本组成元素，分别是机密性（Confidentiality）、完整性（Integrity ）、可用性（Availability ）。

  
  

  机密性要求保护数据内容不能泄露，加密是实现机密性要求的常见手段。

  
  

  完整性要求保护数据内容是完整、没有被篡改。常见的保证一致性的技术手段是数字签名。（什么是数字签名？数字签名，就是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串是对信息的发送者发送信息真实性的有效明。举个例子：传说清朝康熙皇帝的遗诏，写的是“传位十四子”，被当时还是四阿哥的胤禛篡改了遗诏，变成了“传位于四子”。姑且不论传说的真实性，在故事中，对这份遗诏的保护显然没有达到完整性要求。如果在当时有数字签名等技术，遗诏就很难被篡改。从这个故事中也可以看出数据的完整性、一致性的重要意义。 ）

  
  

  可用性要求保护资源是随需而得、随时可用。（举例：假设一个停车场里有100 个车位，在正常情况下，可以停 100 辆车。但是在某一天，有个坏人搬了100 块大石头，把每个车位都占用了，停车场无法再提供正常服务。在安全领域中这种攻击叫做拒绝服务攻击，简称DoS （Denial of Service），拒绝服务攻击破坏的就是安全的可用性）

  
  

  在安全领域中，最基本的要素就是这三个，后来还有人想扩充这些要素，增加了诸如可审计性、不可抵赖性等，但最最重要的还是以上三个要素。在设计安全方案时，也要以这三个要素为基本的出发点，去全面地思考所面对的问题。

  
  
  

  Part4-安全评估过程

  
  

  一个安全评估的过程，可以分为4个阶段：资产等级划分、威胁分析、风险分析、制定解决方案。

  
  

  这里需要插播一下：什么是威胁，什么是风险？这两个概念经常会被人混淆，弄清他们对于了解安全评估每阶段做的事情很重要。威胁，是指可能造成危害的来源，英文叫Threat，风险，是指可能会出现的损失，英文叫Risk。这里要明确一件事：虽然危害可能导致损失，但是危害≠损失。所以威胁分析，是要找到可能造成危害的来源，风险分析，就是在找到这些来源的基础上，分析他们可能造成的损失。

  
  

  第一个阶段：资产等级划分

  这项工作是所有安全评估工作的基础，这阶段的任务是：明确评估目标。应该可以再加一个：明确安全边界。

  根据资产的重要性，划分资产等级。在互联网中，安全的核心问题，可能是数据的安全问题。所以做资产等级划分时，很重要的一个参考依据就是：按照数据的重要性确定与数据相关联的资产的重要性。怎么确定各类数据的重要性呢？主要通过访谈形式，当然，如果企业自己已经对数据做出了等级划分，就更好了。

  
  

  划分完资产等级后，就开始划分安全域和安全边界，建立一个安全模型。后面的评估，就要围绕着安全边界的内部和外部来开展。

  
  

  第二个阶段：威胁分析

  Part 2 讲到过，白帽子和黑帽子对待安全问题的区别：白帽子是宏观的，他要找到所有弱点，不能有遗漏；而黑帽子就简单的多，他是微观的，只要突破一点就可以攻陷系统。白帽子防护系统比黑帽子入侵系统要难得多。所以，白帽子做安全评估，需要对系统的安全威胁做全面的分析，尽可能的找到所有安全弱点。

  虽然想找到所有安全弱点很难，但是也不是盲目乱找，有一些科学的威胁建模方法可以帮助我们较为全面的查找威胁。这里介绍较通用的STRIDE模型，最早由微软提出。

  STRIDE是6个单词的首字母缩写，我们在分析威胁时，可以从以下6个方面去考虑。

  

   

  在进行威胁分析时，要尽可能地不遗漏威胁，头脑风暴的过程可以帮助确定攻击面。 威胁分析模型也不是一成不变的，相反，它需要经常更新。

  
  

  第三个阶段：风险分析

  并非每个威胁都会造成难以承受的损失，一个威胁到底能够造成多大的危害，如何去衡量它？这就要考虑到风险了。我们判断风险高低的过程，就是风险分析的过程。

  风险由两个因素组成：发生的可能性、破坏性（Risk = Probability * Damage Potential）

  如何更科学地衡量风险，也相应模型可以帮助我们做判断，这里介绍DREAD模型，它也是由微软提出的。

  

   

  在DREAD模型里，每一个因素都可以分为高、中、低三个等级。在上表中，高、中、低三个等级分别以3、2、1的分数代表其权重值，因此，我们可以具体计算出某一个威胁的风险值。

  
  

  介绍完威胁建模和风险分析的模型后，我们对安全评估的整体过程应该有了一个大致的了解。在任何时候都应该记住：模型是死的，人是活的，再好的模型也是需要人来使用的，在确定攻击面，以及判断风险高低时，都需要有一定的经验，这也是安全工程师的价值所在。类似STRIDE和DREAD的模型可能还有很多，不同的标准会对应不同的模型，只要我们觉得这些模型是科学的，能够帮到我们，就可以使用。但模型只能起到一个辅助的作用，最终做出决策的还是人。

  
  

  第四个阶段：制定安全解决方案

  安全评估的产出物，就是安全解决方案。

  很多人认为，安全和业务是冲突的，因为往往为了安全，要牺牲业务的一些易用性或者性能，事实上并非如此。从产品的角度来说，安全也应该是产品的一种属性，一个从未考虑过安全的产品，是不完整的。（比如：我们要评价一个杯子是否好用，除了它能装水，能装多少水外，还要思考这个杯子内壁的材料是否会溶解在水里，是否会有毒，在高温时会不会熔化，在低温时是否易碎，这些问题都直接影响用户使用杯子的安全性。）

  
  

  对于互联网来说，安全是要为产品的发展与成长保驾护航的。我们不能使用“粗暴”的安全方案去阻碍产品的正常发展，所以应该形成这样一种观点：没有不安全的业务，只有不安全的实现方式。作为安全工程师，要想的就是如何通过简单而有效的方案，解决遇到的安全问题。安全方案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。好的安全方案对用户应该是透明的，尽可能地不要改变用户的使用习惯。

  
  

  一个优秀的安全方案应该具备以下特点：能够有效解决问题、用户体验好、高性能、低耦合、易于扩展与升级。

  
  

  
  

  
  

  第7页

  "No Patch for stupid"即“最大的漏洞就是人”，所以安全问题是一直存在的，
  安全的本质是信任问题，数据来源不可信，这是安全的一个原则
  安全是一个持续的过程，不断的升级与改善
  互联网安全的核心问题，是数据安全的问题。
  安全的3要素：CIA
  机密性（Confidentiality）：要求数据内容不能被泄露，常见实现技术为加密。
  完整性（Integrity）：要求数据内容是完整的，没有被篡改，常见实现技术为数字签名。
  可用性（Availability）：要求保护资源是“随需而得”，例如DOS（Denial of Service）攻击，是常见的破坏可用性的方法
  扩展：可审计性、不可抵赖性
  安全的评估：
  1、资产等级划分：
  2、威胁分析：
  Threat：可能造成危害的来源；Risk：可能会出现的损失。这两个概念要分清。
  微软提出的STRIDE模型：
  3、风险分析：Risk = Possibility * Damage Potential
  微软提出的DREAD模型：
  当然，所有的这些模型都是辅助作用，模型可能会有更新，根据不同的产品模型也有不同，做决策的是人。
  4、设计安全方案：
  安全和业务并不冲突，安全也应该是产品的一种属性，一个从未考虑过安全的产品，是不完整的
  一些原则：
  1、Secure by default 原则：也可以归纳为白名单、黑名单的思想，最小权限原则。
  2、纵深防御原则（Defense in depth）：
  a、不同层面，不同方面实施安全方案
  b、在正确的地方做正确的事，比如说XSS，只需要在输出的时候进行处理即可
  3、数据库与代码分离原则
  4、不可预测性（Unpredictable）：比如说id的生成，自增长就很容易被预测，往往需要用到加密、随机数算法、哈希算法，常见的常见为预防CSRF的时候采用token

  2012-04-29 17:32:40 回应

• 第34页

  浏览器安全：
  同源策略(Same Origin Policy)：Web是构建在同源策略的基础上的，同源策略现在离来自不同源的“document”或者脚本，对当前“document”的读写权限。
  <script><img><iframe><link>标签都是可以跨域家在资源，不受同源策略的限制。这些带‘src’属性的标签每次加载的时候，实际上是由浏览器发送了一次GET请求。不同于XMLHttpRequest的是，通过src属性加载的资源，浏览器限制了Javascript的权限，使其不能读、写返回的内容。但是XMLHttpRequest受到同源策略的约束，不能跨域访问资源。但是W3C制定了XMLHttpRequest跨域访问标准.
  浏览器沙箱：
  Sandbox，资源隔离类模块，其目的是让不可信的代码运行在一定的环境里，限制不可信的代码访问隔离区之外的资源；如果一定需要跨越sandbox便捷进行交互，则通过安全的API来完成。Chrome和IE都采用了Sandbox技术。
  恶意网址拦截：http://www.phishtank.com/ 免费提供恶意网址黑名单的组织
  IE、Chrome等主流浏览器识别恶意网站主要是通过黑名单功能，使用EV SSL证书（Extended Validation SSL Certificate）也可以有效的识别钓鱼网站，该证书在地址栏上会以已绿色显示
  例如https://www.alipay.com/
  浏览器对于安全方面的努力
  IE8退出了XSS Filter功能，当用户访问的URL中包含了XSS攻击脚本时，IE就会修改其中的关键字符使得攻击无法完成，并对用户弹出提示
  浏览器插件的开发，带来了新的安全隐患，同时也带来了新的挑战。

  第34页
  跨站脚本攻击(XSS) Cross Site Script, to clarified from CSS, it's named XSS
  XSS Payload：
  1、构造get, post请求：
      <img>的src属性
      构建form表单
      使用XMLHttpRequest
  2、XSS钓鱼：使用xss模仿出一个一模一样的登陆框，将用户输入直接提交至hacker的server，这个可以去处理验证码的问题
  3、识别用户浏览器：
      可以通过alert(navigator.userAgent)，但是userAgent可以伪造，可以采用其他代码来实现，见page 55
  4、识别用户安装的软件：
      查找插件：navigator.plugins
  5、CSS history hack：通过css发现用户曾经访问过的网站http://ha.ckers.org/weird/CSS-history-hack.html 可以访问到你曾经访问过的哪些历史记录，FF已经在2010.3决定修补这个问题，但是该问题依然在chrome上存在
  6、获取用户的真实IP：需要借助第三三方软件来完成
  XSS 攻击平台：其目的为演示XSS的为好，以及方便渗透测试使用，没事可以去玩
  Attack API: http://code.google.com/p/attackapi/BeFF: http://bindshell.net/tools/beef.htmlXSS-Proxy：通过嵌套iframe的方式，实时的远程控制被XSS攻击的浏览器
  XSS Worm：蠕虫一般多发于存储型XSS，并且交互行为多的页面。
  1、Samy Worm：http://namb.la/popular/tech.html (留着以后看)
  2、百度空间蠕虫：http://security.ctocio.com.cn/securitycomment/57/7792057.shtml (留着以后看)
  调试
  1、Firebug on FF；Inspect element on Chrome；Developer tools on IE 8
  2、Fiddler：www.fiddler2.com/fiddler2/3、Http Watch：商业软件，目标网站是https会特别有用
  2012-04-30 18:27:44 回应
  第76页
  XSS构造技巧
  1、字符编码：需要熟悉Unicode
  2、绕过长度限制：
      利用location.hash, location.hash则可以用来获取或设置页面的标签值。比如http://ued.alimama.com#admin的location.hash=”#admin”,利用这个属性值可以实现很多效果。 refer to http://www.jz123.cn/text/0718524.html
      利用注释附绕过长度限制：
  3、使用<base>标签
  <base>可以出现在页面的任何地方，并作用于该标签在之后的所有标签；<base>标签只用于<head>标签之内，这个说法是不对的
   mark
  4、window.name的妙用
  对当前窗口的window.name对象赋值，没有特殊字符的限制，因为window对象是浏览器的窗体，而并非document对象，因此很多时候window对象不收同源策略的限制，攻击者可以利用这个对象，实现跨域、跨页面传递数据。
    steps
      1. 在目标窗口，给window.name赋值，此处可以附上cookie等敏感数据
      2. 当前窗口跳转至另一个url,可以通过window.name获取到参数，因为window对象是当前窗口
  5、以往的一些XSS
    Apache Expect Header XSS, Anetha：利用反射xss和存储xss协作攻击
    Flash XSS : allowScriptAccess, allowNetworking 参数的配置很重要
      refer tohttps://www.owasp.org/index.php/Category:SWFIntruderhttps://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project
  JS框架的安全问题：
  Dojo 1.4.1, YUI也遭遇过Dojo相同的问题
  2012-04-30 19:39:31 回应
  第89页
  XSS的防御
  1、HttpOnly
  httpOnly标签至今已经逐渐成为一个标准，浏览器禁止JS访问带有HttpOnly的Cookie，HttpOnly可以选择性的加载任何一个Cookie值上
  Java EEresponse.setHeader("Set-Cookie","cookiename=value; Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");
  C#HttpCookie cookie = new HttpCookie("myCookie");cookie.HttpOnly = true;Response.AppendCookie(cookie);
  PHP 4header("Set-Cookie: hidden=value; httpOnly");PHP 5setcookie("cookiename","value",NULL,NULL,NULL,NULL,TRUE)
  2、输入检查
  如果遇到富文本的输入，实现起来比较困难，因为过滤之前需要考虑到语境
  3、输出检查
    a.安全的编码函数：
  输出对象为html时，采用HtmlEncode，HtmlEncode不是专用名词，他只是一种函数实现。他的作用是将字符转换成HTMLEntities，对应的标准是ISO-8859-1
  至少需要转换以下字符：
  & --> &amp;
  < -->&lt;
  > --> &gt;
  " --> &quot;
  ' --> &#x27;
  / --> &#x2F;
  JS编码方式可以使用JavascriptEncode, 
  refer to https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
  采用框架并不一定能够全部解决问题，比如说Phthon的web2py，但需要在正确的地方使用正确的编码方式。
  正确的防御XSS
  在HTML标签中输出、在HTML属性中输出：对变量使用HtmlEncode
  在<script>标签中输出、在事件中输出：使用JavascriptEncode
  在CSS中输出：推荐使用OWASP ESAPI中的encodeCSS()方法
  String safe = ESAPI.encoder().encodeForCSS(request.getParameter("input"));
  在地址中输出：OWASP ESAPI中的encodeForURL()方法（此API并没有解决伪协议的问题），先检查变量是否以“http”开头(如果不是则自动添加)，以保证不会出现伪协议类的XSS
  String safe = ESAPI.encoder().encodeForCSS(request.getParameter("input"));
  处理富文本：采用XSS filter
  For Java: Anti-Samy refer to https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
  For PHP: http://htmlpurifier.org/
  防御DOM Based XSS：复合的XSS防御
  从$var输出到<script>的时候需要做JavascriptEncode，在输出到html的时候，如果是输出到事件或者脚本，再做一次JavascriptEncode，如果输出到html，做HtmlEncode，即，输出点即为防御点。
  cheatsheet for DOM Based XSS：http://code.google.com/p/domxsswiki/
  理论上，XSS漏洞数量很多，并且可能复杂，但是确实可以彻底解决的。
  2012-05-01 19:32:23 回应
  第109页
  CSRF( Cross Site Request Forgery)
  浏览器的cookie有两种：不同浏览器对于cookie的管理策略是不同的
    a.session cookie(临时cookie)：对于server来说是session
    b.third-party cookie(本地cookie)：对于server来说是cookie
  P3P header：W3C指定的一项关于隐私的标准：The Platform for Privacy Preferences.
  如果网站返回给浏览器的HTTP头中包含了P3P头，某种程度上说，是允许浏览器发送第三方cookie，并且对于cookie的影响将扩大到整个域中的所有页面，因为cookie是以域和path为单位的。P3P头的介入会改变网站的隐私策略，将不再拦截浏览器发送第三方cookie，并且只设置一次即可。 很多时候，如果测试CSRF时发现<iframe>等标签在IE能发送cookie，很有可能是P3P的原因（因为IE默认会拦截iframe发送cookie）
  refer to http://www.w3.org/TR/P3P/
  CSRF的防御：
    a. 验证码
    b. Referrer check：最常用的就是防止图片盗链，但该方法用来监控比较好
    c. Token：使用 Anti CSRF Token，token在用户提交表单前都有效，在提交之后失效，并且重新生成一个新的token，token可以放在用户session或者cookie里，不宜放在url上
  在防御CSRF之前，必须防止XSS，否则CSRF将无法被防御。
  2012-05-03 09:35:58 回应
  第125页
  视觉上的欺骗手段，将一个透明的、不可见的iframe覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。
  对于当前的web浏览器来说，主要用在钓鱼、欺诈和广告作弊等方便，并且实施成本高，个人认为影响并不算大
  拖拽劫持&数据窃取： page 131
  触屏劫持：TapJacking，运用于手机客户端，相当有威力，因为在手机客户端很多浏览器为了节约空间，会隐藏地址栏，并且可以不只是用在浏览器上哦，手机屏幕都是可以被劫持的对象
  防御方式：
  1. frame busting:采用js禁止使用iframe的嵌套，但是容易被绕过
  refer to http://seclab.stanford.edu/websec/framebusting/framebust.pdf
  2. X-Frame-Options:
    比较优选的方案就是使用http头：X-Frame-Options, 支持的浏览器有：IE 8+; Opera 10.50+; Safari 4+; Chrome 4.1.249.1042+ FF 3.6.9
    有3个可选值: 
      DENNY: 浏览器会拒绝当前页面加载任何frame页面
      SAMEORIGIN: frame页面的地址只能为同源域名下的页面
      ALLOW-FROM origin: 可以定义允许frame加载的页面地址
    
  2012-05-05 02:55:34 回应
  第139页
  新标签引起的XSS：如果过滤是采用黑名单过滤，那么新标签的引用有可能带来新的xss攻击，例如<video><audio>标签
  refer to http://code.google.com/p/html5security/
  <iframe>的sandbox属性：可以控制同源访问、访问顶层窗口、提交表单、执行脚本的事件
  <a>和<area>的ref属性：<a href="xxx" rel="noreferrer" /> 指定noreferrer后,浏览器在请求该标签置顶的地址时将不再发送referrer
  <canvas>：HTML的一大特性，超越了<img>，可以让JS在页面中直接操作图片对象
  refer to http://diveintohtml5.info/canvas.html通过canvas自动识别Megaupload提供的验证码: http://userscripts.org/scripts/review/38736
  Cross-Origin Resource Sharing：根据跨域访问提出的新标准，在request的header中增加Origin，即本域；可以在response中看到Access-Control-Allow-Oringin，此属性中如果含有当前发送请求的域，则发送请求的域可访问被请求域的资源
  postMessage--跨窗口传递消息
  postMessage 允许每一个window (包括当前窗口, 弹出窗口, iframe)对象往其他的窗口发送文本消息，从而实现跨窗口的消息传递。这个功能不收同源限制
  使用postMessage的时候有2个安全问题需要注意：1、在接收窗口验证domain，即做同源策略的验证；2、需要对发送的请求的信息进行安全检查，例如防止注入
  Web Storage：W3C的新标准，分为Session Storage和Local Storage，受到同源策略的约束，安全的隐患存在于将恶意代码或者敏感信息保存在Web Storage中
  js的使用方法：
  Setter: window.sessionStorage.setItem(key, value);Getter: window..sessionStorage.getItem(key);
  2012-05-05 12:27:27 回应
  第152页
  Blind Injection:
  在服务器没有返回错误会先时完成的注入攻击，手法可使用 and 1=1, and 1=2等，提交之后根据返回的结果可以判断是否有SQL injection.
  Timing Attack: 利用BENCHMARK()函数，让同一个函数执行若干次，使得结果返回的时间比平时要长；通过时间长短的变化，可以判断注入是否成功
  攻击工具：sqlmap.py refer to http://sqlmap.sourceforge.net/
  常见攻击技巧：
  盲注
  利用UDF( User defined functions) ：此攻击的用户是有很高权限的用户，可以通过UDF或者sql语句执行当前OS命令
  攻击存储过程：存储过程本生没有输入检查，很致命
  利用字符集编码攻击：这个比较麻烦，解决的方案是统一DB, OS,Web Server所使用的字符集，建议使用UTF-8，如果无法统一，则需要单独实现用于过滤或者转移的安全函数
  利用Sql column truncation攻击：
    Mysql有一个配置选项，sql_model的属性"STRICT_TRANS_TABLES"如果被设置，在插入表的时候如果有字段超长，则会自动截断并且发出warning，而不是error，这样会导致程序与数据的初衷不符合，可能会出现问题，例如db中有用户叫做admin，且column长度限制为5，攻击者申请新用户叫做admindaad980eqdads098dadan0，很容易会跳过程序的检查，并且在插入时自动截取前5个字符，admin，攻击成功
  防御：使用黑名单，很容易被跳过
  1、针对sql最佳方式就是使用预编译：
  java--> PreparedStatement()
  .NET--> SqlCommand(), OleDbCommand()
  PHP--> bindParam()
  Hibernate --> bind parameter
  SQLite--> sqlite3_prepare()
  2、避免使用procedure，如果必须需要使用，则使用安全的procedure：
  java--> 
  CallableStatement cs = connection.prepareCall("{call prc_name(?)}");cs.setString(1,"xxx");
  3、使用安全的函数
  可以参考OWASP ESAPI中的实现
  Codec orac = new OracleCodec();String query = " select 1 from t_user where username ='"+ESAPI.encoder().encodeForSQL(orac, username)+"' and password ='"+ESAPI.encoder().encodeForSQL(orac, password)+"'";
  4、从DB自身的角度来看，使用最小权限原则，不应该有操作文件或者定义函数等功能，并且应该和Web服务器分离
  附------------------------------------------------------
  Mysql中的一些函数
  --将expr执行count次的耗时，常用语性能调试的语句BENCHMARK(count, expr):select BENCHMARK(5000000, curdate());--查看数据库版本select @@version from dual;--将查出的语句写入到文件中SELECT table_name, table_type, ENGINEFROM information_schema.TABLESWHERE table_schema ='mysql'ORDER BY table_name DESC into outfile 'path';--将敏感数据读出，通过INTO DUMPFILE将该文件写入到系统中，然后通过LOAD DATA INFILE将文件导入创建的表中，通常被用于导出一个WebShell，为攻击者的进一步攻击做铺垫，因为普通的DB user一般不具备操作文件的权限create table t_testAtt(line BLOB);select load_file('sensitiveFile') INTO DUMPFILE ('targetPath');LOAD DATA INFILE 'targetPath' INTO TABLE t_testAtt;
  2012-05-05 15:11:58 回应
  第173页
  XML注入
  代码注入：多见于脚本语言，但是服务端语言也有可能被注入
  Java如果使用了脚本引擎，就可能发生注入
  import javax.script.*;// para="hello');var fImport= new JavaImporter)(java.io.File); with (fImport){ var f = new File('new'); f.createNewFile();}";public void test(String para) throws Exception{  ScritpEngineManager manager = new ScriptEngineManager();  ScriptEngine engine  manager.getEngineByName("JavaScript");  System.out.println(para);  engine.eval("print('"+para+"')");}
  CRLF注入：CR--> Carriage Return( ASCII 13, \r, 0x0d); LF--> Line Feed( ASCII 10, \n, 0x0a)
  对http头的影响比较明显，如果请求中包含了/r/n，并且该请求会被放入到cookie中，则返回的头，则会多出一个/r/n，连续2次换行意味着http头的结束，在此空间内可以执行攻击，从此处也可以发现，注入http头的印象很大。
  2012-05-05 15:51:50 回应
  第181页
  文件上传导致的危害：
  1、上传的文件是WebShell，服务器的Web容器解析并且执行了用户上传的文件，导致代码执行。完成攻击的条件：a.上传的文件能够被web容器解释执行; b.用户能够从Web上访问到这个文件; c. 上传的文件没有被格式化、安全检查、压缩等而导致改变功能。2、上传文件是类似于Flash的策略文件crossdomain.xm，黑客可以控制该域下的行为。3、上传文件是木马、病毒，黑客用来有道用户或者管理员下载的4、上传文件是钓鱼图片或者包含脚本的图片，被用于钓鱼或者欺诈
  绕过文件上传检查功能：
  攻击者手动修改了上传过程中的POST包，在文件名后添加一个%00字节，则可以阶段某些函数对文件名的判断，比如说在C、php等语言的常用字符串处理函数中，0x00被认为是终止符。例如应用原本只允许上传JPF图片，可以构造文件名（需要修改POST包）为xxx.php[\0].jpg，由于[\0]为十六进制的0x00字符，.jpg就绕过了应用上传文件类型的判断；并且对于服务器来说，此文件因为0字节阶段的关系，最终会变成xxx.php
  防御：
  1、文件服务器和Web服务器分离，并且单独设置文件服务器的域名，可以通过同源策略的关系使客户端攻击失效。
  2、文件上传的目录设置为不可执行
  3、检验文件类型，结合使用MIME type、后缀检查，黑名单靠不住，使用白名单；对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同事破换图片中可能包含的HTML代码。
  4、使用随机数改写文件名和路径
  2012-05-05 17:24:51 回应
  第192页
  Authentication & Authorization.
  认证与授权
  密码必须以不可逆的加密算法，或者是单项散列函数算法，加密后存储在DB中，一般采用的加密方式是需要加上salt
  可采用多因素认证来增加认证强度，例如支付宝中的各种认证方式
  需要预防Session劫持，这个和SessionID的管理有关，个人认为只要控制了xss，就不会出现session劫持的情况。
  SSO：最开放和流行的SSO系统是OpenID
  2012-05-06 17:12:09 回应
  第205页
  RBAC（Role-Based Access Control）：基于角色的访问控制
  基于URL的访问控制，基于方法的访问控制：Spring Security是框架实现了Filter Chain，但是缺乏一个管理界面供灵活配置，因此每次调整权限时，需要重新修改配置文件或代码，学习成本较高，维护成本也较高
  例子：http://www.wooyun.org/bugs/wooyun-2010-0788http://www.wooyun.org/bugs/wooyun-2010-01429http://www.wooyun.org/bugs/wooyun-2010-01352不要把后台管理页面藏起来，虽然搜索引擎的爬虫搜索不到这些页面，但是攻击者管用的几辆是使用一部包含了很多后台路径的字典把“藏起来”的页面扫出来。
  水平权限管理：基于数据的访问控制，这个问题很常见
  OAuth：
  从OpenID中分离出来，解决了交互的信任问题
  2012-05-06 17:56:23 回应
  第220页
  Stream Cipher Attack:
  流加密法是基于异或（XOR）操作进行的，每次都只操作一个字节，但是性能非常好，常见的加密算法有RC4, ORYX, SEAL
  WEP破解：
  现实中，最著名的针对流密码攻击可能就是WEP密钥的破解。WEP是一种常用无线加密传输协议，破击了WEP的密钥，就可以以此密钥连接无线的Access Point，WEP采用RC4算法
  page 233
  分组加密法：
  有通用的几种加密模式：ECB, CBC, CFB, OFB, CTR
  常见的分组加密算法有DES, 3-DES, Blowfish, IDEA, AES
  EBC模式（Electronic Codebook， 电码薄）
  2012-05-06 18:09:49 1人收藏 回应
  第281页
  防御XSS, 采用模板引擎可以统一控制
  1. 在HTML标签中输出变量
  2. 在HTML属性中输出变量
  3. 在Script标签中输出变量
  4. 在事件中输出变量
  5. 在CSS中输出变量
  6. 在URL中输出变量
  防御CSRF： 跟业务挂钩比较重，一般在“增、删、改”操作的时候需要防御，“读”并不需要
  1. token
  2. “增、删、改”操作时需要采用post，不能使用get
  关于Ajax的例子可见page 286
  Header管理：主要是需要对抗CRLF注入，将value编码所有的\r\n即可。
  管理好跳转的页面，采用白名单，设置HttpOnly
  2012-05-26 13:30:02 1人推荐 3人收藏 回应
  第295页
  DDOS （ Distributed Denial of Service）分布式拒绝服务
  CC攻击( Challenge Collapsar)：对资源消耗大的应用页面不断发起正常的请求，以达到小号服务器资源的目的。
  防御方案：
  1. 针对每个“客户端”做请求频率限制page 298
  2. 代码要做好性能优化
  3. 网络架构需要做优化
  Slowloris攻击：原理是以极低的速度往服务器发送http请求，使Web Server的所有连接都被恶意链接占用, page 307, 该攻击对很多Web Server都是有效的，当然很多Web Server可以通过配置参数来解决这个问题
  HTTP Post DDOS：类似于Slowloris, 在发送Http post包时，指定一个非常大的Content-Length值,然后以很低的速度发送，以保持连接不断开
  Server Limit DOS：Web Server的Http长度都是有限制的,request header与request body. 攻击者可以在利用xss在Cookie里面写入超长的信息，超过header的限制，服务器则会返回4xx错误，防御方式可以修改Server参数
  ReDOS：正则表达式DOS，是代码的缺陷，和以上攻击以略有占用资源不同，有的正则写得有缺陷的话，会导致运算时间加长，这个影响看来是挺大的
  通用的防御：
  CAPTCHA( Completely Automated Public Turing Test to Computer and Humans Apart, 全自动区分计算机和人类的图灵测试)，/**好拗口 */ 现在常用方式为验证码，但是并不是最优的solution,Yahoo( Detecting system abuse) 提出了更宽广的思路
  2012-05-26 14:03:59 回应
  第317页
  直接跳过了.以后接触到php的时候再回来读
  简单来说，因为灵活，所以导致了PHP代码安全评估的难度较高，常见漏洞有：文件包含漏洞、代码执行漏洞
  2012-05-27 09:59:05 回应
  第353页
  Apache Httpd：
  1. 检查Module的安装情况，根据“最小权限原则”，应该尽可能的减少不必要的Module，对于要使用的Module，检查起对应版本是否存在安全漏洞
  2. 需要为Apache Httpd建立单独的一个user/group，该user/group的唯一作用就是运行Apache Httpd，不能具备shell
  3. 保护好Apache log，比如实时的发送到远程的syslog服务器上
  Nginx：
  同Httpd的第2点，http://nginx.org/en/security_advisories.html 官方已经列出了安全的隐患和漏洞，需要保持Nginx升级更新
  jBoss
  默认安装时，访问JMX-Console (http://address:port/jmx-console )是没有认证的
  需要删除JMX-Console的，移除jmx-console.war和web-console.war即可
  Tomcat
  Tomcat Manager部署war包所需的manager权限应该单独配置给一个账号，不要使用默认的tomcat账号 tomcat-users.xml
  HTTP Parameter Pollution
  通过向服务器发送GET或者POST请求时，提交两个相同的参数，不同服务器的选择会有不同，可能会绕过安全检查，关于服务器的处理方式，参见page 364
  2012-05-27 10:33:44 回应
  第402页
  Secure at the Source，以最小的成本提高产品的安全性
  关于SDL，我们可以基于Microsoft或者OWASP的帮助，例如Microsoft的STRIDE模型，OWASP的SAMM( Software Assurance Maturity Model https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model)
  针对于敏捷开发，SDL有着不同的实现方式，但是有一下准则：
  1. 与Project Manager充分沟通，排出足够的时间，否则裸奔是很危险的
  2. 规范公司的立项流程，确保所有项目都能通知到安全团队
  3. 树立安全部门的权威，项目必须由安全部门审核完成后才能发布
  4. 将技术方案写入开发、测试的工作手册中
  5. 培训
  6. 记录所有的安全BUG，产生需要有report，并且能够让程序员活跃起来交流
  需求：check list: from page 410 to 414
  开发阶段
  1. 采用安全的组件 (OWASP ESAPI: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API)
  2. 指定安全的开发规范，并且将安全的开发规范写入文档中，让安全方案落地
  审计：核心思想并非直接检查代码是否安全，而是检查开发者是否遵守了开发规范
  审计工具：
  commercial: IBM Rational Appscan, WebInspect, Acunetix WVS
  free: w3af, skipfish( http://code.google.com/p/skipfish/ , 二次开发的上佳选择)
  
  

Part4-安全评估过程

一个安全评估的过程，可以分为4个阶段：资产等级划分、威胁分析、风险分析、制定解决方案。

这里需要插播一下：什么是威胁，什么是风险？这两个概念经常会被人混淆，弄清他们对于了解安全评估每阶段做的事情很重要。威胁，是指可能造成危害的来源，英文叫Threat，风险，是指可能会出现的损失，英文叫Risk。这里要明确一件事：虽然危害可能导致损失，但是危害≠损失。所以威胁分析，是要找到可能造成危害的来源，风险分析，就是在找到这些来源的基础上，分析他们可能造成的损失。

第一个阶段：资产等级划分

这项工作是所有安全评估工作的基础，这阶段的任务是：明确评估目标。应该可以再加一个：明确安全边界。

根据资产的重要性，划分资产等级。在互联网中，安全的核心问题，可能是数据的安全问题。所以做资产等级划分时，很重要的一个参考依据就是：按照数据的重要性确定与数据相关联的资产的重要性。怎么确定各类数据的重要性呢？主要通过访谈形式，当然，如果企业自己已经对数据做出了等级划分，就更好了。

划分完资产等级后，就开始划分安全域和安全边界，建立一个安全模型。后面的评估，就要围绕着安全边界的内部和外部来开展。

第二个阶段：威胁分析

Part 2 讲到过，白帽子和黑帽子对待安全问题的区别：白帽子是宏观的，他要找到所有弱点，不能有遗漏；而黑帽子就简单的多，他是微观的，只要突破一点就可以攻陷系统。白帽子防护系统比黑帽子入侵系统要难得多。所以，白帽子做安全评估，需要对系统的安全威胁做全面的分析，尽可能的找到所有安全弱点。

虽然想找到所有安全弱点很难，但是也不是盲目乱找，有一些科学的威胁建模方法可以帮助我们较为全面的查找威胁。这里介绍较通用的STRIDE模型，最早由微软提出。

STRIDE是6个单词的首字母缩写，我们在分析威胁时，可以从以下6个方面去考虑。

 

在进行威胁分析时，要尽可能地不遗漏威胁，头脑风暴的过程可以帮助确定攻击面。 威胁分析模型也不是一成不变的，相反，它需要经常更新。

第三个阶段：风险分析

并非每个威胁都会造成难以承受的损失，一个威胁到底能够造成多大的危害，如何去衡量它？这就要考虑到风险了。我们判断风险高低的过程，就是风险分析的过程。

风险由两个因素组成：发生的可能性、破坏性（Risk = Probability * Damage Potential）

如何更科学地衡量风险，也相应模型可以帮助我们做判断，这里介绍DREAD模型，它也是由微软提出的。

 

在DREAD模型里，每一个因素都可以分为高、中、低三个等级。在上表中，高、中、低三个等级分别以3、2、1的分数代表其权重值，因此，我们可以具体计算出某一个威胁的风险值。

介绍完威胁建模和风险分析的模型后，我们对安全评估的整体过程应该有了一个大致的了解。在任何时候都应该记住：模型是死的，人是活的，再好的模型也是需要人来使用的，在确定攻击面，以及判断风险高低时，都需要有一定的经验，这也是安全工程师的价值所在。类似STRIDE和DREAD的模型可能还有很多，不同的标准会对应不同的模型，只要我们觉得这些模型是科学的，能够帮到我们，就可以使用。但模型只能起到一个辅助的作用，最终做出决策的还是人。

第四个阶段：制定安全解决方案

安全评估的产出物，就是安全解决方案。

很多人认为，安全和业务是冲突的，因为往往为了安全，要牺牲业务的一些易用性或者性能，事实上并非如此。从产品的角度来说，安全也应该是产品的一种属性，一个从未考虑过安全的产品，是不完整的。（比如：我们要评价一个杯子是否好用，除了它能装水，能装多少水外，还要思考这个杯子内壁的材料是否会溶解在水里，是否会有毒，在高温时会不会熔化，在低温时是否易碎，这些问题都直接影响用户使用杯子的安全性。）

对于互联网来说，安全是要为产品的发展与成长保驾护航的。我们不能使用“粗暴”的安全方案去阻碍产品的正常发展，所以应该形成这样一种观点：没有不安全的业务，只有不安全的实现方式。作为安全工程师，要想的就是如何通过简单而有效的方案，解决遇到的安全问题。安全方案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。好的安全方案对用户应该是透明的，尽可能地不要改变用户的使用习惯。

一个优秀的安全方案应该具备以下特点：能够有效解决问题、用户体验好、高性能、低耦合、易于扩展与升级。