php防止csrf /文件上传/xfs漏洞/非web接口安全

缺乏、安全感 2022-06-11 08:43 243阅读 0赞

一、csrf  
csrf是一种通过有权限用户在不知情的情况下点开了黑客的链接，黑客通过譔用户的权限进行一系利用户不知情的操作。  
一般都是提交form表单。  
在我不知道csrf以前，我判段用户是否登录都是在session存一个标识符，程序进行操作时都会判段此标识符是否存在。可是对csrf这个东西来说我这个安全措施是不存在的，想一想,用户的session是靠什么来进行区分的，靠的是存在cookie中的session\_id,就是说只要黑客知道这个session\_id并且此session还在生命周期内的话，黑客就可以伪造session\_id盗用你的身份,可是有一个前提，黑客要知道你的session\_id，黑客要知道session\_id就是要获取你的cookie,可是黑客又不可能知道用户cookie，这时就可以用csrf了，通过一些手段，让用户访问黑客制作的网站，黑客把网站表单提交给被攻击的网站，如果用户打开这个网站提交了表单，session还活着，ok你就gg了，黑客不能得到你的cookie但是如果是你自己做的操作呢？所以csrf本质上是欺骗用户做一些操作。  
用户可能被欺骗，所以我们需要做一些安全措施，防止出现csrf，黑客伪造表单用户上当点击的情况，既然cookie中的sessionid有可能是假的，那么我们就需要另一个验证，就可以使用token,具体就是在form表单中我们可以添加一个`<input type="hideen" value="token_value" name="token"></input>` 表单上传的时候，我们要判段这个token是否与后端程序的token是否相等 例如这样`if($_SESSION['id']&&$_POST['token']==$_SESSION['token']) { echo '身份认证成功'; }else{ echo '身份认证失败'; }` 那token是否能被黑客知道呢，有可能那就是他得到了你的用户和密码并且按下f12查看token…有了这个手段想要再简单csrf就不存在了。

二、文件上传漏洞  
文件上传漏洞就是黑客上传可执行文件到**web服务器配置目录**，再通过向web服务器请求后执行。  
如何防范呢?  
一、nginx配置上传目录是不允许php文件运行  
存放上传文件的目录直接不能执行php文件件，直接从根源上解决问题。  
至于上传其它的脚本文件，那没有任何意义，因为nginx只配置了php文件给 php-cgi运行，其它的文件都只是一些静态资源文件。客户端访问后，是直接输出文件让客户端进行下载。  
//以下例 子是不允许web服务器根目录下的imagse文件运行Php文件

location ~* ^/images/.*\.(php|php5)$
    {
    deny all;
    }

需要注意必须要在此配置上面

location ~ [^/]\.php(/|$) {
          #fastcgi_pass remote_php_ip:9000;
          fastcgi_pass unix:/dev/shm/php-cgi.sock;
          fastcgi_index index.php;
          include fastcgi.conf;
        }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NzcyMzY2_size_16_color_FFFFFF_t_70]  
三、xfs攻击  
xfs攻击就是一种投机取巧的钓鱼网站，直接使用iframe标签引入我们真实的网站前端址，在外部网页对用户的操作进行监听。不需要写一些钓鱼页面。  
一般的解决方案是。

1.前端判断自身是否处在，顶层窗口。如果不是处在顶层窗口。则把顶层窗口的域名，换成原本网页真实的域名。  
验证是否顶级窗口代码如下

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

但是这样还是不够的。黑客可以扒前端源码，修改源码。在iframe中放入修改后的页面。你的前端验证就失效了。所以需要第二步。

2.后端不允许**非本指定域下**的url发请请求，要把**图一里响应头的星号**，换成**指定域名**或者**服务器ip地址**，如图二所示，这样只有在浏览器中访问指定域下或ip的页面，才可以进行ajax通信，这样黑客就算扒了前端的源码，也不能访问我们的后端接口了。只能iframe引入我们的网站。那么这样，我们的前端判断就一定会被执行了，xfs漏洞也就完美修复了。当然在开发阶段，肯定是要允许\*号的。  
图一  
![在这里插入图片描述][20200611190733632.png]  
图二  
![在这里插入图片描述][20200612043747107.png]

四、非web接口安全  
如果我们的接口不仅是web网页的接口。还要其它接口类型的话。如app接口，第三方开发接口，那么服务器就不能只允许指定ip请求了，而是要使用图一那种\*号，允许所有环境都能发送请求到服务器。那么服务器就不能跟网页一样保证app是官方的app了,但是如果web接口要和app接口共用的话。那么前面的跨域充许列表就要打上星号了。那么就不能保证网页不会被监听了。但是用户不要点钓鱼网站就是没事。认准域名。  
所以app用户最好是从应用市场进行下载正版app，而不是从非安全渠道下载，因为这样有可能会下载到钓鱼app。  
至于第三方开发接口，一般都是开发者。他们都会使用固定的地址，进行访问。也就不存在欺骗行为。  
[xfs参考][xfs]

五、不同端的token共用  
app端和web端的token可以共用，token只是用来识别用户身份的。比如说app扫码登录后，生成一个新的token。生成新的token并不需要产生新的数据，只需要修改当前己存在的token行中的token值和过期时间。修改后返回新给token给网页还有app，他们更新token就行了。

小结：  
为了防止点击链接自动提交表单会自动携带session，所以单纯依靠session是不行的，要一个sesion再上对一个表单token,又因为在本域下才会生成session对应的表单token，生成的表单token会把放在一个隐藏域中，但这是mvc提交表单防止csrf的方式。  
现在，主流的是用ajax提交，用token来鉴别身份，点击的链接非本域，根本获取不到token,所以现在不用考虑这种csrf问题了

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1NzcyMzY2_size_16_color_FFFFFF_t_70]: /images/20220611/b6ed73b4e63a4916a8c2a2e64fee9169.png
[20200611190733632.png]: /images/20220611/22f68ed34fd7451ebd0daad56814e7a0.png
[20200612043747107.png]: /images/20220611/d94cd64d10a8451992c498a5dc8c8ff6.png
[xfs]: https://blog.csdn.net/fageweiketang/article/details/101002718