爱时密码研究院:Web应用程序中的数据流及安全问题

 admin   2019-12-21 15:58   195 人阅读  0 条评论

当然,如果您最近一直在关注该新闻,则可以看到许多有关网站被黑客入侵以及其数据库被泄漏的报告。网站违规行为显然变得越来越普遍,但是为什么呢?

似乎Web应用程序应该比桌面应用程序更安全它们通常使用托管语言编写,因此开发人员不必担心低级缓冲区溢出样式的攻击。那么,什么使构建安全的Web应用程序如此困难呢?

Web应用程序具有自己独特的攻击集。最常见的方法是:SQL注入和跨站点脚本已被很好地理解,因此我将不对其进行解释。我要解释的是为什么它们如此难以预防。

普通的Web应用程序由四个互不信任的组件组成:

  1. Web浏览器(用户输入)

  2. 外部代码(库)

  3. 数据库(及其内容)

  4. 生成Web浏览器请求的页面的脚本

这些组件中的每一个都必须接受来自另一个组件的潜在危险输入,如下图所示:

网站的安全模型。 四个互不信任的组件。

每个红色箭头提示都表示来自其他组件之一的潜在危险输入。外部代码库不能假定页面生成脚本传递给它的所有内容均已正确清理。同样,页面生成脚本不能假定外部代码返回的数据将被正确清理。外部代码和页面生成脚本都不能假定存储在数据库中的数据已被清除。

从某种意义上说,数据库和Web浏览器是愚蠢的,因为它们总是按照所告诉的去做,而不能区分不好的输入。因此,发送至数据库或Web浏览器的任何数据都必须经过清理,否则可能被利用。

要分析潜在的SQL注入攻击,请查看该图。跟踪来自Web浏览器的数据可能到达数据库的所有可能路径。现在我们可以了解为什么Web应用程序如此难以保护:危险数据可以通过许多途径到达数据库。如果这些路径之一将数据传递到数据库而不进行消毒,则该网站很容易受到SQL注入攻击。

例如,数据可以遵循以下任何路径:

Web浏览器-> script.php->数据库Web浏览器-> script.php->外部代码->数据库Web浏览器-> script.php->数据库-> script.php->数据库Web浏览器-> script.php->数据库->外部代码->数据库等等....

在图论中,这些实际上称为步行,其中有无限多个。

您可能已经注意到script.php始终是该路径的第二步。如果script.php清除了Web浏览器的所有输入,那会不会很好?这将是神奇的,但事实并非如此。因为在为特定平台清理了数据之后,该平台以外的其他任何东西都无法理解它。

为了说明我的观点,让我们假装我们正在使用一些数据库软件构建一个网站,该数据库软件会在查询中的任何位置出现字符串“ 21”时自动销毁(通过自销,我的意思是服务器实际上爆炸了)。现在想象一下我们正在构建一个通讯录网站。

假装Web浏览器要求我们的脚本向数据库添加地址,并发送以下信息:

  • 国家:美国

  • 州:加利福尼亚

  • 城市:比佛利山庄

  • 地址:第31街6556号

  • 邮政编码:90210

您可以看到这里存在潜在的问题。如果我们将这些数据直接插入数据库,则邮政编码中的“ 21”将导致数据库爆炸。我们不希望数据库爆炸,因此我们定义了清理功能,将“ 21”替换为“ TWENTYONE”。我们的数据库软件知道“ 21”问题,因此,当要求它存储值“ TWENTYONE”时,它足够聪明,可以首先将其转换回“ 21”(不爆炸)。

如果script.php清除数据,它将变为:

  • 国家:美国

  • 州:加利福尼亚

  • 城市:比佛利山庄

  • 地址:第31街6556号

  • 邮政编码:90T-WENTYON-E10

现在,script.php可以安全地将其添加到数据库中。但是,如果script.php要使用外部代码库来检查邮政编码在该状态下是否实际上是有效的邮政编码,该怎么办?不能,因为数据已经过清理。外部库不会知道“ 90T-WENTYON-E10”的含义。不幸的是,但不可避免的是,传递给外部库的任何数据script.php都必须经过清理。

如果外部库需要查找数据库中的邮政编码,或者script.php从数据库中提取一个邮政编码并重新插入,或者script.php从外部库中获取了一些信息并想要插入,该怎么办?它进入数据库?所有这些情况下,Web应用程序的程序员都必须在将数据发送到数据库之前对其进行清理。

换句话说,每次将数据发送到数据库时,首先必须对其进行清理。如果Web应用程序中有1000个将数据发送到数据库的位置,则需要进行1000次数据清理。如果仅缺少一个,则可能会发生SQL注入攻击。

跨站点脚本攻击也是如此。跟踪数据可能从Web浏览器,通过网站再回到浏览器的所有路径。

并不是所有的坏消息

使用基于图论的对Web应用程序安全性的理解,我们可以发现保护网站安全的更有效方法。

数据有两种访问数据库的方法,一种是访问浏览器的方法。

通过查看该图,我们看到实际上只有两个数据库输入路径和一个Web浏览器输入路径。在大多数网站中,数据库清理将在“外部代码”和“ script.php”中完成,而HTML清理将在script.php中进行。通过这种方式完成后,图中的每个输入路径代表查询数据库或将数据发送到浏览器的所有1000行代码。这给script.php和外部库的开发人员带来了沉重负担。它迫使他们不断监视是否将未消毒的数据发送到数据库或浏览器。他们必须是安全专业人员。

我们可以通过添加“第四方”清理库来解决这些问题,该库为数据库和Web浏览器定义了“包装器”接口。看起来像这样:

接口A保护数据库,而接口B保护Web浏览器。

在此设置中,接口A和B由安全专业人员开发,旨在为客户端代码提供相同的(或更多的)功能,就像它们不在那里一样。“外部代码”和“ script.php”的开发人员从不直接处理数据库或浏览器。他们总是通过安全界面。因为他们使用界面,所以他们不必担心经典的漏洞利用,例如SQL注入和跨站点脚本。

它不会阻止他们通过应用程序级逻辑错误(例如文件上传,include,exec()或正则表达式)引入安全漏洞。但是这种方法是巨大的改进。接口A和B只需编写一次,并且可以在整个应用程序中重复使用。

接口A允许数据库在逻辑上甚至在物理上与所有其他代码分离。它可以用SOAP或XMLRPC实现,从而允许数据库位于物理上独立的服务器上,因此即使网站服务器受到威胁,它也保持安全。

这也表明设计一种安全的脚本语言是完全可能的,因此不可能执行数据执行样式。甚至可以扩展现有的语言以使利用成为不可能。只需禁用所有内置的“危险”功能并将其功能替换为安全的包装器接口即可


本文地址:http://lovetimes.cn/post/8.html
版权声明:本文为原创文章,版权归 admin 所有,欢迎分享本文,转载请保留出处!

 发表评论


表情

还没有留言,还不快点抢沙发?