防止SQL注入:这是对数据库的攻击的工作方式

Anonim

根据当前的数据库引擎排名,诸如Oracle,MySQL和Microsoft SQL Server之类的关系数据库管理系统(RDBMS)在市场上最受欢迎。 由于它们被认为非常可靠并且可以避免数据集中的不一致,因此数十年来,它们已成为大多数公司中数据库的既定标准。

为了检索和编辑数据,通常使用结构化查询语言(SQL)数据库语言。 例如,用户通过网上商店中的产品搜索掩码与服务器进行通信,该服务器依次查询数据库并将结果作为搜索结果播放回网上商店。

这样,存储的信息容易受到所谓的SQL注入(SQLi)的影响,该注入将任意代码注入数据库查询中。 这样就可以在未经授权的情况下读取或更改信息。 在最坏的情况下,入侵者将控制整个数据库。

spoods.de
SQL Injection
SQL注入
照片:Maxx Studio-shutterstock.com

简单常绿

该攻击方法于1998年被发现,此后一直被认为是最持久的威胁之一。 在独立的开放式Web应用程序安全项目(OWASP)定期发布的十大Web应用程序安全风险(PDF)中,SQLi自2010年以来一直排名第一。 在2019年8月,该漏洞连续第四年在以色列安全供应商Checkpoint的每月全球威胁指数中位列最容易被利用的漏洞之首。

没错 因此,在2019年3月,可以通过经销商数据库中的客户数据读取并消除在线商店软件Magento中的漏洞。 2018年,加拿大互联网服务提供商Altima网站上出现了故障(导致计算机程序故障的软件或编程错误),有可能通过所谓的盲目SQL注入(稍后会详细介绍)来解决访问广泛的客户数据库。

SQLi在黑客中如此受欢迎的原因之一是它是一种非常简单的攻击。 在2018年于拉斯维加斯举行的第26届DEF CON黑客大会上,一个11岁的孩子能够通过SQLi在短短的十分钟之内破解和操纵佛罗里达州选举外观网站的一个副本。

另一方面,防御措施既简单又有效。 在下文中,描述了各种类型的SQLi并提供了防御选项。

遮阴类型

无论涉及哪种类型的SQL注入,攻击者每次都将任意SQL代码发送到Web应用程序的数据库查询中。 这可以以不同的方式发生。

最简单的攻击形式是通过用户输入进行的 。 Web应用程序通常通过表单接受输入。 然后,前端将输入转发到后端的数据库以进行处理。 如果Web应用程序未清除输入,则可以通过注入的SQL输入删除,复制或修改数据库内容。

攻击者还可以修改Cookie来感染Web应用程序查询。 Cookies将有关客户端状态的信息存储在本地硬盘上。 通常,Web应用程序加载cookie来处理此信息。 恶意用户或恶意软件可以对其进行修改,以将SQL命令注入后端数据库。 通过服务器变量(例如HTTP标头)也可以做到这一点。 如果Web应用程序未清除此输入,则包含任意SQL的伪标题可以将此代码注入数据库。

盲SQL类型攻击是对Web应用程序的攻击,它们不会主动阻止SQLi,但是不会明显显示注入结果。 而是,它们没有显示明显的响应,也没有显示一般错误消息,例如,表明SQL查询的语法不正确。 尽管在这种情况下页面不提供任何数据,但是根据注入到合法SQL中的逻辑语句的结果,页面略有不同。

信息不是通过这种方法直接识别的,而是通过一系列正确或错误的查询然后从数据库中删除的。 这种方法被认为非常耗时。 但是,一旦发现漏洞和所需信息,就可以通过一组工具自动进行攻击。

二阶 SQL注入攻击是最隐秘的攻击,因为它们不会立即生效,而是会在稍后发生。 此类恶意但不活动的SQL命令可以由应用程序正确编码,并作为有效SQL存储在数据库中。 然后,如果应用程序的另一部分(可能未受到SQLi的保护)在不同的上下文中执行存储的SQL语句,则将启动延时攻击。

简单的SQLi攻击示例

例如,假设一家公司构建了一个Web应用程序,客户可以在其中输入客户编号来访问其个人资料。 应用程序的前端将输入的号码重定向到后端。 数据库执行SQL调用,并将结果返回给应用程序,然后将其显示给用户。

