项目安全简谈

最新推荐文章于 2023-05-23 11:56:24 发布

millet109

最新推荐文章于 2023-05-23 11:56:24 发布

阅读量490

点赞数

分类专栏： PHP Laravel 文章标签： PHP项目如何保证安全性 laravel保证项目安全性预防SQL注入预防XSS漏洞预防CSRF跨站请求漏洞

本文链接：https://blog.csdn.net/gu_wen_jie/article/details/109259013

版权

PHP 同时被 2 个专栏收录

40 篇文章 0 订阅

订阅专栏

Laravel

23 篇文章 3 订阅

订阅专栏

文章目录

1.SQL注入漏洞
2.XSS漏洞
3.CSRF 跨站请求伪造漏洞
4.逻辑漏洞

前段时间接手了一个老项目的维护，发现了其中一些不规范的写法，有些已经对于整个项目的安全留下了潜在的隐患。今天就来说一下在PHP项目中几个常见的漏洞类型（以下代码演示框架为Laravel7）。

1.SQL注入漏洞

SQL注入算是一种最早就存在的，并且是非常流行的漏洞之一，危险性也同他的年龄成正比。

原理就是：将未经过滤的用户输入拼接到 SQL 语句中。

$product = DB::select("select * from products where id = '".$_GET['id']."'");

这个时候用户提交的id如果是 1 and 1 = 2，那么最终被执行的 SQL 就是:

select * from products where id = 1 and 1 = 2

很明显这个 SQL 查出来的结果必然为空，那么页面就会显示该商品不存在。
但仅仅是这样感觉好像没有什么危害，那这个时候攻击者提交的id参数变成了：

1 and exists (select * from admins where name = 'admin')

执行的 SQL 就变成了：

select * from products where id = 1 and exists (select * from admins where name = 'admin')

假如攻击者看到了正常的商品页面，那就说明这个网站存在一个名为 admin的管理员。接着请求：

1 and exists (select * from admins where name = 'admin' and len(password) = 32)

这样根据页面是否展示商品信息就能判断出 admin这个管理员在数据库中的密码是否为 32位。这样就可以一步一步来验证出管理员的密码。现在有很多自动化的 SQL注入软件，可以用很短的时间就把管理员的数据查询出来。
在 PHP 的项目里要避免 SQL 注入需要两个条件：

1.使用 Prepared Statement + 参数绑定
2.绝对不手动拼接 SQL
Prepared Statement 简单来说就是把要执行的 SQL 与 SQL 里的参数分开，还是以上面的查询商品为例，Prepared Statement 就是：

select * from products where id = ?

然后再传入参数：1 and 1 = 1，这个时候数据库会严格地去查找对应 ID = 1 and 1 = 1的商品，而不是把 and 1 = 1当做查询条件，所以即使 1 = 1成立，数据库仍然返回空。

2.XSS漏洞

XSS漏洞的原理就是：

将未经过滤的用户输入原样输出到网页中

例如用户把以下内容作为收货地址提交：

<script>alert(123)</script>

而如果我们在后台原样输出这个收货地址，就会触发网页 JS 代码，弹出一个 123 的提示框。
在我们的项目中，可能会有多处用户输入会保存到数据库中，并在之后输出到了页面中,比如：

用户姓名
商品评价
收货地址

这些字段我们并没有做任何的过滤，现在核心是看看我们是否原样输出。
在 Laravel 中要输出文本有两种方式：{{ $str }} 和 {!! $str !!}，前者等同于 echo htmlspecialchars($str)而后者则是 echo $str，htmlspecialchars()函数默认会把 <>&"这个 4 个字符分别转义成 <、&lgt;、&和 "，因此我们只要保证我们一直在用 {{ }}来输出就没有问题。

3.CSRF 跨站请求伪造漏洞

CSRF 漏洞的危害程度不低于 XSS，但是远没有 XSS 那样出名。
原理就是：

利用用户的身份认证信息，在用户当前已登录的 Web 应用程序上执行非用户本意的操作。

举个例子，假如一个论坛:xxx.com，退出登录的请求方式和路由是 Get /logout，那么恶意用户只要在某个帖子里插入一张图片，图片的 SRC 是 https://xxx.com/logout，那么任何访问这个帖子的用户都会被强制退出，因为浏览器在请求这个 URL 之前并不知道这个 URL 是不是一张真的图片，那么就会带着当前用户的 Cookie 用 Get 方式去请求这个退出页面，也就导致当前用户被强制退出。
那么是不是把请求方式改成 Post 就没有问题了呢？确实无法通过图片的方式来触发，但是恶意用户可以在其他站点构造一个页面，内容如下：

<form action="https://xxx.com/logout" method="post" id="form"></form>
<script>document.gentElementById('form').submit();</script>

然后恶意用户诱导正常的用户去访问这个页面（比如这个恶意用户在 LC 的头条里分享了这个页面并取了一个很有诱惑的标题《教你如何实现一个千万并发的网站》，相信会有很多人访问），那么访问了这个页面的用户就会被强制退出 LC。
如果一个银行网站的转账功能有 CSRF 漏洞，那么恶意用户就可以通过 CSRF 漏洞来盗取其他用户的资金。
根据上面所说的原理，不难发现要避免 CSRF 攻击需要两个条件：