粤嵌科技毕业实习Day15

CSRF（跨站请求伪造）

1 、用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2、在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3、用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4、网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5、浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。

网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

CSRF危害
- 攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
- 如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。
CSRF防御
- 验证 HTTP Referer 字段
  - Referer记录了该 HTTP 请求的来源地址。
  - 在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。
- 在请求地址中添加 token 并验证
  - CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie 来通过安全验证。
  - 要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对。
- 在 HTTP 头中自定义属性并验证
  - 这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
  - 然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。
- 添加验证码

csrf的post型利用

进入CSRF（post）页面
点一下提示
选其中一个登录
点击修改个人信息
修改手机和邮箱
提交之前打开burp suite进行抓包
生成Poc恶意表单
复制生成的代码，保存到新建的html文件

修改代码

  <script>
    history.pushState('', '', '/')
    window.onload = function(){
        document.getElementById("submit").click();
    }
  </script>

将post.html文件移动到phpStudy\PHPTutorial\WWW\pikachu\vul\csrf\csrfpost目录下
登录恶意链接http://127.0.0.1/pikachu/vul/csrf/csrfpost/post.html，自动跳转到http://127.0.0.1/
点击Submit request

信息被修改

上传漏洞利用（1）

打开http://127.0.0.1/upload/

Pass-01
1. 新建一个php文件，代码如下：
```
<?php phpinfo(); ?>
```
2. 打开Pass-01
3. 上传abc.php，不被允许
4. F12查看源码，找到限制上传文件类型的代码
5. 修改代码
```
#不调用checkFile()函数
form enctype="multipart/form-data" method="post" onsubmit=""
```
6. 上传成功
7. 右击图片，查看图像信息，获得文件路径
8. 打开该链接
Pass-02
1. 打开Pass-02
2. 上传abc.php
3. 查看提示
4. 通过burp suite来将php文件伪装成符合上传类型的文件。
```
Content-Type: application/octet-stream
#改为
Content-Type: image/jpeg
```
  点击Forward，并关闭Intercept
5. 上传成功
6. 打开图片链接
Pass-04
1. 打开Pass-04
2. 查看提示
3. 查看源码
4. 根据提示，过滤上述后缀后，可以通过上传.htaccess后缀配置文件，修改解析格式。代码如下：
5. 开启burp suite，上传配置文件抓包
6. 去掉filename的文件名，只留尾缀
7. 上传成功
8. 将abc.php改后缀为abc.jpeg并上传，由于上传配置文件修改了服务器的解析格式，所以此时的.jpeg会被解析为php。
9. 打开图片链接http://127.0.0.1/upload/upload/abc.jpeg
Pass-05（在Pass-06）
1. 打开Pass-06
2. 查看提示，有.htaccess后缀限制
3. 查看源码，相比Pass-04，少了转成小写的代码，找到突破点。
4. 将abc.php更改后缀为abc.PHP并上传
5. 可见，上传成功，打开图片链接http://127.0.0.1/upload/upload/202009151838042353.PHP
Pass-06（在Pass-07）
1. 打开Pass-07
2. 查看提示
3. 查看源码，相比Pass-05，少了首尾去空的检测，可作为突破口。
4. 由于在Windows系统无法在首位加空格，所以使用burp suite来修改名字。
5. 上传成功
6. 打开图片链接http://127.0.0.1/upload/upload/202009151848054309.php