关于PBP的记录以及思考（阅读上古资料）

简单的记录 PBP 内容以及对安全的思考。

这是一个古老的项目，写出来只是为了借鉴一些思路，而不是为了达到什么奇怪的目的。

原论文描述了一些违反同源策略的基于脚本的攻击。通过在受害HTTPS域的上下文中运行恶意脚本，这些攻击可以访问或更改应该由HTTPS保护的敏感数据。¹

具体资料参考点这里。

写给自己看，就随便写了

• 主要的攻击方式有三个：
  1. Embedding Scripts in Error Responses
  2. Redirecting Script Requests to Malicious HTTPS
     Websites
  3. Importing Scripts into HTTPS Contexts through
     “HPIHSL” Pages

三个攻击方式原理

1. Embedding Scripts in Error Responses

• 对于透明的代理，正常工作情况是这样的:

• bad-proxy

不会在图中加注释，所以写在下面，这是iframe的样子
<iframe src=”https://site.example.com” style=”display:none”></iframe>
而发送的脚本将会在的https://site.example.com的安全上下文中运行，绕过同源策略，执行脚本。假设这是一个银行站点，那么攻击者不仅可以窃取用户账户信息，还可以对用户账户进行恶意操作。

2. Redirecting Script Requests to Malicious HTTPS
   Websites
   那个时候的网页会从不同服务器上导入脚本，那么在与https://site.example.com建立好联系后，服务器请求从导入脚本:

• 返回一个302重定向包，转向一个危险的https web站点。

其危害和第一例差不多。
<script src="https://scriptExample.com/foo.js"> </script>

3. Importing Scripts into HTTPS Contexts through

第三个大致也和前面差不了多少。大概就是不安全的引用，从而导致安全上下文去运行恶意脚本。

当时许多web服务器同时提供http和https服务，对敏感网页就https，不重要的就http，来节约资源。

当时，在HTTPS环境下，只要 HPIHSL 网页被引用了，浏览器就会给提示，问你要不要加载，但只有顶级框架是HTTPS时，这个提示才会被触发，当顶层框架是HTTP页面的时候，即使这个页面包含一个加载了 HPIHSL 页面的HTTPS iframe的时候，检测也会被绕过。²

所以，假设在一个商品页面，用户点击一个商品，通过HTTP进行访问时，proxy就可以给出一个iframe请求这个页面，如果页面请求脚本，那么恶意网站就可以返回一个恶意脚本，当这个脚本进入了iframe中，就可以在该网站上下文中运行， 覆盖页面上的按钮之类的，从而获取用户信息…

画图真难，不画了

静态HTML网页的PBP利用

• 通过与浏览器去通信的HTTPS服务器的可信证书来代理认证。
• 代理可以作为登录用户来取信HTTP。

时光飞逝，有空再写