读软件开辟安全之道：概念、设计与实行13Web安全

1. Web安全

1.1. 当蜘蛛网中出现笔墨时，所有人都说这是个奇迹。但是没有人指出蜘蛛网本身就是一个奇迹

• 1.1.1. E.B.怀特
  

1.2. 万维网的巨大成功在很大程度上归因于一个明显的事实​：无数人对它的原理一无所知，但经常利用它

• 1.2.1. 网络的易用性促使它的用户持续增长
  
• 1.2.2. 如此复杂的技术融合在一起所取得的这个非凡成就既是福也是祸
  

1.3. Web是历史上最极度的亡羊补牢的例子

• 1.3.1. 早期的Web设计非常幼稚，没有过多思量安全性
  
• 1.3.1.1. 如果早期创新者在过去试图设计一个完全安全的体系，那么这项任务将会非常艰巨，如果他们失败了，所有积极大概永久不会得到任何结果
  
• 1.3.2. 当代Web是一个标准长期演变的产物，同时被竞争激烈的“浏览器大战”和向后兼容性所困扰
  
• 1.3.3. 尽管当代Web可以变得安全，但它错综复杂的历史意味着它也非常脆弱
  

1.4. 微小的失误很容易造成漏洞

• 1.4.1. 漏洞源于细节，一个安全的网站必须做对很多事情
  

1.5. 在安全框架上的构建要求，这个安全框架会为你处理错综复杂的事件
2. 建立在框架之上

2.1. 借助当代的Web开辟工具，构建网站几乎与利用网站一样简朴
2.2. 依赖高质量的框架，永久不要忽视框架所提供的掩护措施，让有本领的专家来处理所有混乱的细节

• 2.2.1. 一个可靠的框架应该可以使你免受大部门漏洞的影响，但是准确理解框架会做什么以及不做什么也很重要，因为这样你就可以更有效地利用框架
  
• 2.2.2. 从一开始就选择一个安全的框架也很重要，因为你的代码将深深依赖于它，如果它未能达到你的预期，在将来更换框架会非常痛苦
  

2.3. 一样平常准则

• 2.3.1. 选择利用由值得信赖的组织或团队开辟的框架，这些组织或团队会积极地开辟和维护这个框架，以跟上不断变革的网络技术和实践
  
• 2.3.2. 在文档中查找明白书写的安全声明
  
• 2.3.3. 该框架不需要有完美的记载，但相应迟缓或持续存在的问题模式都是伤害信号
  
• 2.3.4. 构建一个小型原型并检查生成的HTML是否拥有正确的转义和引用
  
• 2.3.5. 构建一个简朴的测试平台来试验根本的XSS和CSRF攻击
  

3. Web安全模型

3.1. Web是一种客户端/服务器技术

• 3.1.1. 双方的安全利益经常存在争议，尤其是思量到潜在的攻击者会通过互联网入侵
  
• 3.1.2. 只有在服务器能够很好地提供安全性的情况下，Web才能工作，这样诚信的终端用户才能偶然机得到安全的Web体验
  

3.2. 客户端浏览器的脚色

• 3.2.1. 纵然Web服务器尝试对客户利用的浏览器类型举行限制，使其只能利用特定的版本，但浏览器可以容易实现错误表明自己的身份并绕过这类限制
  
• 3.2.2. 只要服务器是安全的，恶意客户就无法对服务器提供给其他客户的服务造成影响
  
• 3.2.3. Web服务器过度信任那些不值得信任的客户端浏览器，大概是众多Web安全漏洞的根源
  

3.3. HTTP

• 3.3.1. HTTP本身是Web的核心
  
• 3.3.1.1. Web浏览已经成为日常生活的一部门
  
• 3.3.2. Web浏览总是从一个URL（Uniform Resource Locator，同一资源定位符）开始的
  
• 3.3.3. HTTP动作所指定的哀求
  
• 3.3.3.1. GET动作会从服务器哀求内容
  

1. >  3.3.3.1.1. GET请求不会改变服务器的状态

复制代码

