如何防止跨站点脚本攻击?

发布于 2024-09-01 10:39:28 字数 82 浏览 4 评论 0原文

我正在使用 php、mysql 和 smarty,并且用户可以在其中放置注释等。在插入数据库进行 SQL 注入之前,我已经转义了字符。我还需要做什么?

I am using php, mysql with smarty and I places where users can put comments and etc. I've already escaped characters before inserting into database for SQL Injection. What else do I need to do?

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

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

发布评论

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

评论(5

灼痛 2024-09-08 10:39:29

XSS 主要是关于 HTML 转义(*)。每当您获取一串纯文本并将其放入 HTML 页面时,无论该文本是来自数据库、直接来自用户输入、来自文件还是完全来自其他地方,您都需要对其进行转义。

最小的 HTML 转义是将所有 & 符号转换为 & 并将所有 < 符号转换为 & lt;。当您将某些内容放入属性值时,您还需要转义用于分隔属性的引号字符,通常是 ""。始终转义双引号(" 和单引号撇号 ')没有坏处,有些人也会转义 > 到 >,尽管这只是 XHTML 中的一个特殊情况所必需的,

任何优秀的面向 Web 的语言都应该提供一个函数来为您执行此操作,例如在 PHP 中,它是 htmlspecialchars():

<p> Hello, <?php htmlspecialchars($name); ?>! </p>

在 Smarty 模板中,它是 escape 修饰符:

<p> Hello, {$name|escape:'html'}! </p>

实际上,因为 95% 的情况下您都需要 HTML 转义(想要允许原始 HTML 标记的情况相对较少)包含在内),这应该是默认的。较新的模板语言已经了解到,选择加入 HTML 转义是一个巨大的错误,会导致无尽的 XSS 漏洞,因此默认情况下,

您可以使 Smarty 表现得像这样 。将 默认修饰符 更改为 html 。 (不要按照他们的建议使用 htmlall ,除非您真的知道自己在做什么,否则它可能会搞砸所有非 ASCII 字符。)

无论如何确实如此,请不要陷入常见的 PHP 错误,即在处理或放入数据库之前对输入上的 HTML 进行 HTML 转义或“清理”。这是执行输出级编码的错误位置,并且会给您带来各种问题。如果您想验证您的输入以确保它是特定应用程序所期望的,那么很好,但在此阶段清除或转义“特殊”字符是不合适的。

*:当 (a) 您实际上想要允许用户发布 HTML 时,就会出现 XSS 的其他方面,在这种情况下,您必须将其缩减为可接受的元素和属性,这通常是一个复杂的过程是由像 HTML Purifier 这样的库完成的,但即便如此,仍然存在漏洞。替代的、更简单的标记方案可能会有所帮助。 (b) 当您允许用户上传文件时,这是很难保证安全的。

XSS is mostly about the HTML-escaping(*). Any time you take a string of plain text and put it into an HTML page, whether that text is from the database, directly from user input, from a file, or from somewhere else entirely, you need to escape it.

The minimal HTML escape is to convert all the & symbols to & and all the < symbols to <. When you're putting something into an attribute value you would also need to escape the quote character being used to delimit the attribute, usually " to ". It does no harm to always escape both quotes (" and the single quote apostrophe '), and some people also escape > to >, though this is only necessary for one corner case in XHTML.

Any good web-oriented language should provide a function to do this for you. For example in PHP it's htmlspecialchars():

<p> Hello, <?php htmlspecialchars($name); ?>! </p>

and in Smarty templates it's the escape modifier:

<p> Hello, {$name|escape:'html'}! </p>

really since HTML-escaping is what you want 95% of the time (it's relatively rare to want to allow raw HTML markup to be included), this should have been the default. Newer templating languages have learned that making HTML-escaping opt-in is a huge mistake that causes endless XSS holes, so HTML-escape by default.

You can make Smarty behave like this by changing the default modifiers to html. (Don't use htmlall as they suggest there unless you really know what you're doing, or it'll likely screw up all your non-ASCII characters.)

Whatever you do, don't fall into the common PHP mistake of HTML-escaping or “sanitising” for HTML on the input, before it gets processed or put in the database. This is the wrong place to be performing an output-stage encoding and will give you all sort of problems. If you want to validate your input to make sure it's what the particular application expects, then fine, but weeding out or escaping “special” characters at this stage is inappropriate.

*: Other aspects of XSS are present when (a) you actually want to allow users to post HTML, in which case you have to whittle it down to acceptable elements and attributes, which is a complicated process usually done by a library like HTML Purifier, and even then there have been holes. Alternative, simpler markup schemes may help. And (b) when you allow users to upload files, which is something very difficult to make secure.

昔梦 2024-09-08 10:39:29

对于 SQL 注入,转义是不够的 - 您应该尽可能使用数据访问库和参数化查询。

对于XSS(跨站脚本),从对输出数据进行html编码开始。再说一次,反 XSS 库是你的朋友。

当前的一种方法是仅允许非常有限数量的标签进入,并在过程中清理这些标签(白名单+清理)。

In regards to SQL Injection, escaping is not enough - you should use data access libraries where possible and parameterized queries.

For XSS (cross site scripting), start with html encoding outputted data. Again, anti XSS libraries are your friend.

One current approach is to only allow a very limited number of tags in and sanitize those in the process (whitelist + cleanup).

岁月染过的梦 2024-09-08 10:39:29

您需要确保人们无法在评论中发布 JavaScript 代码或可怕的 HTML。我建议您禁止除非常基本的标记之外的任何内容。

如果注释不应包含任何标记,那么执行 a

echo htmlspecialchars($commentText);

就足够了,但它非常粗糙。更好的办法是在将所有输入放入数据库之前对其进行清理。 PHP strip_tags() 函数可以帮助您入门。

如果您想允许 HTML 注释,但为了安全起见,您可以尝试 HTML Purifier

You'll want to make sure people can't post JavaScript code or scary HTML in their comments. I suggest you disallow anything but very basic markup.

If comments are not supposed to contain any markup, doing a

echo htmlspecialchars($commentText);

should suffice, but it's very crude. Better would be to sanitize all input before even putting it in your database. The PHP strip_tags() function could get you started.

If you want to allow HTML comments, but be safe, you could give HTML Purifier a go.

隔岸观火 2024-09-08 10:39:29

在将用户输入的数据放入数据库之前,不应修改该数据。修改应该在您将其输出到网站时进行。您不想丢失原始数据。

当您将其输出到网站时,您希望使用类似 htmlspecialchars("my output & stuff", ENT_QUOTES, 'UTF-8') 将特殊字符转义为 HTML 代码 - - 确保指定您正在使用的字符集。该字符串将被翻译成 my output &供浏览器读取的内容

You should not modify data that is entered by the user before putting it into the database. The modification should take place as you're outputting it to the website. You don't want to lose the original data.

As you're spitting it out to the website, you want to escape the special characters into HTML codes using something like htmlspecialchars("my output & stuff", ENT_QUOTES, 'UTF-8') -- make sure to specify the charset you are using. This string will be translated into my output & stuff for the browser to read.

锦欢 2024-09-08 10:39:29

防止 SQL 注入的最佳方法就是不使用接受用户输入的动态 SQL。相反,将输入作为参数传递;这样它将是强类型的并且无法注入代码。

The best way to prevent SQL injection is simply not to use dynamic SQL that accepts user input. Instead, pass the input in as parameters; that way it will be strongly typed and can't inject code.

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