如果您已经参与过 laravel 项目,您肯定已经注意到该框架如何提供各种有用的开发工具。但是,你有没有想过你是否可能错过了一个错误?在使用这些工具时,您是否最终错过了一些简单但重要的细节来确保系统的安全?
在本文中,我将向您展示一些“简单”的错误,但非常常见且易于解决。
进行安全部署?
在互联网上公开项目时,需要注意 .env 文件将进入生产/审批环境或任何部署场景,如 app_env 和 app_debug密钥可能会在这些环境中打开可能的漏洞。
这些键有什么用呢?
- app_env = 指示应用程序当前环境的标志,它可以接收诸如“本地”、“生产”、“暂存”、“测试”等值
- app_debug = 指示当前环境是否处于调试模式的标志,它可以接收一个布尔值。
此配置仅用于开发环境。
app_env=local app_debug=true
将此配置用于生产环境。
app_env=production app_debug=false
在生产中不使用正确的配置会出现什么问题?
将 laravel 应用程序保留在调试模式下可以显示详细的错误消息,这对于开发来说非常有用,但对于其他环境来说却很糟糕,因为它可以显示以下敏感信息:
- 代码片段。
- php 和 laravel 版本。 (可用于利用版本中已知的安全漏洞)
- 用户信息和密钥。
- 数据库密码。
- app_env 密钥状态。
指示环境值为“local”的密钥可以打开各种漏洞,范围从无需登录即可打开的 telescope,到使用 app_env 确定流量的某些系统功能的行为。例如,使用外部 api 的以下配置:
'api_service' => [ 'key' => env('app_env') === 'production' ? env('api_key_prod') : env('api_key_dev') ]
验证输入?
每个开发者在一生中的某个时刻都一定听过“不要信任用户”,在本文中您将看到另一个这样想的理由。
让我们想象一下以下场景,您在电子商务中有一个产品编辑表单,仅适用于非经理员工,但该表单没有可用的值字段,以不允许非经理员工进行更改. 已授权。
这是桌子产品
id | valor | nome | quantidade | codigo | setor_id |
---|---|---|---|---|---|
1 | 100 | panela | 4 | pan10323 | 3 |
... | ... | ... | ... | ... | ... |
这些是您的表单请求
的验证规则
public function rules(): array { return [ 'nome' => 'string|max:255', 'quantidade' => 'integer|min:0', 'codigo' => 'string|max:255|unique:itens,codigo', 'setor_id' => 'exists:setores,id', ]; }
这是您的控制器中使用的函数:
public function funcionarioupdateitem(updateitemrequest $request, $id) { $item = item::findorfail($id); $result = $item->update($request->all()); return response()->json(['sucesso' => $result], 200); }
您已检查并且数据已正确更新,验证成功并且一切似乎都按顺序进行。然而,这个流程有一个很大的缺陷:我们正在考虑表单只会发送请求中的四个字段。
但是,如果恶意用户手动更改页面的 html 以添加 value 字段,会发生什么情况?或者,如果攻击者甚至通过 postman 等 api 平台发送请求,并在请求中包含 value 字段,该怎么办?
假设恶意用户将以下数据发送到路由:
{ valor: 1, nome: 'panela barata', }
您的表产品将包含以下记录:
id | valor | nome | quantidade | codigo | setor_id |
---|---|---|---|---|---|
1 | 1 | panela barata | 4 | pan10323 | 3 |
... | ... | ... | ... | ... | ... |
现在原价 100 r$ 的产品最终只需 r$ 1,问题是如何从请求中提取数据。
错了❌
$request->all();
- 这就是所有请求数据的返回方式。
对✅
$request->validated();
- 这样,仅返回请求中的有效数据。
如果示例中的 controller 使用正确的方式接收数据,则相同的恶意负载示例将导致以下记录:
id | valor | nome | quantidade | codigo | setor_id |
---|---|---|---|---|---|
1 | 100 | panela barata | 4 | pan10323 | 3 |
... | ... | ... | ... | ... | ... |
从而避免任何意外数据!
避免 sql 注入 ?
当我们谈论 sql 注入时,我们谈论的是使攻击者有可能在应用程序数据库中执行不需要的和不可预见的 sql 命令的漏洞。
示例:
假设您的系统具有执行以下查询的用户搜索功能。
$query = "select * from users where username = '$username'";
如果用户输入 admin',则认为 $user 变量是由执行搜索的用户给出的;删除表用户; -- 将生成以下查询。
select * from users where username = 'admin'; drop table users; --'
生成的查询是恶意的,会导致整个用户表崩溃,对应用程序的完整性造成巨大损害。
如何保护我的应用程序?
laravel 自己的 eloquent orm 和查询生成器具有强大的保护功能,可以防止恶意输入和查询的潜在危险字符。 但是,在使用任何接受原始查询的方法时必须小心,因为如果滥用这些方法,可能会导致注入恶意输入。
示例:
错了❌
$email = $request->email; db::select("select * from users where email = '" . $email . "'");
在这种情况下,我们通过字符串连接直接将用户输入传递给查询,这不会执行任何参数清理。
对✅
$email = $request->email; user::where('email', $email)->get();
通过这种方式,我们使用 laravel 的原生保护,将输入作为参数传递给将构建查询的函数。
对✅
$email = $request->email; db::select("select * from users where email = ?", [$mail]);
假设您确实需要使用接受原始查询的方法,请通过绑定传递参数。这样,laravel 将防止输入被解释为 sql 代码并保证查询安全。
别忘了⚠
始终在 laravel 中使用原始 sql 进行查询时使用绑定。
使用速率限制?
限制在给定时间内可以发出的请求数量对于保护您的应用程序免受某些类型的攻击至关重要,例如:
- 暴力破解: 通过使用可能的组合发出大量请求来尝试“猜测”密码和凭据,直到成功。
- ddos: 尝试在短时间内通过大量请求使服务器超载。
建议考虑将此保护添加到与身份验证形式相关的路由或使用私有随机令牌的路由。
如何申请?
在 appserviceprovider.php 文件中,您将在启动函数中创建 ratelimiter:
ratelimiter::for('default-limiter', function (request $request) { return limit::perminute(10); });
好的,现在定义了限制器,我们将应用我们的敏感路线。
route::middleware('throttle:default-limiter')->group(function () { route::get('/private/{token}', [tokencontroller::class, 'privatething']); });
考虑该路由接收一个随机生成的令牌来显示其承载者的私人数据。这样我们就设置了每分钟 10 个请求的限制,避免了可能的暴力攻击来猜测秘密令牌,从而获得对私人信息的访问权限。
仍然可以定义具体的、个性化的限制规则,例如通过ip:
RateLimiter::for('default-limiter', function (Request $request) { return Limit::perMinute(10)->by($request->ip()); });
这些限制通常基于 ip 和登录用户,对于防止不同类型的攻击非常重要,包括使用不同 ip 进行的 ddos 攻击。永远记住创建强大的限制规则!
如果您已经使用现成的 laravel 身份验证套件,例如 breeze 或 jetstream,那么恭喜您!您的登录路线已受到速率限制的保护。
注意⚠
设置限制时请密切注意,以免影响用户正常使用您的系统。如果路由的请求流量较大,建议使用 laravel 11 的每秒速率限制功能。
结论
我们在开发过程中必须始终密切关注安全问题,因为小的决定或看似微不足道的错误可能会在未来导致大问题。
非常感谢您阅读本文! ❤
以上就是Simples Mudanças, Grandes Impactos: Como Fortalecer a Segurança da Sua Aplicação Laravel的详细内容,更多请关注php中文网其它相关文章!