所以我有一个laravel 5项目,我想用我的攻城工具对我正在使用的测试服务器进行基准测试。
不幸的是,我意识到您无法登录,因为CSRF通常是从提交表单中收到的。围攻中没有形式,因此无法发送此令牌。
我可以看到这在几个方面得到了解决,但我正在寻找可以留在源代码控制中而不会对安全性产生负面影响的东西。什么是一个很好的方法来获得围攻与Laravel合作没有一堆维护或只是懒惰和禁用CSRF?
答案 0 :(得分:1)
两件事:
_token
参数与任何请求显然,相关文档可在代码中的注释中找到,而不是在官方手册中。
您留下的问题是使用_token
变量传递的值。显然,虚假价值正是CSRF应该防范的那种东西。我认为最简单的方法是修改app/Http/Middleware/VerifyCsrfToken.php
以添加一个特殊条件,它将匹配"与预先设定的值相对应。
我要做的第一件事就是在我的.env
文件中创建一个包含我的面部CSRF令牌的变量,例如
FAKE_CSRF_TOKEN=dd0dda7d4b5e92fafd9e5bebfabd7709
然后在App\Http\Middleware\VerifyCsrfToken
(即我上面提到的文件)中,您将覆盖tokensMatch($request)
函数。您可以执行以下操作:
protected function tokensMatch($request)
{
$parent = parent::tokensMatch($request);
$token = $request->input('_token');
return $parent || $token == env('FAKE_CSRF_TOKEN');
}
然后在您的测试中,只需将您的假CSRF令牌值传递为_token
。当然,
永远不应在生产服务器上运行此代码!
如果是我,我可能会创建一个特殊的.env.siege
文件,并在我的测试或登台服务器上设置APP_ENV=siege
。然后我会重写上面的tokensMatch()
函数来做这样的事情:
protected function tokensMatch($request)
{
$parent = parent::tokensMatch($request);
if ('siege' === env('APP_ENV')) {
$token = $request->input('_token');
return $parent || $token == env('FAKE_CSRF_TOKEN');
}
return $parent;
}
这样,即使这个改变的中间件以某种方式进入您的生产服务器,您也可以获得一些额外的保护,防止虚假的CSRF攻击。最终结果是,您可以在不禁用CSRF的情况下,几乎完全像在生产环境中那样对服务器进行压力测试。
所有这一切,我都不知道资源密集型CSRF检查实际上是如何进行的。将CSRF关闭以进行压力测试可能更简单,而不是在此处进行更改。
答案 1 :(得分:0)
所以上述答案几乎就在那里,但它有以下缺陷:
所以我定义了这个函数:
protected function tokensMatch($request)
{
$parent = parent::tokensMatch($request);
//if it isn't an actual token match, and we aren't on production
if (! $parent && 'production' !== env('APP_ENV')) {
//then get the token
$token = $request->input('_token');
$fake = env('FAKE_CSRF_TOKEN');
//and test it versus our fake
//it must actually be defined to work (no blanks)
//generate an actual random string for security!
if(strlen($fake) && $token === $fake)
return true;
}
//otherwise, just return what we normally would
return $parent;
}