• 3.3.3.2. 客户端会利用POST动作来提交表单或上传文件
  

1. >  3.3.3.2.1. POST请求旨在改变服务器的状态

复制代码

• 3.3.3.3. 如果你严酷地遵守标准规则，可以很容易地让你的服务器变得安全
  
• 3.3.4. 一条与安全相关的“铁则”是不要在URL中嵌入敏感数据，而是利用表单POST哀求向服务器发送敏感数据，否则REFERER哀求头在暴露哀求地点的网页URL时会泄露敏感数据
  
• 3.3.5. 一个容易犯的错误是在URL中包罗用户名
  
• 3.3.5.1. 纵然利用了不透明类型的标识符（好比用户名的散列值）​，也会泄露信息，因为窃听者能够通过观察，发现两个单独的URL指向同一个用户
  

3.4. 数字证书和HTTPS

• 3.4.1. 如果你无法得到可靠的专家发起，你可以看看那些主流且值得信赖的网站是怎样做的，而且依照它们的做法
  
• 3.4.2. 安全Web浏览的第一个寻衅是与正确的服务器举行可靠的通信
  
• 3.4.2.1. 如果网络正确地路由并传输了这个哀求，则哀求应该到达预期的服务器
  
• 3.4.2.2. 攻击者大概会干扰DNS查找、路由或者路由途中任何位置的数据
  

1. >  3.4.2.2.1. HTTPS（也称为HTTP over TLS/SSL）是专为缓解这些威胁而开发的协议

复制代码

• 3.4.2.3. 没有人对利用HTTPS来掩护网络金融生意业务的必要性提出过异议，但主流网站完全采用HTTPS的时间线拉得太长了
  

1. >  3.4.2.3.1. 脸书在2013年才完全采用HTTPS

复制代码

• 3.4.2.4. 很难想出什么理由不将网站设置为仅利用HTTPS
  
• 3.4.3. HTTPS提供了一个安全的防篡改端到端加密隧道，而且向客户端保证隧道的另一端确实是预期的服务器
  
• 3.4.3.1. 将这个安全隧道视为用于确认服务器身份的防数据篡改管道
  
• 3.4.3.2. 攻击者大概会窃听到加密数据，但如果没有密钥的话，他只能看到一堆偶然义的比特
  
• 3.4.3.3. 攻击者可以篡改无掩护网络上的数据，但如果利用了HTTPS，任何篡改都会被发现
  
• 3.4.3.4. 攻击者可以制止通信的举行，好比在物理上割断电缆，但你可以确保数据总是真实的
  
• 3.4.4. HTTPS对于确保真实性和完备性也很重要
  
• 3.4.4.1. HTTPS确保客户端正在与哀求URL中指定的真实服务器举行通信，而且它们之间传输的数据不会被窥探或篡改
  
• 3.4.5. 随着HTTPS和技术环境的成熟，广泛采用HTTPS的末了一个障碍是得到服务器证书的开销
  
• 3.4.5.1. 尽管大公司能够负担受信任的CA收取的费用，而且会有工作人员负责管理和更新证书，但较小网站的所有者却对这份额外的本钱和管理工作夷由不决
  
• 3.4.5.2. 受益于电子火线基金会的大力推动和众多行业公司的赞助，非营利组织互联网安全研究小组的产品Let’s Encrypt为环球用户提供了一个免费、主动化和开放的CA
  

1. >  3.4.5.2.1. 可以免费向任何网站所有者提供DV（Domain Validation，域验证）证书
3. >  3.4.5.2.2. DV证书通常是你用来证明网站身份所需的全部内容
5. >  3.4.5.2.3. DV证书只能证明这个Web服务器的域名已经经过了验证
7. >  3.4.5.2.4. 随着免费DV证书的激增，其他类型证书的使用前景变得模糊
9.   >   3.4.5.2.4.1. 用户很少关心这种信任的区别，OV和EV证书在技术和法律上的细微差别也比较难以说清

复制代码

• 3.4.6. 在将Web服务器设置为利用带有证书的HTTPS后，你必须确保它始终利用HTTPS
  
