Interpolique:透明地阻止SQL注入和XSS使用base64编码,发生了什么?

时间:2012-03-06 03:29:16

标签: security xss sql-injection

对于几年前的keynote at The Next HOPE,Dan Kaminsky公布了Interpolique(谈话真的很有趣btw)。他提出的问题是如何抵御注入攻击,包括SQL注入,跨站点脚本(XSS)和其他注入漏洞。例如,Unicode使转义字符无用,而且准备好的语句是PITA。

他的修复是在传输过程中将字符串转换为base64。例如,在SQL中,可以使用decode64 eval()简单地填充SQL调用。它比预处理语句容易得多,对数据库性能影响很小(如果有的话),对数据库用户透明,编程语言中的本机实现可以使程序员在使用和服务器性能方面都变得透明。可以应用类似的技术来防御XSS和所有跨语言通信。但是,除了当时写的几篇博客文章之外,我无法在任何地方找到它。

发生了什么事?

3 个答案:

答案 0 :(得分:1)

发生什么事了?发生的事情与安全领域的许多好主意相同:由于发明人无法控制的原因,它无处可去。这是一个很酷的想法,但它需要框架和应用程序开发人员采用。而且,无论好坏,对此类安全解决方案的需求并不大。对于大多数开发人员来说,安全性是次要考虑许多应用程序开发人员认为他们没有问题并且不认为需要解决方案(他们中的大多数可能都在欺骗自己,但事实如此)。许多 知道XSS的开发人员认为他们可以通过小心谨慎来避免它(这是一个可疑的命题,因为它太容易造成一个无意识的错误,而这个错误会损害你的安全性整个网站,但嘿,如果他们觉得不需要它,他们就不会采用它了。)

请理解Interpolique主要不是关于SQL注入。您将其描述为关于SQL注入,但这不是它的主要贡献。它的主要贡献是帮助抵御XSS和其他注入攻击。 Kaminsky的演讲确实讨论了如何使用Interpolique来防止SQL注入,但我怀疑这主要是一种教学设备。 Interpolique是针对注入攻击的一般防御,其中SQL注入和XSS是两个例子。 SQL注入比XSS更容易理解和更易于理解,因此在SQL注入的上下文中解释Interpolique背后的思想可能比XSS更简单。任何安全研究人员都应该立即了解它们如何应用于XSS环境,这是更重要和更具挑战性的问题。正如其他人所说的那样,准备好的语句对于实际用途的SQL注入来说是一个“足够好”的解决方案(实际上有些情况不是由预准备语句处理的,但它们可能通过转义/验证加上仔细的代码审计来处理),所以这不是国际刑警组织最有用的地方。

此空间中最受欢迎的安全技术是context-aware auto-escaping,例如that implemented in Google's ctemplate。这需要框架支持,但对于开发人员而言可能比Interpolique更好,因为在大多数情况下它不需要开发人员的额外努力:转义是自动完成的。此外,它对安全性也更好:默认情况下,转义是完成的,因此默认值是安全的,开发人员必须采取一些明确的步骤来禁用安全措施。

这个问题可能会在IT安全堆栈交换上得到更明智的回应。 (我简直不敢相信一个人真的写过“Danno那个Dan Kaminsky家伙,但他不知道。”我希望这是一个笑话!Kaminsky是计算机安全领域最杰出和最受尊敬的研究人员/从业者之一。)您可以在以下问题中找到有关IT安全性的Interpolique和类似技术:Whitelisting DOM elements to defeat XSSEscaping JavaScript constants

答案 1 :(得分:-1)

如果您看到实际返回的内容,YCS给出的示例将更加清晰:

php > echo mysql_real_escape_string("1; DROP TABLE users;");
1; DROP TABLE users;
php > echo mysql_real_escape_string("1'; DROP TABLE users;");
1\'; DROP TABLE users;

此函数部分可以缓解某些向量以进行SQL注入,但它绝不会提供针对它的全面保护。您仍然必须使用输入验证和输出转义来阻止它。

答案 2 :(得分:-2)

丹诺是那个丹卡明斯基的家伙,但他毫无头绪。

  • 正确使用时,字符串无法使用 (并且,事实上,转义字符串与注入无关)
  • 准备好的陈述不是PITA,如果用得有点聪明

所以,他的两个假设都是明显错误的。这足以使他的框架过时。

可能他刚刚意识到释放他的想法后不久 - 这可能是你再也没有听说过这种方法的原因。

顺便说一句,例如,Mysql开箱即用it's own base16 encoding facility

mysql> SELECT 0x5061756c;
       -> 'Paul'

不需要实施理想化的项目。 它虽然没有被广泛使用。

但我不得不承认,与逃避不同,在不当使用的情况下不会失败。

说,一个臭名昭着的逃避使用的臭名昭着的案例(PHP / Mysql)

$spoiled_data = "1; DROP TABLE users;"
$spoiled_data = mysql_real_escape_string($spoiled_data);
$query        = "SELECT * FROM users where id=$spoiled_data";

移植到十六进制字符串时

$spoiled_data = "1; DROP TABLE users;"
$spoiled_data = '0x'.bin2hex ($spoiled_data);
$query        = "SELECT * FROM users where id=$spoiled_data";

非常安全。