读白帽子讲WEB安全，摘要

读<白帽子讲WEB安全>摘要

我的安全世界观

安全三要素-CIA

1. 机密性 Confidentiality

   • 数据不被泄漏
     • 加密

2. 完整性 Integrity

   • 保护数据内容完整的、没有被篡改
     • 数字签名

3. 可用性 Availability

   • DOS-Denial Of Service 攻击会破坏可用性

4. 拓展：可审计性、不可抵赖性

如何实施安全评估

互联网安全的核心问题，是数据安全的问题。

1. 资产等级划分

   1. 了解公司最重要的资产是什么，他们最看重的数据是什么 。通过访谈的形式，安全 部门才能熟悉、了解公司的业务，公司所拥有的数据，以及不同数据的重要程度，为后续的安 全评估过程指明方向
   2. 信 任域和信任边界,网络逻辑上来划分。比如最重 要的数据放在数据库里，那么把数据库的服务器圈起来； Web 应用可以从数据库中读/写数据， 并对外提供服务，那再把 Web 服务器圈起来；最外面是不可信任的 Internet

2. 威胁分析

   危害的来源称为威胁（Threat）

   可能会出现的损失称为风险（Risk）

   1. 威胁建模

      什么是威胁分析？威胁分析就是把所有的威胁都找出来。怎么找？一般是采用头脑风暴 法。当然，也有一些比较科学的方法，比如使用一个模型，帮助我们去想，在哪些方面有可能 会存在威胁，这个过程能够避免遗漏，这就是威胁建模。

      • STRIDE 模型

威 胁	定 义	对应的安全属性
Spoofing（伪装）	冒充他人身份	认证
Tampering（篡改）	修改数据或代码	完整性
Repudiation（抵赖）	否认做过的事情	不可抵赖性
InformationDisclosure（信息泄露）	机密信息泄露	机密性
Denial of Service（拒绝服务）	拒绝服务	可用性
Elevation of Privilege（提升权限）	未经授权获得许可	授权

• 风险分析

  我们判断风险高低的过程，就是风险分析的过程 .

  风险由以下因素组成：

  Risk = Probability * Damage Potential

  • DREAD 模型

• 等 级	高(3)	中(2)	低(1)
  Damage Potential	获取完全验证权限；执行管理员操 作；非法上传文件	泄露敏感信息	泄露其他信息
  Reproducibility	攻击者可以随意再次攻击	攻击者可以重复攻击，但有时间 限制	攻击者很难重复攻击 过程
  Exploitability	初学者在短期内能掌握攻击方法	熟练的攻击者才能完成这次攻击	漏洞利用条件非常苛刻
  Affected users	所有用户，默认配置，关键用户	部分用户，非默认配置	极少数用户，匿名用户
  Discoverability	漏洞很显眼，攻击条件很容易获得	在私有区域，部分人能看到，需 要深入挖掘漏洞	发现该漏洞极其困难

