【问题标题】:Saving textarea in the database将文本区域保存在数据库中
【发布时间】:2013-03-09 18:27:25
【问题描述】:

我一直在搜索这个,但我找不到最重要的部分 - 使用什么字段。

我想保存一个 textarea 而不允许任何类型的 javascript、html 或 php。

在将发布的 textarea 保存到数据库之前,我应该通过哪些函数运行它?我应该在数据库中使用什么字段类型?这将是一个描述,最多 1000 个字符。

【问题讨论】:

  • 没有 HTML、javascript 或 PHP。那么你打算用什么来输入数据呢?
  • 对不起,我想要的是不允许用户在其中保存任何 JS、HTML 或 PHP。我将使用PHP处理提交的表单并将其保存在数据库中。
  • @MikeRobinson 我认为他的意思是他不希望将文本区域内的任何代码存储在数据库中
  • 为了清楚起见,当您问“使用什么字段”时,您的意思是“数据类型”,例如varchartextblob 等等?
  • 是的,超人。我目前正在使用文本

标签: php


【解决方案1】:

有多种方法可以删除/处理代码,以便将其保存在您的数据库中。

正则表达式

一种方法(但可能很难且不可靠)是使用regular expressions 删除/检测代码。

例如以下使用php代码删除所有脚本标签(取自here):

$mystring = preg_replace('/<script\b[^>]*>(.*?)<\/script>/is', "", $mystring)

stip_tags PHP 函数

您还可以利用内置的stip_tags 函数从字符串中去除HTML 和PHP 标记。本手册提供了几个示例,为方便起见,如下所示:

<?php
$text = '<p>Test paragraph.</p><!-- Comment --> <a href="#fragment">Other text</a>';
echo strip_tags($text);
echo "\n";

// Allow <p> and <a>
echo strip_tags($text, '<p><a>');
?>

HTML 净化器

您可以查看HTML Purifier,这是一个常见的 HTML 过滤器 PHP 库,旨在检测和删除危险代码。

在他们的Getting Started 部分找到的简单代码:

require_once '/path/to/HTMLPurifier.auto.php';

$config = HTMLPurifier_Config::createDefault();
$purifier = new HTMLPurifier($config);
$clean_html = $purifier->purify($dirty_html);

实践中(安全输出)

如果您试图避免 XSS 攻击或注入攻击,那么清理用户数据是错误的做法。删除标签并不是 100% 保证您的服务免受这些攻击的保证。因此,在实践中,包含代码的用户数据通常不会被过滤/清理,而是在输出期间转义。更具体地说,字符串中的特殊字符被转义,这些字符基于语言的语法。一个例子是使用 PHP 的 htmlspecialchars 函数来将特殊字符转换为它们各自的 HTML 实体。摘自手册的代码片段如下所示:

<?php
$new = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES);
echo $new; // &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;
?>

有关转义的更多信息以及与您的问题相关的非常好的解释,请查看此page。它向您展示了其他形式的输出转义。另外,关于转义的问答,请点击here

此外,我想向您提出的另一个简短但重要的观点是,从用户不能收到的任何数据都是可信的。

SQL 注入攻击

定义(来自here

SQL 注入攻击包括 SQL 的插入或“注入” 通过从客户端到应用程序的输入数据进行查询。一个 成功的 SQL 注入漏洞利用可以从 数据库,修改数据库数据(插入/更新/删除),执行 对数据库的管理操作(例如关闭 DBMS), 恢复存在于 DBMS 文件系统上的给定文件的内容 并且在某些情况下向操作系统发出命令。

对于 SQL 注入攻击:在将信息存储到数据库时使用准备好的语句和参数化查询。 (问答找到here)可以找到使用PDO准备语句的教程here

跨站脚本 (XSS)

定义(来自here):

跨站点脚本攻击是一种注入问题,其中 恶意脚本被注入到其他良性且受信任的环境中 网站。当攻击者发生跨站点脚本 (XSS) 攻击时 使用 Web 应用程序发送恶意代码,一般形式为 浏览器端脚本,发送给不同的最终用户。

我个人喜欢这张图片以便更好地理解。

XSS 攻击:你应该参考这个著名的page,它逐条描述了需要做什么。

【讨论】:

    【解决方案2】:

    TLDR:

    通常使用htmlspecialchars() 对输出文本进行编码,而不是过滤输入文本。 text 字段可以用于此目的。

    你需要防御什么

    您正试图保护自己免受XSS 的侵害。当用户可以在您的站点上存储 HTML 控制字符时,就会发生 XSS。其他用户会看到此 HTML 标记,因此恶意用户可以使用您的页面将人们重定向到其他网站或窃取 cookie 等。

    您需要为所有输入考虑这一点:这应该包括可以存储在数据库中的任何 varchartext 字段;不仅仅是你的textareas。我可以将恶意内容添加到 input 字段,就像将恶意内容添加到 textarea 一样容易。

    我们如何防御这种情况?

    假设用户声称他们的用户名是:

    <script src="http://example.com/malicious.js"></script>
    

    处理此问题的最简单方法是“按原样”将其保存到数据库中。但是,每当您在网站上echo 它时,您都应该通过 PHP htmlspecialchars() 函数对其进行过滤:

    echo 'Hi, my name is ' . htmlspecialchars($user->username) . '!';
    

    htmlspecialchars 将 HTML 控制字符(&amp;lt;&amp;gt;&amp;amp;'")转换为它们的 HTML 实体(&amp;lt;&amp;gt;&amp;amp;&amp;apos;&amp;quot;)。这看起来像浏览器中的原始字符(即:对于普通用户),但它不像实际的 HTML 标记。

    结果是,用户名看起来像 ,而不是恶意 JavaScript。

    为什么要过滤输出?为什么不输入?

    1 - OWASP recommends this way

    2 - 如果您忘记保护输入字段,并且有人发现并添加了恶意内容,您现在需要在数据库中查找恶意内容修复您网站上的故障代码.

    3 - 如果您忘记对输出字段进行编码,并且有人设法潜入恶意输入,那么您只需修复您网站上的错误代码。

    4 - 用户编写的用户名可能会破坏用于编辑用户名的 HTML 字段。如果您在将内容存储到数据库之前对内容进行编码,那么您需要在适当的输入字段中“按原样”显示它(假设管理员或用户可以稍后更改他们的用户名) .但是,让我们假设用户找到了一种将恶意代码注入数据库的方法。如果他们说他们的用户名是:" style="display:none;" /&gt;。允许管理员更改此用户名的输入字段现在如下所示:

    <input type="text" name="username" value="" style="display:none;" />" />
                    malicious content ->      ^^^^^^^^^^^^^^^^^^^^^^^^^^ 
    

    现在,管理员无法解决问题:输入字段消失了。但是,如果您在输出中对文本进行编码,那么您的所有输入字段都将具有针对恶意内容的保护。现在,您的输入将如下所示:

    <input type="text" name="username" value="&quot; style=&quot;display:none;&quot; /&gt;" />
                         safe content ->      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
    

    【讨论】:

      猜你喜欢
      • 2014-01-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-12-31
      • 1970-01-01
      • 2018-07-13
      • 1970-01-01
      相关资源
      最近更新 更多