因此,我们的用户在前端输入了他的号码1234567。

后端中的查询可能看起来像这样:

选择*

来自客户

WHERE customer_id ='1234567'

假设用户在Web表单的字段中输入以下客户编号:

1234567; 删除*客户的'1'='1

然后,后端中的数据库将执行以下SQL:

选择*

来自客户

WHERE customer_id ='1234567';

删除*

来自客户

其中'x'='x'

数据库依次执行多个SQL语句,并用分号(;)分隔。 如果未对单引号(')的输入进行删节,则攻击者可以删除整个表

这是一个故意简单的示例,但是每个SQLi都遵循相同的原理:通过Web应用程序的不受限制的输入,将执行数据库中的所有SQL代码。

Eingaben bereinigen, Zfsrechte beschränken und die Verwendung von Stored Procedures sowie Prepared Statements heben das grundlegende Schutzniveau gegen SQLi erheblich.
清理条目,限制访问权限以及使用存储过程和准备好的语句显着提高了针对SQLi的基本保护级别。
照片:乔·Techapanupreeda-shutterstock.com

用火扑灭

由于SQLi攻击相对容易编织,因此很快就可以自动化。 攻击者和防御者都可以使用SQLninja,SQLmap或Havij之类的工具,从而使公司可以测试其Web应用程序是否存在针对SQLi的漏洞。

例如,SQLmap是一个不错的选择,因为它支持几乎所有主要数据库,包括MySQL,Oracle,PostgreSQL,Microsoft SQL Server,Microsoft Access,IBM DB2和SAP MaxDB。 它适用于所有主要操作系统,并且可以识别Web应用程序中最常见的注入漏洞。 这样可以轻松确定净化输入的措施是否真正起作用。

发现SQLi

有两种检测SQL注入攻击的方法。 Web应用程序防火墙(WAF)可以根据预定义的规则检查传入流量以进行操纵输入,并在必要时进行阻止。 就监视数据库本身而言,入侵检测系统(IDS)很有用。 基于网络的IDS监视与数据库的所有连接,并对可疑活动发出警报。 基于主机的IDS跟踪Web服务器日志文件并报告违规情况。

防止SQLi

有关所有相关防护措施的完整详细说明,请参见OWASP SQL注入预防备忘单。 下面我们提供一些最重要的选择。

与公司IT上的大多数攻击面一样,良好的补丁程序卫生可以解决许多问题。 它定期发现和修复黑客可用于SQL注入的应用程序和数据库中的漏洞。 因此,保持补丁和更新为最新很重要。

为了进行基本保护 ,必须以某种方式管理通过SQL进行的数据库访问,以确保在执行之前清除所有输入而没有异常。 这意味着不允许使用不正常的字符来指示操作,并不允许使用转义序列之类的措施来确保输入不会被错误地视为命令。 另外,建议按上下文过滤所有条目。 例如,电话号码应仅允许数字输入。 即使攻击者键入不同的命令,所谓的准备语句也会阻止更改查询的目的。

如果尽管清理仍然存在漏洞,则限制数据库用户的帐户特权非常重要。 最低权限原则应适用。 该应用程序仅具有足够的回旋余地来完成其工作,仅此而已。 例如,Web应用程序只能获得读取权限,而没有写权限。 另外,删除整个数据库的命令“ DROP TABLES”不应执行。

同样,通过一次调用在数据库中执行一系列存储命令的存储过程 ,会使SQLi变得更难-甚至不是不可能。 如果Web应用程序仅需要执行一些SQL查询,则应为其编写存储过程。 通常,只有数据库管理员有权创建和编辑它们。 重要的是要注意,许多数据库已经具有现成的存储过程,攻击者可能知道这些存储过程。 如果这些不是绝对必要的,则应将其删除。

护理是最好的保护

SQL注入是对企业数据的最简单的攻击手段之一,因此,精明的攻击者可以使用它进行很多破坏。 但是,对于公司而言,关闭这个开放的侧面同样容易。 需要做的就是在Web应用程序和数据库之间建立通信时要格外小心,并采取一些保护措施。