• 确认解决方案

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

  2. 设计解决方案不难，难的是如何设计一个好的解决方案。设计一个好的解决方案，是真正 考验安全工程师水平的时候。 很多人认为，安全和业务是冲突的，因为往往为了安全，要牺牲业务的一些易用性或者性 能，笔者不太赞同这种观点。从产品的角度来说，安全也应该是产品的一种属性。一个从未考 虑过安全的产品，至少是不完整的。

  3. 没有不安全的业务，只有不安全 的实现方式。

  4. 安全方 案必须能够有效抵抗威胁，但同时不能过多干涉正常的业务流程，在性能上也不能拖后腿。

  5. ，一个优秀的安全方案应该具备以下特点：

     1. 能够有效解决问题；
     2. 用户体验好；
     3. 高性能；
     4. 低耦合；
     5. 易于扩展与升级

  白帽子兵法

  1. Secure By Default 原则 ，也可以归纳为白名单、黑名单的思想

     1. 黑名单、白名单
     2. 最小权限原则

  2. 纵深防御原则

     不同的层面、不同的角度对系 统做出整体的解决方案。

     我们常常听到“木桶理论”这个词，说的是一个桶能装多少水，不是 取决于最长的那块板，而是取决于最短的那块板，也就是短板。设计安全方案时最怕出现短板， 第 1 章 我的安全世界观 19 木桶的一块块板子，就是各种具有不同作用的安全方案，这些板子要紧密地结合在一起，才能 组成一个不漏水的木桶。

     在常见的入侵案例中，大多数是利用 Web 应用的漏洞，攻击者先获得一个低权限的 webshell， 然后通过低权限的 webshell 上传更多的文件，并尝试执行更高权限的系统命令，尝试在服务器上 提升权限为 root；接下来攻击者再进一步尝试渗透内网，比如数据库服务器所在的网段。

     Web 应用 安全、 OS 系统安全、数据库安全、网络环境安全等。在这些不同层面设计的安全方案，将共 同组成整个防御体系，这也就是纵深防御的思想。

     纵深防御的第二层含义，是要在正确的地方做正确的事情。 如何理解呢？它要求我们深入 理解威胁的本质，从而做出正确的应对措施。

  3. 数据与代码分离原则

     这一原则广泛适用于各种由于“注入”而 引发安全问题的场景。

     实际上，缓冲区溢出，也可以认为是程序违背了这一原则的后果——程序在栈或者堆中， 将用户数据当做代码执行，混淆了代码与数据的边界，从而导致安全问题的发生。

     在 Web 安全中，由“注入”引起的问题比比皆是，如 XSS、 SQL Injection、 CRLF Injection、 X-Path Injection 等。此类问题均可以根据“数据与代码分离原则”设计出真正安全的解决方案， 因为这个原则抓住了漏洞形成的本质原因。

  4. 不可预测性原则

     不可预测性原则，可以巧妙地用在一些敏感数据上。比如在 CSRF 的防御技术中，通常会 使用一个 token 来进行有效防御。这个 token 能成功防御 CSRF，就是因为攻击者在实施 CSRF 攻击的过程中，是无法提前预知这个 token 值的，因此要求 token 足够复杂时，不能被攻击者 猜测到。

