火狐扩展NS-NoScript-ABE-应用边界执行模块-江3

关于Firefox的技巧的文档：侧边栏视图、缩略图视图、by江3如此多娇 //参考 //简介 //参数 //策略格式： //站点格式： //HTTP类型： //动作： //举例 //提示/错误记录： //参考 //什么是ABE？参考， //ABE Rules .pdf，官方最新版的标准 //ABE的WEB开发者须知， //论坛-ABE， //NS参数与设置-江3， //NS杂记-江3， // 一些有必要通过ABE过滤的Sites， //CSRF_百度百科， //csrf 攻击 - Google 搜索， //CSRF 攻击的应对之道， //简介 //ABE是内置防火墙式的功能，可以用来防御CSRF、DNS重绑定等几乎所有跨站攻击，支持系统和用户自定义规则， //ABE与CSP相似，并不冲突，两者可以互补 //ABE与Chrome的Site Isolation机制相似，可以模仿， 一些NS目前有效防御的攻击XSS, CSRF or ClickJacking等攻击有一个基础/前提：缺乏在Web应用级别上有效合理的隔离； 因为Web起初并未被预见会成为一个应用平台，所以缺少了一些必备的保护Web应用安全的特点。 事实上，“Web应用”这个概念都是很难被界定的，它的边界也是模糊的，特别是在现代这个多媒体和混合式网络时代，跨多域的Web应用泛滥 ABE的背后的思想是就是加固“NS已有效提供的”“面向Web应用的”保护，通过提供浏览器内置的防火墙试组件， 该“防火墙”用来自定义和守护用户相关的敏感Web应用（Webmail、在线银行等）的边界， 该“防火墙”的规则/策略可由用户自己、Web开发者/管理员、可信的第三方提供 内置于浏览器，ABE模块可以有效的利用它的特权位置来强制划定Web应用边界，因为它始终知道真正的HTTP请求源，而不是可能丢失或伪造的（即使出于隐私保护）HTTP Referer Header 但未来Origin HTTP header变得广泛使用并可靠，ABE会被升级为外部过滤代理。 //参数 user_pref("noscript.ABE.enabled", false);//开启ABE？ user_pref("noscript.ABE.siteEnabled", true);//ABE允许网站推送自己的规则集？ //user_pref("noscript.asyncNetworking", true);//ABE预拦截HTTP请求与DNS解析异步进行？默认true //Asyncrhonous networking in Gecko >= 1.9 for ABE preflight requests and DNS checks (can be turned off by noscript.asyncNetworking about:config preference) ======================================================= //Site规则集： 通过执行特定的的动作（Actions）完成的，这些动作本质上是修改或拦截HTTP请求。这些动作采用可读的语法表示为4种规则集（ruleset） ABE规则集匹配时是有一定顺序的：SYSTEM > USER > Subsription > Site 1 SYSTEM：系统规则集，优先级最高，默认自带一个LOCALrodeo策略，用来保护”私有网络” 2 USER：用户定义规则集，优先级次之 3 Subscription：订阅的在线规则集（由可信第三方提供），每日更新一次 4 Site：网站定义的自己的ABE规则集（rules.abe）, 在HTTPS请求之前加载，并缓存一天，或者更久（如果与缓存相关的Headers有要求） Site定义的规则集必须保存在跟域名下rules.abe文件中，并且支持HTTPS，且该文件中的Site行必须与该域名相同才被视为有效。 Rules.abe的具体规则语法与上面的相同！或者叫做： //Built-in：形如“SYSTEM”的规则集，是自带的，提供针对普遍性的威胁，不要轻易改动 //User-defined like the “USER” ruleset, 由用户来自定义规则 //Subscription-provided, 来自第三方中立者提供的规则集 //Site-specific, 网站提供的，用来保护自己的网页 Web开发者的Opt-in方式必须满足2个条件：SSL+rules.abe文件， HTTPS://domain.com/rules.abe Q：为啥要使用文件-rules.abe而不用Header？ A：因为CSRF需要在HTTP请求到达服务器之前被拦截：我们根本不能等到一个反应头，参考Site Isolation模型-江3， 每个规则集都包含一系列针对不同HTTP请求的不同动作，其中不同的HTTP请求通过3个部分定义： 目标站点、请求站点、HTTP类型；这3个部分都可以缺省，默认表示为ALL或者from ALL 参考Chrome的Site Isolation 论文 政研论文下载论文大学下载论文大学下载关于长拳的论文浙大论文封面下载 中的3种Opt-in方法的比较 参考noscript.net/abe/web-authors， //策略格式： # 注释 Site 目标站点a Actions1 HTTP类型 请求站点x Actions2 HTTP类型 请求站点y ... Site 目标站点b Actions1 HTTP类型 请求站点z Actions2 HTTP类型 请求站点w ... 请求站点由关键字from定义，若省略则缺省表示为from ALL或者ALL 目标站点由关键字 Site定义 //站点格式： ● 正则表达式，如^http?://some\.abc\.com/.* ● 域名表达式，如www.abc.com ● 严格域名表达式，如http://www.abc.com ● 星表达式，如*.abc.com（不包括abc.com） ● 点表达式，表示星表达式+二级域名，如 .abc.com （包括abc.com） ● 伪表达式：ALL，LOCAL，SELF，SELF+，SELF++ ○ ALL 所有URI，缺省值 ○ LOCAL 本地LAN资源 ○ SELF 严格网址，包括相同的协议、全域名、端口 ○ SELF+ 全域名，相同的协议、主域名、端口 ○ SELF++ 二级域名，相同的协议、顶级域名、端口 三个SELF都仅限于表示请求站点，后面不需要在赘加其他URI，若加了，表示2个不同请求站点， 比如，Accept from SELF+ .abc.com 表示接受任意来自其自身主域名(www.sites.com)及abc.com的请求 如果想把某个静态IP当作LOCAL处理（也就是允许某个静态IP访问本地资源），有2个办法： 把这个IP放在 Accept from LOCAL 后面，比如，Accept from LOCAL 121.49.88.1 或者把121.49.88.1加入noscript.ABE.localExtras 参数中，多个值用空格隔开 //HTTP类型： //ABE支持Mozilla's XPCOM nsIContentPolicy 定义的请求类型 “真HTTP 请求方式”（GET，POST，HEAD，PUT，DELETE，TRACE，OPTIONS）和 “伪HTTP 请求类型”（ALL(*)，SUB，INC），若省略则缺省表示ALL，及所有HTTP类型 All 或 * 所有HTTP类型的请求，缺省值 SUB 仅限于frame或者iframe内显示的子文档的请求，SUB=INC，SUB伪类型是在noscript 新增 X-Frame-Options 和ClearClick两个功能之前用来反点击劫持的手段～ INC （或INCLUSION）子 内容 财务内部控制制度的内容财务内部控制制度的内容人员招聘与配置的内容项目成本控制的内容消防安全演练内容 集合，包括SCRIPT，CSS，IFRAME，OBJ（插件对象），OBJSUB（插件对象请求的子内容）， SUBDOC，XBL，PING，XHR,DTD，MEDIA（HTML5 video and audio），FONT，OTHER; 这些包含的内容使用逗号隔开，如INC (SCRIPT, HEAD) //动作： ● Accept 接受：允许请求 ● Deny 拒绝：拦截请求 ● Anon（或Anonymize，或Logout）匿名：剔除掉授权和Cookie头信息，并把GET、HEAD、OPTIONS HTTP请求方式变成GET方式，先移除需要上传的数据再发送请求，参考NS的 Anti-XSS-江3， ● Sandbox 沙盒：照旧发送原请求，只是在执行页面时禁用JS和其他活动内容（如插件等嵌入对象），参考FF混合内容-江3， 这里的沙盒与杀毒软件的沙盒有区别，ABE的沙盒是提前拦截可执行的内容（JS、嵌入对象等），并未真正运行它们， 而杀软的沙盒是采用虚拟系统环境来运行可执行的内容，Chrome浏览器内置的沙盒应该是类似后者的， 然而，在这个 帖 行书字帖3500常用字图幼儿笔画描红字帖田字格空白字帖簪花小楷字帖乐善堂 子中Giorgio就已经告诉了我们，现在Chrome这种沙盒的作用已经很小了，充其量是防止网页上的恶意代码访问本机资源， 优点是把浏览器应用与本机环境隔离，但是却不能实现WEB应用的彼此隔离，这就是ABE更厉害的地方 动作的匹配安装从上倒下优先级递减，所以要把动作范围小的放在上面，动作范围大的放在下面 比如，Accept from www.baidu.com 要放在 Deny from .baidu.com上面 多个”实HTTP方式”可以并列在一个动作下，比如Accept GET SUB 这4个动作细分3类：包容类（Accept）、非包容非致命类（Sandbox、Anon）、致命类（Deny） 动作匹配时，遇到包容类、非包容非致命类时，继续向下匹配，遇到致命类就杀死匹配进程～ Site www.AD.com # 目标站点 Accept SELF *.google.com # 仅放行 www.AD.com <<< www.AD.com 和 www.AD.com <<< *.google.com Accept GET POST SELF++ # 多个”实HTTP方式”可以并列 Anon # 匿名（却掉授权和cookie信息） Deny INC(SCRIPT) from www.abc.com # 拦截JS Deny //举例 # 拦截来自非自身站点的子文件的请求 Site * Accept INCLUSION from SELF Deny INCLUSION # 接受来自LOCAL对LOCAL资源的HTTP请求，拦截其他（也就是互联网）对LOCAL资源的HTTP请求，防御DNS重绑定-江3， Site LOCAL Accept LOCAL Deny # 去掉来自*.abc.com以外的站点的请求中的授权信息（授权和cookie），参考CSRF-江3， Site *.abc.com Accept GET POST from SELF++ Anon # 强迫facebook的脚本和对象仅在facebook网页内 Site .facebook.com .fbcdn.net Accept from .facebook.com .fbcdn.net Deny INCLUSION (SCRIPT, OBJ, SUBDOC) # 关闭Google自动完成功能 Site ^https?://clients\d\.google\.com/complete/search Deny ABE模块与“内容权限”模块相互独立，ABE基于HTTP请求，如果NoScript“内容权限”模块拦截了某个黑名单中的网站， 那么该网站内地如下内容的HTTP请求都不会生成，那么ABE模块也就不能接管、修改对该站点的如下内容的HTTP请求了 user_pref("noscript.forbidBookmarklets", false);//书签脚本，允许 user_pref("noscript.forbidExtProtSubdocs", true);//默认true user_pref("noscript.forbidFlash", false);//Flash，用自带的CTP，默认true user_pref("noscript.forbidFonts",true);//字体 user_pref("noscript.forbidFrames", false);//默认false user_pref("noscript.forbidIFrames", false);//默认false user_pref("noscript.forbidJava", true);//默认true user_pref("noscript.forbidMedia", true);//默认true，HTML 5 media user_pref("noscript.forbidMetaRefresh", false);//默认false user_pref("noscript.forbidMetaRefresh.notify", true);//默认true，提示 user_pref("noscript.forbidMetaRefresh.remember", false);//默认false user_pref("noscript.forbidMixedFrames", true);//默认true user_pref("noscript.forbidPlugins", true);//其他插件 user_pref("noscript.forbidSilverlight", true);//Silverlight user_pref("noscript.forbidWebGL", true);//默认false 所以，如果想通过ABE来细化管理某个网站的上面这些内容（相当于ABE模块中的SUB或者INC类型），首先要在NoScript菜单中允许， 比如，若要禁止除*.google.com外一切网站对doubleclick网站上的JS脚本的调用，需要首先白doubleclick允许为白名单，再在ABE的USER中加入 Site *.doubleclick.net Accept from *.google.com Deny //提示/错误记录： ABE规则被触发时，FF的错误扩展台中会显示如下的记录， 仅当触发的动作是Deny，且拦截的请求针对顶层窗口-Top-level Window时，才会显示提示条 MATCHING_PATTERN: ACTION on {MATCHING_SITE << ORIGIN1[, ORIGIN2, ...], ORIGINAL_ORIGIN - REQUEST_TYPE} MATCHING_PATTERN 匹配的Site规则 ACTION 相应的ABE动作 (Deny, Anonymize...) MATCHING_SITE 匹配的请求的实际URI ORIGIN1, ORIGIN2 等等，实际的请求URI链 (重定向时会更多...), 但是 ORIGINAL_ORIGIN 始终表示触发请求的URI REQUEST_TYPE 请求的类型 (document, subdocument, image 等) Mozilla's XPCOM nsIContentPolicy接口中定义的 [ABE] Deny on {POST https://sso.from.mydomain.com <<< https://wikisite.we.use.com} SYSTEM rule: Site LOCAL Accept from LOCAL Deny ====================================