• 3.4.7. 利用HTTPS选项，让通信双方为加密隧道协商密码套件(cipher suite)
  
• 3.4.7.1. 最好的防御措施是确保你的HTTPS配置仅运行安全的当代加密算法
  
• 3.4.8. 为了缓解这类攻击，我们可以始终将HTTP重定向到HTTPS，而且仅为HTTPS利用Web cookie
  
• 3.4.8.1. 在HTTP相应头中包罗Strict-Transport-Security指令，以便浏览器知道该网站始终利用HTTPS
  
• 3.4.8.2. 要想完全保障HTTPS网页的安全性，它必须仅利用HTTPS
  
• 3.4.8.3. 意味着服务器上的所有内容（所有脚本、图像、字体、CSS，以及其他引用资源）都应该利用HTTPS
  

3.5. 同源策略

• 3.5.1. Same Origin Policy，SOP
  
• 3.5.2. 浏览器会将来自不同网站的资源隔脱离（通常通过窗口或标签页）​，因此这些资源不会相互影响
  
• 3.5.3. 仅当资源的主机域名和端口号雷同时，资源之间才可以举行交互
  
• 3.5.4. 同源策略适用于脚本和cookie（与一样平常的同源策略有些许不同）​，它们都有大概在独立网站之间泄露数据
  
• 3.5.5. 尽管同源策略制止了来自其他网站页面中脚本的进入，但网页始终可以随意选择访问不同的网站，并将其内容拉到窗口中
  

3.6. Web cookie

• 3.6.1. cookie是指服务器要求客户端为其存储在本地的小的数据字符串，客户端会根据后续哀求将其提供给服务器
  
• 3.6.2. 虽然任何客户端都可以篡改自己的cookie，并将自己的会话伪装成其他会话，但如果会话cookie设计适当的话，客户端应该无法伪造有效的会话cookie
  
• 3.6.3. 并不意味着cookie没有用，cookie可以用来记着客户的偏好、最喜爱的商品或其他详细信息，篡改这些信息不会对商家造成伤害
  
• 3.6.4. 服务器可以设置会话cookie的过期时间，但由于服务器不能总是依赖于客户来主动实行这个操纵，服务器还必须对需要更新的会话cookie的有效性举行限制
  
• 3.6.5. cookie会受到同源策略的约束，并对子域之间的共享做出明白规定
  
• 3.6.5.1. 虽然子域可以看到其父域设置的cookie，但不能修改这些cookie
  
• 3.6.6. 脚本在名义上可以通过DOM访问cookie，但这种便利性会为设法在网页中运行的恶意脚本提供时机以盗取cookie，因此最好通过实行httponly cookie属性来制止脚本的访问
  
• 3.6.6.1. HTTPS网站还应该应用secure属性，指示客户端只通过安全隧道发送cookie
  
• 3.6.7. 向后兼容性与当代安全性之间的紧张关系带来了妥协的解决方案，这也说明了如果一开始没有思量安全性的话，未来安全性会变得含糊不清
  
• 3.6.8. HTML5为安全模型添加了很多扩展
  
• 3.6.8.1. 一个典型的例子是CORS（Cross-Origin Resource Sharing，跨源资源共享）​，它答应有选择地放宽同源策略的限制，以使其他受信任的网站能够访问数据
  
• 3.6.8.2. 浏览器也提供了Web存储API，这是用于Web应用步伐的一种更当代的客户端侧存储功能，它也受限于同源策略
  

4. 跨站脚本攻击

4.1. XSS（Cross-Site Scripting，跨站脚本）攻击
4.2. 同源策略提供的隔离是构建安全网站的基础，但如果我们不采取必要的预防措施，这种掩护很容易遭到破坏
4.3. XSS攻击是针对Web的注入攻击，它的恶意输入会改变网站的行为，通常会答应运行未经授权的脚本
4.4. XSS漏洞对于攻击者来说并不难发现，因为他们可以容易地查看网页内容，来了解这个HTML内部的工作原理

