在 Laravel 中如何以及在何处应用 XSS 保护?

2022-01-08 00:00:00 php laravel laravel-4 xss

我想知道 Laravel 如何(如果有的话)提供 XSS 保护.我在文档中找不到任何关于它的内容.

I wonder how (if anyhow) is XSS protection provided in Laravel. I couldn't find anything about it in the documentation.

问题

我正在使用 Eloquent 的 create() 方法将数据插入数据库($fillable/$guarded 属性在模型中设置).事实证明，我可以在任何形式的文本输入中自由地输入这样的内容:

I am using Eloquent's create() method to insert data into database ($fillable/$guarded properties are set in the models). As it turns out, I can freely put something like this in any form's text input:

<script>alert('Hacking Sony in 3...2...')</script>

并且该值将被插入到数据库中.然后，当 echo 执行它时 - 会显示警报.

and the value will be inserted in the database. Then, when echoing it - the alert is shown.

可能的解决方案

现在，Laravel 是一个非常好的框架，所以我认为 必须 有一些东西可以防止 XSS 开箱即用.但是，我不知道那是什么.

Now, Laravel is a really nice framework, so I would assume there must be something to prevent XSS out of the box. However, I can't find out what that is.

如果我错了，处理问题的最佳方法是什么?

If I'm wrong, what is the optimal way to handle the issue?

  • 我是否使用花哨的正则表达式验证来禁止特定字符?
  • 我是否在我使用的每个 Input::get() 上都使用 mysql_real_escape_string()?
  • 我要strip_tags()吗?
  • Do I use fancy regex validation to disallow specific characters?
  • Do I use mysql_real_escape_string() on every Input::get() I use?
  • Do I strip_tags()?

视图级转义是不够的

我知道我可以使用 Blade 的 三重大括号在视图中转义字符串，但这不是重点.对我来说首先不要让那些鬼鬼祟祟的混蛋进入数据库更有意义.

I know I can use Blade's triple curly brackets to escape strings in the views, that's not the point, though. Makes much more sense to me not to let those sneaky bastards into the database in the first place.

有人遇到过这个问题吗?

Anyone faced this problem already?

推荐答案

对我来说首先不要让那些鬼鬼祟祟的混蛋进入数据库更有意义.

Makes much more sense to me not to let those sneaky bastards into the database in the first place.

实际上 - 这不是真的.

Actually - that is not true.

XSS 仅由刀片处理的原因是 XSS 攻击是一个输出问题.如果您将 <script>alert('Hacking Sony in 3...2...')</script> 存储在数据库中，则没有安全风险 - 它只是文本 - 它没有任何意义.

The reason that XSS is only handled by blade is that XSS attacks are an output problem. There is no security risk if you store <script>alert('Hacking Sony in 3...2...')</script> in your database - it is just text - it doesnt mean anything.

但是在 HTML 输出的上下文中 - 那么文本是有意义的，因此应该进行过滤.

But in the context of HTML output - then the text has a meaning, and therefore that is where the filtering should occur.

另外 - XSS 攻击可能是反射攻击，其中显示的数据不是来自数据库，而是来自另一个来源.即上传的文件、网址等.如果您未能过滤所有各种输入位置 - 您可能会丢失某些内容.

Also - it is possible that XSS attack could be a reflected attack, where the displayed data is not coming from the database, but from another source. i.e. an uploaded file, url etc. If you fail to filter all the various input locations - you run a risk of missing something.

Laravel 鼓励您转义 all 输出，无论它来自哪里.由于特定原因，您应该只显式显示未过滤的数据 - 并且只有在您确定数据来自受信任的来源(即来自您自己的代码，而不是来自用户输入)的情况下.

Laravel encourages you to escape all output, regardless where it came from. You should only explicitly display non-filtered data due to a specific reason - and only if you are sure the data is from a trusted source (i.e. from your own code, never from user input).

附言在 Laravel 5 中，默认的 {{ }} 将转义所有输出 - 这突出了这一点的重要性.

p.s. In Laravel 5 the default {{ }} will escape all output - which highlights the importance of this.

这是一个很好的讨论，进一步说明了为什么应该过滤输出，而不是输入:html/XSS escape on input vs输出

here is a good discussion with further points on why you should filter output, not input: html/XSS escape on input vs output

相关文章