问题描述
我想知道Laravel中如何(如果有的话)提供XSS保护.我在文档中找不到任何内容.
I wonder how (if anyhow) is XSS protection provided in Laravel. I couldn't find anything about it in the documentation.
问题
我正在使用雄辩的 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 echo
ing 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 everyInput::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?
推荐答案
实际上-事实并非如此.
Actually - that is not true.
XSS仅由刀片处理的原因是XSS攻击是一个 output 问题.如果将<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).
p.s.在Laravel 5中,默认的{{ }}
将转义所有输出-突出了这一点的重要性.
p.s. In Laravel 5 the default {{ }}
will escape all output - which highlights the importance of this.
这是一个很好的讨论,进一步讨论了为什么应该过滤输出而不是输入: html/XSS转义vs输出
here is a good discussion with further points on why you should filter output, not input: html/XSS escape on input vs output
这篇关于在Laravel中如何以及在何处应用XSS保护?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!