• 4.4.1. 攻击者会设法将恶意数据存储在服务器或客户端中
  

4.5. 基于DOM的XSS攻击，它将HTML DOM作为恶意注入的来源，但其他方面的工作方式大致雷同
4.6. 一个安全的Web框架应该内建XSS掩护，在这种情况下，只要在框架内你就是安全的

• 4.6.1. 与任何注入漏洞一样，防御机制包罗制止任何不受信任的输入进入Web页面，以及有大概发生的恶意行为，或者实行输入验证来确保安全地处理输入
  

5. 跨站哀求伪造

5.1. CSRF（Corss-Site Request Forgery，跨站哀求伪造）
5.2. 跨站哀求伪造（CSRF，偶然缩写为XSRF）是对同源策略根本限制的攻击
5.3. Web框架应该提供CSRF掩护，但深入了解底层问题也很有价值，这样你就可以确认掩护机制确实有效，而且能够确保不会干扰该机制
5.4. 同源策略对于POST的处理与GET雷同，而且POST哀求可以修改站点的状态
5.5. 为了防止CSRF攻击，请确保攻击者无法猜测有效的状态更改哀求

• 5.5.1. 将每个有效的POST哀求都视为一片特殊的雪花，它只能在其预期的利用环境中工作一次
  
• 5.5.2. 一个简朴的方法是在所有表单中包罗一个秘密令牌并将其作为隐藏字段，然后检查每个哀求中是否包罗与给定Web会话雷同的秘密令牌
  
• 5.5.3. 从会话cookie中派生出令牌是一个很好的解决方案
  
• 5.5.3.1. 检查所必需的信息都可以在POST哀求中得到
  
• 5.5.4. 另一种缓解措施是利用随机数（不可猜测的一次性令牌）​，但为了抵御CSRF攻击，你仍须将其与预期的客户会话绑定在一起
  
• 5.5.4.1. 这个解决方案会为表单的CSRF令牌生成一个随机数，将令牌存储在一个由会话举行索引的表中，然后通过查找会话的随机数并判断它与表单中的随机数是否匹配，对表单举行验证
  

5.6. 当代浏览器在cookie上支持利用SameSite属性来缓解CSRF攻击

• 5.6.1. SameSite=Strict会制止页面上的任何第三方哀求向其他域发送cookie，这就会制止CSRF攻击，但在导航到另一个需要其cookie的站点时大概会破坏由cookie带来的有用行为
  
• 5.6.2. 一种客户端侧对于CSRF的防御措施，服务器完全依赖它大概碰面对风险，因此应该将其作为额外的缓解措施，而不是唯一的缓解措施
  

6. 注意的问题

6.1. 不要让攻击者将不受信任的输入注入HTTP头（类似于XSS）
6.2. 指定准确的MIME内容类型，以确保浏览器正确地处理相应
6.3. 开放式重定向大概会出现问题：不答应重定向到任意URL
6.4. 仅利用＜IFRAME＞嵌入你可以信任的网站（很多浏览器支持X-Frame-Options头缓解措施）​
6.5. 在处理不受信任的XML数据时，要注意XXE攻击
6.6. CSS的:visited选择器大概会披露浏览器历史中是否有给定的URL
6.7. CSP（Content Security Policy，内容安全策略）相应头，以减少XSS暴露

• 6.7.1. 可以为脚本或图像指定拥有授权的来源（和其他类似功能）​，答应浏览器制止从其他域注入内联脚本或其他恶意内容的尝试
  
• 6.7.2. 客户端侧的防御措施，不受你的控制，因此不要将其看尴尬刁难XSS完全免疫的通行证
  

6.8. 在测试环境中，在所有Web页面中添加特定的安全策略，然后对网站举行测试，并针对每个问题追踪被制止的行为
6.9. 很多HTTP相应头可以帮助你指定浏览器应该答应或不应该答应的内容，包罗Content- Security-Policy相应头、Referrer-Policy相应头、Strict-Transport-Security相应头、X-Content-Type-Options相应头和X-Frame-Options相应头

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。