str_replace('<') 可以保护我们免受用户注入代码的影响吗?

发布于 2024-12-09 11:09:00 字数 209 浏览 0 评论 0 原文

好的,我有一些用户输入,我做了一个 echo str_replace('<', '&lt;', str_replace('&','&',$_POST['input'] ));

我想知道,用户是否可以破坏此过滤器?

最初我认为这个脚本非常安全,但在阅读了一些有关 php、字符集和安全性的文章后,我开始怀疑它的稳健性。

Ok so I have some user input and i do a echo str_replace('<', '<', str_replace('&','&',$_POST['input']));

I'm wondering, is there anyway the user could break this filter?

Initially I'd thought this script is pretty bullet-proof, but I began to suspect its robustness after reading some article on php, character sets, and security.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

一刻暧昧 2024-12-16 11:09:00

这取决于输入的最终位置。

例如,如果在某个时候您最终得到一个像这样构造(很差)的模板...

<a href="<?php echo $somevar; ?>">a link</a>

那么有人可以通过简单地使用以下输入来注入代码:

javascript:do_whatever()

即使输出通常不会回显到 href 字段,像这样的东西...

<a title="<?php echo $somevar; ?>" href="http://www.google.com">Google</a>

如果输入是...仍然可能容易受到攻击...

" href="javascript:do_whatever()

所以基本上...过滤器必须对其使用的上下文敏感。常用的函数是 htmlspecialchars() ,它处理很多常见的案例。

It depends on where that input ends up.

For instance, if at some point you wind up with a template that is (poorly) constructed like this...

<a href="<?php echo $somevar; ?>">a link</a>

Then someone could inject code by simply using the following input:

javascript:do_whatever()

Even if the output isn't normally echoed into the href field, something like this...

<a title="<?php echo $somevar; ?>" href="http://www.google.com">Google</a>

could still be vulnerable if the input is...

" href="javascript:do_whatever()

So basically... filters have to be sensitive to the contexts in which they are being used. A commonly used function is htmlspecialchars() which handles a lot of the common cases.

心作怪 2024-12-16 11:09:00

是的。在一些多字节字符集中(UTF-7 是最值得注意的)还有其他字符可以在 html 中用作尖括号。

此外,这不会保护 html 属性,因为它们可以通过使用引号注入 javascript。因此,您所做的事情是:

<input value="<?= $replaced_value ?>" />

他们可以传递值

" onclick="alert(5)" x="

,这将导致

<input value="" onclick="alert(5)" x="" />

如果您不使用正确的方法,那么有人可以通过多种不同的方式利用您的代码。使用 OWASP 的编码库 Reform 您可以对您需要的所有内容进行编码。

最重要的是,除非绝对必要,否则在任何情况下都不应该推出自己的安全代码。无论是从效率的角度还是从责任的角度来看,第三方库都是您能做的最好的事情,其中​​多个安全专家在该问题上花费了大量时间。

Yes. In some multibyte character sets (UTF-7 being the most notable) there are other characters that can be used as angle brackets in html.

In addition, that won't protect html attributes, since they can inject javascript by using a quotation. So, where you'd doing:

<input value="<?= $replaced_value ?>" />

they can pass the value

" onclick="alert(5)" x="

which will result in

<input value="" onclick="alert(5)" x="" />

There are many different ways that someone can exploit your code if you don't use the right methods. Using OWASP's encoding library Reform you can encode everything you need to.

The bottom line is that you shouldn't ever, under any circumstances, roll your own security code unless you absolutely have to. 3rd party libraries where multiple security experts have spent a large amount of time on the problem is the best thing you can do, both from an efficiency standpoint and a liability standpoint.

肩上的翅膀 2024-12-16 11:09:00

快速浏览一下 htmlspecialchars() 函数 :

执行的翻译是:

<前><代码>'&' (& 符号)变为“&”
'"'(双引号)变为 '"'当 ENT_NOQUOTES 未设置时。
“'”(单引号)变为 '''仅当设置了 ENT_QUOTES 时。
'<' (小于)变为“<”
'>' (大于)变为“>”

因此,最重要的是 > 在 HTML 中无效,除非它是标记的一部分,但浏览器可能会忽略这一点。

如果您将其放入某些引号中,则需要引号转义,例如:

echo "<input name='x' value='" . htmlspecialchars($input) . "'/>";

也就是说,为什么不直接使用 htmlspecialchars

Taking a quick look at the htmlspecialchars() function:

The translations performed are:

'&' (ampersand) becomes '&'
'"' (double quote) becomes '"' when ENT_NOQUOTES is not set.
"'" (single quote) becomes ''' only when ENT_QUOTES is set.
'<' (less than) becomes '<'
'>' (greater than) becomes '>'

So the big one is that > isn't valid in HTML unless it's part of a tag, but presumably browsers will ignore this.

The quote escaping is needed if you're putting this inside some quotes, like:

echo "<input name='x' value='" . htmlspecialchars($input) . "'/>";

That said, why not just use htmlspecialchars?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文