• 客户端安全

  浏览器安全

  同源策略

  same origin policy 时浏览器也是最核心的功能。如果缺少同源策略，浏览器的正常功能都会受影响。

  浏览器只是同源策略的一种实现。

  浏览器的同源策略，限制了来自不同源的"document" 或脚本，对当前的“document ”读取或者设置某些属性。

  影响源的由 host (域名或ip地址）、子域名、端口、协议。

  但浏览器中

  XMLHttpRequest受到同源策略的约束，不能跨域访问资源。

  随着业务的发展，跨域请求越来越迫切。因此W3C委员会制定了XMLHttpRequest跨域访问的要求，他需要通过目标域返回的HTTP头来授权是否允许跨域访问，因为http头对于javascript来说一般是无法控制的，所以这个方案是可以实施的，这个跨域方案的安全基础:javaScript 无法控制该Http头。如果信任基础被打破。则此方案将不在安全。

  对于浏览器来说，处理DOM、cookie、XMLHttpRequest受到同源策略的限制外。浏览器加载的一些第三方插件也有各自的同源策略。最常见的插件有 flash、java applet、silverlight、 google gears等都有自己的控制策略。

  浏览器沙箱

  采用sandbox技术，让不受信任的脚本允许在一个受限制的环境中，从而可以保证本地桌面系统的安全。

  恶意网址拦截

  挂马 攻击是在正常的网页中，通过 script 或 iframe 等标签加载恶意的网址。

  钓鱼网站、诈骗网站对用户来说也是一种恶意网址。

  恶意网址的拦截非常简单，定期从服务器端获取一份最新的恶意网址清单。用户在浏览恶意网站时会弹出警告。

  常见的恶意网址分两类：一类是挂马网站、一类是钓鱼网站。

  高速发展的浏览器安全

  IE 推出Xss filter

  firefox 推出的csp

  XSS 跨站脚本攻击

  XSS简介

  XSS = cross site script

  XSS 通常指黑客通过 “html注入” 篡改了网页，插入了恶意的脚本。而从在用户浏览网页时，控制用户浏览器的一种攻击。这种攻击的演示案例是跨域的，所以叫跨站脚本，但是发展到今天，是否跨域已经不在重要。

  • 反射型XSS

  简单的把脚本反射给浏览器，黑客 往往要诱使客户‘"点击"一个恶意链接。才能攻击成功。

  • 存储型XSS

  把用户输入的数据存储在服务器端，这种XSS具有很强的稳定性。

  • DOM Based XSS

  通过修改页面的dom节点形成的XSS，称之为DOM based XSS

  XSS 攻击进阶

  初探XSS Payload

  从攻击者的角度来体验下XSS的威力。

  XSS攻击成功后，攻击者能够对当前浏览器的页面植入恶意脚本，通过恶意脚本。控制用户的浏览器，用于完成具体功能的恶意脚本。被称之为“xss payload”。

  常见的payload就是cookie劫持。

  cookie中一般保存了当前用户的登录凭证。如果cookie丢失，往往意味着用户的登录凭证丢失。换句话说，攻击者可以不通过密码，而直接登录进用户的账户。

  攻击者获取到用户的cookie后，可以使用此cookie发起攻击。

  强大的xss payload

  构造GET和POST请求。

  一个网站只接受http协议中的get和post请求，对攻击者来说，只通过JavaScript就可以让浏览器发送此请求。

  此不需要劫持用户的cookie，只要构造 网站的现有get或post方法。即可控制客户的浏览器。

  XSS钓鱼

  1. xss的攻击过程都是JavaScript自动进行的，也就是说缺少交互过程。

  • 如果在构造post请求是，加上验证码，但也不能彻底防止。

    攻击者：对于验证码可以把验证码图片发送到攻击者后台识别。

  • 此外在大多数修改密码的功能会要求输入旧密码。但是这也不能防止xss payload。

    修改密码问题稍微复杂，需要将XSS与"钓鱼"相结合。

    实现思路：使用javascript在当前页面上"画出"一个伪造的登陆框，当用户在登录框输入用户名与密码，将密码发送至黑客的服务器上。

  2. 识别用户浏览器

  3. 识别用户安装的软件

  CSS history hack

  利用style的visited属性，如果用户曾经访问过某个链接，那么这个链接的颜色会变的与众不同。

  获取用户的真实IP

  xss攻击框架 “attack ip” 由可以获取本地api

  XSS 攻击平台

  • attach api
  • BeEF
  • XSS-Proxy

  终极武器 XSS Worm

  一般来说，用户之间发生发生交互行为的页面，如果存在存储型XSS，比较容易发起XSS Worm

  调试JavaScript

  • firebug
  • ie 8 developer tools
  • fiddler
  • httpwatch

  XSS构造技巧

  1. 利用字符编码
  2. 绕过长度限制。

  • 利用事件，加载location.hash的值
  • 利用注释，合并2个input标签

  3. 使用base标签。 在设计XSS 安全方案时 一定要过滤这个非常危险的标签
  4. window.name 的妙用。

  window 对象时浏览器窗体

  5. 变废为宝 Mission Impossible

  • apache expect header xss

  • anehta的回旋镖

  • flash xss

  • JavaScript 开发框架 真的安全么
    dojo
    yui
    jquery

  XSS 防御

  XSS的本质是HTML注入。将用户的数据当作代码执行。

  HttpOnly

  解决XSS攻击中的cookie劫持问题。

  服务器可以设置多个cookie，可以给制定的cookie设置HttpOnly。

  respone.setHeader("Set-Cookie","cookieName=value;Path=/;Domain=domainValue;Max-Age=seconds;HTTPOnly");
  
    
    
  
    
    
  1

  输入检查

  XSS攻击和Sql Injection。需要对输入进行检查。这种检查被称为“XSS Filter”。

  对 script 和 javascript onclick alert 等以下关键字处理。

  输出检查

  一般来说，除了富文本输出外，在变量输出到HTML页面时，可以使用编码或转义的方式来防御XSS攻击。

  1. 安全的编码函数

     编码分为很多种，针对html代码的编码方式是HtmlEncode。HtmlEncode不是专有名字，是一种函数的实现。作用就是将字符转换成HTMLEntries，对应的标准是ISO-8859-1。

     在javascript可以使用JavaScriptEncode。

     & -> &
     > -> >
     < -> &lt;
     " -> &quot;
     ' -> &#x27;
     / -> &#x2F;
     
        
        
     1
     2
     3
     4
     5
     6

  正确的防御XSS攻击

     1. HTML 标签中输出。`HtmlEncode`解决 。
     2. HTML 属性中输出。`HtmlEncode`解决。
     3. script标签中输出。`javascriptencode`解决
     4. 事件中输出。`javascriptencode`解决。
     5. css标签中输出。`encodeforcss`解决。
     6. 在地址中输出。`URLEncode`解决。
  
   
   
  1
  2
  3
  4
  5
  6

  处理富文本

  1. 过滤富文本，比较危险的标签，比如<iframe>、<script>、<base>、<form>等。
  
   
   
  1

  防御 DOM Base XSS

  javascript 输出到html页面，相当于一次XSS输出的过程。需要分语境使用不同的的编码函数。
  >`javascript`输出到html event 或 script tag需要JavaScriptEncode
  >`javascript`输出到html content 或 script attribute 需要 JavaScriptEncode.
  ```javascript
  1. javaScript输出到html页面
      document.write()
      document.write()
      xxx.innerHtml()
      doucument.attachEvent()
      window.attachEvent()
      document.location.replace()
      documment.location.assign()
  2. 可能出现dom base xss
  	页面所有的输入框
  	windows.location href hash
      window.name
  	window.refer
  	document.cookie
  	localstorage
      XMLHttpRequest 返回的数据
  ```
  
   
   
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21

  CSFR跨站请求伪造

  cross site request forgery

  CSRF 进阶

  浏览器的cookie策略

  cookie分为：

  1. “session cookie” 又叫 “临时cookie”。浏览器关闭就失效。
  2. “third party cookie” 也称为"本地cookie"、第三方cookie。在set-cookie时设置了Expire时间，到了Expire时间，cookie失效。

  出于安全考虑，IE默认禁止了浏览器在<img>、<iframe>、<script>、<link>等标签发送第三方cookie。

  Firefox chrome 默认会发送第三方cookie。

  P3P

  the platform for privacy preferences

  如果http返回的 header中含有P3P头，在某种程度上将允许浏览器发送第三方cookie，在IE下即使是>&amp;#12289;

  但是如果设置了P3P 头可以允许跨域访问隐私数据， 从而使跨域set-cookie成功。

  在网站业务中，P3P头主要用于类似广告的等需要跨域的访问页面。但遗憾的是P3P头设置后，对cookie的影响到 了整个域的页面，因为cookie是以域和path为单位的。这并不符合“最小权限”原则。

  cookie是以域和path为单位的

  诱导用户访问恶意链接。可调用系统的现有的接口，导致出现一些客户不知情的操作。

  get or post

  get和post都能发起csrf攻击。

  Flash CSRF

  IE6 IE7，flash发送的网络请求可以带上本地cookie，从ie8起，flash发起的网络请求不再发送本地cookie。

  CSRF worm

  CSRF防御

  1. 验证码

  2. Referer check

     常见的应用就是"防止图片盗链"。Referer check 也可以被用于检查请求是否来自合法的源。

     常见的互联网应用，页面与页面之间都具有逻辑关系，这使得每个正常的请求Referer具有一定的规律。

     缺陷：服务器并非任何时候都能获取Referer。
     refer policy说明

  https://w3c.github.io/webappsec-referrer-policy/#referrer-policies

  3. Anti CSRF Token

     CSRF 为什么能成功，因为重要操作的所有参数是可以被攻击者猜测到的。

     新增一个参数Token，token是安全的随机数生成算法。

     提交表单时，带上随机token，token的值也存在session中，在提交处理中校验token是否存在

  4. Token 的使用原则

     1. 防御CSRF的Token，是根据“不可测性原则”设计的方案，需要使用安全的 随机数生成Token.

     2. Token的目的不是为了防重复提交。虽然可以达到此效果。

     3. Token 应保持保密性，如出现在URL中，可能会在Referer中泄漏。应该使用ajax或post提交。

        还有一些XSS漏洞或者跨域漏洞可能让攻击者窃取到Token值。

     4. Token 仅仅是用于对抗CSRF攻击，当网站还有其他XSS漏洞时，这个方案会变得无效。因为XSS可以模拟客户端浏览器执行任意操作。攻击者完全可以请求页面后，读出页面token的值，然后再构造一个合法的请求，这个过程可以称为 XSRF和CSRF区分开。

  点击劫持

  ClickJacking

  点击劫持是一种视觉上的欺骗。往往使用透明的iframe嵌入目标网站。欺骗目标网站用户，窃取客户信息。

  flash点击劫持:

  图片覆盖攻击

  拖拽劫持和数据窃取

  触屏劫持

  智能终端上的触屏劫持

  防御点击劫持

  可以写一段JavaScript代码，以禁止iframe嵌套，这种方法是 frame busting。

  frame busting

  是指利用js判断location以防止网页被别人iframe内嵌的一个实现

  比如以下代码:

  if(top.location != location){
      top.location=self.location;
  }
  
   
   
  
   
   
  1
  2
  3

  常见的frame busting 条件判断

  1.    if (top != self)
  

  2. if (top.location != self.location)

  3. if (top.location != location)

  4. if (parent.frames.length > 0)

  5. if (window != top)

  6. if (window.top !== window.self)

  7. if (window.self != window.top)

  8. if (parent && parent != window)

  9. if (parent && parent.frames && parent.frames.length>0)

  10. if((self.parent&&!(self.parent===self))&&(self.parent.frames.length!=0))

  如果frame busting 条件判断为真，常见的动为以下：

  1. top.location = self.location

  2. top.location.href = document.location.href

  3. top.location.href = self.location.href

  4. top.location.replace(self.location)

  5. top.location.href = window.location.href

  6. top.location.replace(document.location)

  7. top.location.href = window.location.href

  8. top.location.href = “URL”

  9. document.write(’’)

  10. top.location = location

  11. top.location.replace(document.location)

  12. top.location.replace(‘URL’)

  13. top.location.href = document.location

  14. top.location.replace(window.location.href)

  15. top.location.href = location.href

  16. self.parent.location = document.location

  17. parent.location.href = self.document.location

  18. top.location.href = self.location

  19. top.location = window.location

  20. top.location.replace(window.location.pathname)

  21. windowwindow.top.location = window.self.location

  22. setTimeout(function(){document.body.innerHTML=’’;},1);

  23. window.self.onload = function(evt){document.body.innerHTML=’’;}

  24. var url = window.location.href; top.location.replace(url)
      

      • 1
      • 2
      • 3
      • 4
      • 5
      • 6
      • 7
      • 8
      • 9
      • 10
      • 11
      • 12
      • 13
      • 14
      • 15
      • 16
      • 17
      • 18
      • 19
      • 20
      • 21
      • 22
      • 23
      • 24
      • 25
      • 26
      • 27
      • 28
      • 29
      • 30
      • 31
      • 32
      • 33
      • 34
      • 35
      • 36
      • 37
      • 38
      • 39
      • 40
      • 41
      • 42
      • 43
      • 44
      • 45
      • 46
      • 47
      • 48
      • 49
      • 50
      • 51
      • 52
      • 53
      • 54
      • 55
      • 56
      • 57
      • 58
      • 59
      • 60
      • 61
      • 62
      • 63
      • 64
      • 65
      • 66
      • 67
      • 68
      • 69

  几种攻击方法：

  1. 二次frame（不能针对 top.location，只能针对 parent.location）
  2. 利用 onbeforeunload 事件
  3. xss
  4. 构造referer绕过js referer检查
  5. 浏览器漏洞。
  6. iframe security属性（仅IE支持）
  7. iframe sandbox属性（HTML5）
  8. 浏览器designmode
  9. 部分手机站点

  相关总结：

  http://seclab.stanford.edu/websec/framebusting/

  X-Frame-Options

  • DENY 拒绝当前页面记载任何iframe

  • SAMEORIGIN iframe只能是同源域名下的页面

  • ALLOW-FROM origin 可以定义iframe可以加载的地址

  1. X-Frame-Options
  2. firefox 的content security policy和noscript 也能有效防御click-jacking
  3. 用hidden 元素的方法，有点山寨，不过有用且通用

  HTML5安全

  html新标签的xss

  可嵌入javascript实现xss攻击。

  有研究者建立了一个html5 security cheatsheet项目。

  iframe 的sandbox属性

  “”	应用以下所有的限制。
  allow-same-origin	允许 iframe 内容被视为与包含文档有相同的来源。
  allow-top-navigation	允许 iframe 内容从包含文档导航（加载）内容。
  allow-forms	允许表单提交。
  allow-scripts	允许脚本执行。

  link types ： noreferer

  html5的标签 可以指定noreferer，浏览器在请求该标签指定的地址时不再发送Referer.

  这是出于保护敏感信息和隐私的考虑，因为通过referer可能会泄露一些敏感数据。

  canvas的妙用

  canvas可以使javascript可以操作图片的像素。

  其他安全问题

  cross-origin resource sharing CORS

  浏览器的同源策略 same origin policy 限制了脚本的跨域请求。互联网的趋势越来越开放。跨域访问需要越来越急迫。出现很多跨域的技术 jsonp 、iframe 等。

  1. XMLHttpRequest 在ie中可以使用XDomainRequest来跨域。

  2. 使用response的header中设置Access-Control-Allow-Origin的值*，但是很不安全。

     https://w3c.github.io/webappsec-referrer-policy/#referrer-policies
     可以使用request中header中origin 。origin不像referer一样容易被伪造或者置为空。

  postMessage 跨窗口传递消息

  在跨站脚本攻击 一章中，曾经提到利用 window.name 来跨窗口，跨域传递信息。window对象几乎不受同源策略限制。很多脚本都利用了window对象这一个特点。

  服务器端应用安全

  注入攻击

  注入攻击的本质是将用户的数据当作代码来执行。
  两个关键条件

  1. 用户能控制输入
     2.程序原本要执行的代码，拼接了用户输入的数据。

  sql注入

  1. 盲注

  2. timing attack

  数据库攻击技巧

  常见的攻击技巧
  命令执行
  攻击存储过程
  编码问题
  sql cluumn truncation
  
   
   
  1
  2
  3
  4
  5

  数据库防御

  找到所有的sql注入漏洞
  修补这些漏洞

  1. 使用预编译语句
  2. 使用存储过程
  3. 检查数据类型

  严格过滤检查 用户的输入数据。

  4. 使用安全函数

  其他注入

  1. xml注入

  xml注入越要满足注入的攻击的两大条件。用户能控制输入的数据，程序拼凑了数据。
  与html一样，将“语言本身的保留字符”进行转义处理。

  2. 代码注入
  3. CRLF 注入

  cr = carriage return
  lf = lind feed

  文件上传文件

  上传漏洞概述漏洞
  文件上传常见漏洞

  1. 上传的文件是web脚本语言，服务器的web容器解释并执行用户上传的脚本，导致代码执行。
  2. 上传文件时flash的策略文件domain.xml,类似浏览器下的跨域。
  3. 上传文件是病毒和木马、黑客用以诱骗用户或者管理员下载执行。
  4. 删除的是钓鱼图片或者包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。
     绕过文件上传检查功能。

  功能还是漏洞

  apache 文件解析问题
  apache 1.x 2.x 对于不认识的文件按照php文件处理。

  IIS文件解析问题
  PHP的cgi问题
  利用上传文件钓鱼

  钓鱼网站在传播的时候，会通过利用xss，服务端的302跳转等功能，从正常网站跳转到钓鱼网站。

  设置安全的文件上传功能

  1.文件上传的目录设置为不可执行
  2.判断文件类型
  3.使用随机数改写文件名称和路径
  4.单独设置文件服务器域名

  由于浏览器同源策略，一系列的客户端攻击将失效，比如上传crossdomain、上传包含javascript的xss利用等问题将解决。

  认证和会话管理

  认证目的是认出用户是谁。就是认证用户凭证的过程。

  而授权的目的是为了决定用户能够做什么。

  密码那些事儿

  • 密码必须是不可逆加密算法或者单向散列算法，加密后存储在数据库中的，sha-1 、md5 存储。

  • 多因素认证，以支付宝为例，支付密码，安全问题，实名认证，短信验证，证书 等等。

  session 与认证

  session一旦在声明周期内被窃取，就等于账户失窃，Session是用户登陆的凭证，黑客将不在登陆，因此黑客不再需要登录过程。
  session泄漏的途径很多，xss攻击、网络sniff以及本地木马窃取。
  xss攻击通过设置httponly解决，对于网络嗅探，本地木马只能通过客户端 解决。

  sessionId 生成必须要要有随机性。
  手机很多浏览器都不支持session，都是在url中传输sessionId。

  session fixation 攻击

  登录后需要重写sessionId。

  session保持攻击

  session保持攻击，可以通过不断的访问后台，保持服务器session有效。
  甚至攻击者可以 把session cookie 增加一个expire date变成了third party session。永远的持久化在客户本地。
  如何防御
  强制将session过期，或者客户存在多个session。以最后一个session生效。其他的session都是失效。

  sso 单点登录 single sign on

  访问控制

  what can i do ?

  某个主体 subject能对某个个体 object 需要实施某种操作

  垂直权限管理

  访问控制实际上是建立用户与权限的关系。
  现在由一种通用的方法，基于角色的访问控制,role base access contorl 简称RBAC.
  不同角色的权限有高低，往往高权限能防访问低权限的资源。
  用户->角色->权限
  以spring security为例

  水平越权管理

  可称之为基于数据的访问控制

  加密算法与随机数

  Web框架安全

  mvc 框架安全

  view 负责用户视图、页面展示工作
  control 负责用户逻辑的实现，接受view传送的数据，并转发给model处理
  model model负责数据处理。

  web框架与csrf 策略

  模板引擎与xss防御

  1. post请求添加token
  • session 绑定token
  • form 表单自动添加token
  • ajax请求中自动添加token
  • 在服务器端对比post参数的token与session的token是否一致

  http header 的管理

  在web框架中，可以对http头进行全局化的处理，因此一些基于http头的安全方案很好实施。

  1. 对http返回头的crlf攻击，所有的head都是key value 键值对。

  location : http://www.a.com
  host:127.0.0.1
  对抗CRLF的方案只需要在value中编码所有的 \r``\n

  2. 类似针对30X返回号的http response ,浏览器将会跳转到location制定的url，攻击者往往利用此类功能实施钓鱼和咋骗。

  HTTP/1.1 302 Moved Temporarily
  Location: http://www.fakesite.com

  管理好跳转地址很重要

  1.如果web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单
  2.另一种解决是控制location的地址，本质还是白名单形式。
  
   
   
  1
  2

  X-frame-options

  https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

  httponly

  https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies

  数据库与sql注入

  还能想到什么

  凡是在web框架可能实现的方案，只要对性能没有太大的损耗，都应该考虑实施。
  spring security为spring mvc的用户提供了很多安全的功能，比如针对url的控制访问。
  加密方法、证书支持、openId支持。但是还是缺乏的xss、csrf等问题的解决方案。
  在设计整体框架安全解决方案时，比较科学的方法是建立威胁模型
  在设计web框架安全解决方案时，还需要保存好安全检查日志，比如发生XSS 攻击时，可以记录下攻击者的ip、时间、useragent、目标url、用户名等信息。

  web框架的自身安全

  关注业界前沿。框架漏洞。

  ##应用层拒绝服务攻击

  PHP安全

  Web Server 配置安全

  安全开发流程

  安全运营

  安全运营

  修补漏洞流程

  安全监控

  入侵检测

  紧急响应流程

  邮件 im 短信