Question

我有一个项目，我试图让其他可能是敌对的编码器用小写标记，将在不同的上下文中显示各种属性，包括嵌入HTML，在Postgres中保存和操作，用作属性标签在JavaScript中，并在shell中操作（例如，将数据文件保存为продажи.zip）以及各种数据分析工具，如图形工具等。

之前我曾参与过多语言项目，但他们要么是小客户，要么不需要特别担心复杂的攻击，要么是我在多语言方面后来到的项目这个地方，所以我不是负责验证安全的人。

我很确定这些应该是安全的，但我不知道是否有需要注意的问题，例如，中文字符集中的特殊[TAB]或[QUOTE]字符可能会逃避我的逃避。

我的正则表达式过滤器中的这些是否正常？

dash = '-' english = 'a-z' italian = '' russain = 'а-я' ukrainian = 'ґї' german = 'äöüß' spanish = 'ñ' french = 'çéâêîôûàèùëï' portuguese = 'ãõ' polish = 'ąćęłńóśźż' turkish = 'ğışç' dutch = 'áíúýÿìò' swedish = 'å' danish = 'æø' norwegian = '' estonian = '' romainian = 'șî' greek = 'α-ωίϊΐόάέύϋΰήώ' chinese = '([\p{Han}]+)' japanese = '([\p{Hiragana}\p{Katakana}]+)' korean = '([\p{Hangul}]+)'

Answer 1

如果您将自己限制为使用7位ASCII兼容子集的文本编码，那么在与大多数纯粹的编程语言交互时，将0x7f（U+007f）以上的任何内容视为“安全”是相当安全的和工具。如果你使用perl6你运气不好;）

您应该避免使用文本编码Shift-JIS来支持或特别注意文本的输入或输出，其中¥符号位于0x5c，其中\通常居住。这通过利用编码转换为恶意欺骗提供了机会。

避免或小心使用其他非ascii兼容的编码。 EBDIC是一个，但你不可能在野外遇到它。显然是UTF-16和UTF-32，但是如果你对它们进行错误处理，结果会非常明显。

读：

我个人认为你的方法是倒退的。您应该根据每个目标工具或语言的词法语法定义输入和输出函数以转义和转义字符串，而不是试图禁止任何可能的元字符。但后来我不知道你的情况，也许这对你正在做的事情来说是不切实际的。

Answer 2

我不太确定你的实际问题是什么。如果您正确地将文本转换为目标格式，那么您就不关心文本可能是什么。这将确保正确的转换和安全性。

例如：

如果您的文字要包含在HTML中，则应使用适当的HTML引用功能对其进行转义。

示例：

<强>错误
```
// XXX DON'T DO THIS XXX
echo "<span>".$variable."</span>"
```
右：
```
// Actual encoding function varies based your environment
echo "<span>".htmlspecialchars($variable)."</span>"
```
是的，这也可以正确处理包含&或<的文字。

如果要在SQL查询中使用文本，则应使用参数化查询。

示例：

<强>错误

// XXX DON'T DO THIS XXX
perform_sql_query("SELECT this FROM that WHERE thing=".$variable")

右

// Actual syntax and function will vary
perform_sql_query("SELECT this FROM that WHERE thing=?", [$variable]);

如果要将文本包含在JSON中，只需使用适当的JSON编码函数。

示例：

<强>错误

// XXX DON'T DO THIS XXX
echo '{"this":"'.$variable.'"}'

右

// actual syntax and function may vary
echo json_encode({this: $variable});

shell有点棘手，在许多环境中处理非ASCII字符（例如FTP或在不同环境之间执行scp）通常很痛苦。因此，不要对文件使用显式名称，使用标识符（numeric id，uuid，hash ...）并将映射存储到其他地方（在数据库中）的实际名称。

这些字符在HTML，Postgres和Bash中是否可以安全使用？

2 个答案: