注意没排版，缺注释，西文标点，口语表达 第五章 安全 如果在跳舞 ....docxVIP

注意：没排版，缺注释，西文标点，口语表达 第五章 安全 如果在跳舞的猪和安全之间选择，用户无一例外会选择跳舞的猪。 -Ed Felten 和 Gary McGraw 一些小网站或低流量应用程序常忽视安全问题；不幸的是，Web的触角已经延伸到这样一种程度：端对端安全对任何面向公众网站都是基本要求。如今确实有人无所事事到对“埃德娜阿姨的好玩猫图片”这样的网站进行分布式拒绝服务攻击（distributed denial-of-service attack）。若是仅仅把网站当作可在互联网上存取的结果，没人可以承担忽略危险的责任。 在本章中，我们会自顶向下的探讨困扰web开发者的多个安全相关问题。我们先从架构及应用级别的原则开始，这些原则需时刻牢记。然后再进一步展开。我们将会探讨当你在较低层次使用rails时应该牢记的一些安全问题。 应用程序问题 首先来探讨一些应该用于指导任何web应用设计的重要原则。 认证(Authentication) 认证领域最重要的方针相当简单： 一定要salt和hash密码！ 这条规则几乎不存在例外，尤其对于web应用程序。将密码存储成纯文本格式仅有一个理由：密码需要以纯文本的方式提供给外部服务。即便这样，也应该使用双方共知的密码进行对称性加密，以提供深入的防护。 我们来看这条规则背后的道理。对密码进行hash是为了防止数据库或源码被攻破后密码泄露。对密码进行salting是防止揣测攻击（rainbow attacks）。 Salting是确保同一密码针对不同用户会hash成不同值的过程。参考下面的代码，它做了hash但没有salt。 require digest/sha1 $hashes = {} def hash(password) Digest::SHA1.hexdigest(password) end def store_password(login, password) $hashes[login] = hash(password) end def verify_password(login, password) $hashes[login] == hash(password) end store_password(alice, kittens) store_password(bob, kittens) $hashes # = {alice=3efd62ee86d4a141c3e671d86ba1579f934cf04d, # bob= 3efd62ee86d4a141c3e671d86ba1579f934cf04d} verify_password(alice, kittens) # = true verify_password(alice, mittens) # = false verify_password(bob, kittens) # = true 尽管这比把密码存成纯文本要安全些，但还是不够安全；有hash文件的人都能看出Alice和Bob的密码是一样的。 更重要的是，这种方案容易受到“揣测攻击”（rainbow attack）。攻击者可以对一个字典中的所有词使用该hash算法预先计算一个揣测表格（rainbow table），接着将揣测表格中的每个hash跟密码文件中的每个hash比对。由于一个密码总会hash成同一个值，因而攻击者如同老鹰抓小鸡一样，因而攻击者一举破解了字典中所有的密码。 预防这样的攻击，可以在hash密码的同时进行salt操作。比较以下代码： require digest/sha1 $hashes = {} $salts = {} def hash(password, salt) Digest::SHA1.hexdigest(--#{salt}--#{password}--) end def generate_salt(login) Digest::SHA1.hexdigest(--#{Time.now.to_s}--#{login}--) end def store_password(login, password) salt = $salts[login] = generate_salt(login) $hashes[login] = hash(password, salt) end def verify_password(login, password) $hashes[login] == hash(password, $salts[login]) end store_password(alice, kittens) store_password(bob, kittens) $hashes