r
字符串的前缀不会保留在字符串值中。'a\\b'
并且r'a\b'
是完全相同的字符串,只有一个反斜杠。u
前缀确定字符串是包含字节还是 Unicode 字符。一般来说,Django 应用程序中的字符串应该是 Unicode 字符串,但 Python 会在必要时自动将字节转换为字符(如果使用非 ASCII 字符,这可能会爆炸)。
这些都不能确定字符串是否“安全”。
在表单上使用cleaned_data
存储意味着数据已针对与其关联的特定类型的字段进行了验证。如果您有一个电子邮件字段,那么该cleaned_data
值肯定看起来像一个有效的电子邮件地址。如果您有纯文本字段,则cleaned_data
可以是任何字符串。这些都不能保证字符串是“安全的”;输入验证通常是一件好事,也是一种有用的纵深防御,但它并不能使应用程序安全地防止注入。
由于据我所知这些值没有被转义,它们是否可能不安全?
输入值永远不应该被转义并且永远不会“安全”。转义不是输入处理阶段的工作;当您将值放入具有不同上下文的字符串时,您必须担心转义。
因此,当您创建包含字符串的 HTML 响应时,您会对该字符串进行 HTML 转义。(但更好的是:使用自动为您转义的模板语言,例如 Django 的autoescape
.)
当您创建一个包含字符串的 SQL 查询时,您会对该字符串进行 SQL 转义。(但更好的是:使用参数化查询或 ORM,这样您就不必使用字符串变量创建查询。)
当您创建一个包含字符串的 JavaScript 变量赋值时,您会对该字符串进行 JS 转义。(但更好的是:在 DOM 属性中传递数据data-
并从 JS 中读取,而不是使用内联代码。)
等等。有许多不同形式的转义,并且没有全局转义方案可以保护您免受可能的注入攻击的范围。所以让输入保持原样,在输出阶段转义,或者更好地使用现有的框架工具来避免显式转义。