sql注入利用_SQL注入：这是什么？ 原因和利用

sql注入利用

摘要 (Summary)

Many security vulnerabilities are discovered, patched, and go away forever. Some linger and continue to plague software development and will continue to do so for years to come. Setting aside social engineering and non-technical attacks, SQL injection remains one of the top security threats to our data, as well as one of the most misunderstood.

许多安全漏洞被发现，修补并永久消失。 有些人会持续困扰软件开发，并将在未来几年继续这样做。 除了社会工程和非技术攻击之外，SQL注入仍然是对我们数据的最大安全威胁之一，也是最容易被误解的问题之一。

This article takes a modern look at SQL Injection and the many ways in which it persists, despite our knowledge into what it is, what causes it, and how to eliminate it. We’ll also discuss misconceptions and myths that often hinder our security efforts along the way.

尽管我们对SQL注入是什么，导致它的原因以及如何消除它有所了解，但本文还是对SQL注入及其保留的许多方式进行了现代化的研究。 我们还将讨论误解和误解，这些误解和误解通常会阻碍我们一路安全工作。

什么是SQL注入？ (What is SQL Injection?)

Definitions vary amongst professionals, but I prefer the broadest one possible: SQL Injection is any attempt to run unauthorized code on a SQL Server via an authorized path. Unauthorized code includes absolutely anything from security commands to string searches to schema changes. The authorized path allows us to exclude traditional hacking, as well as social engineering and other exploits that clearly are not relevant here.

专业人员之间的定义不尽相同，但我更喜欢最广泛的定义：SQL注入是通过授权路径在SQL Server上运行未授权代码的任何尝试。 未经授权的代码包括从安全命令到字符串搜索到架构更改的所有内容。 授权路径使我们可以排除传统的黑客手段以及社会工程和其他与此处显然不相关的漏洞。

SQL injection is a subset of an even larger exploit known as an injection, which also includes application code, web components, networking hardware, and the other various components that make up the framework of an application.

SQL注入是称为注入的更大漏洞利用的子集，它还包括应用程序代码，Web组件，网络硬件以及组成应用程序框架的其他各种组件。

This threat is the most frequent and consistently rated top security exploit in the history of database software. Despite years of research, identification, and attention, SQL injection persists and continues to plague organizations via unprotected endpoints.

该威胁是数据库软件历史上最频繁且始终被评为最高的安全漏洞。 尽管经过多年的研究，识别和关注，SQL注入仍然存在，并继续通过不受保护的端点困扰组织。

For our work, we will consider a SQL injection attempt successful if a user can access any data or SQL Server components that they are not normally authorized to access.

对于我们的工作，如果用户可以访问通常无权访问的任何数据或SQL Server组件，我们将认为SQL注入尝试成功。

SQL注入的来源 (Sources of SQL Injection)

SQL injection requires some entry point to execute. Some common endpoints include:

SQL注入需要一些入口点才能执行。 一些常见的端点包括：

动态SQL (Dynamic SQL)

This is often mistaken as the only source of SQL injection, which can be detrimental to security efforts. Dynamic SQL provides the ability to splice variables into TSQL at runtime, allowing us to accomplish tasks that otherwise could be time-consuming or inefficient. This makes it a valuable tool, but one where its users need to ensure that each of those variables is cleansed appropriately prior to use.

这通常被误认为是SQL注入的唯一来源，这可能对安全性工作不利。 动态SQL提供了在运行时将变量拼接到TSQL中的功能，从而使我们能够完成可能耗时或效率低下的任务。 这使其成为一种有价值的工具，但它的用户需要确保在使用之前适当清理每个变量。

Consider the following TSQL:

考虑以下TSQL：

DECLARE @Sql_Command NVARCHAR(MAX);
DECLARE @Search_Criteria NVARCHAR(MAX);
 
SELECT @Sql_Command = '
  SELECT
    *
  FROM Person.Person
  WHERE Person.FirstName = ''';
 
  SELECT @Search_Criteria = 'Edward'; -- This text is captured by a form field within an application.
  SELECT @Sql_Command = @Sql_Command + @Search_Criteria + '''';
  EXEC (@Sql_Command);

It’s a simple script that searches a table for anyone with a first name matched by the variable @Search_Criteria. If this variable is being populated via a web form or some open input, then there are a multitude of ways it could be abused. Some common tactics are to:

这是一个简单的脚本，它在表中搜索名字与变量@Search_Criteria匹配的任何人。 如果通过Web表单或某些开放输入来填充此变量，则可以通过多种方式使用它。 一些常见的策略是：

• Close the string and enter your own TSQL
  关闭字符串并输入您自己的TSQL
• Use special characters to augment a LIKE comparison, such as %, [], or insert regex
  使用特殊字符来增强LIKE比较，例如％，[]或插入正则表达式
• Input an empty search
  输入空搜索
• Use UNION ALL to append additional TSQL to the original search query
  使用UNION ALL将其他TSQL附加到原始搜索查询
• Use comments to eliminate any TSQL on the same line as the dynamic SQL
  使用注释消除与动态SQL相同的所有TSQL

The following is an example of TSQL and the results that can be gotten if the inputs have no protection:

以下是TSQL的示例，如果输入没有保护，则可以得到结果：

DECLARE @Sql_Command NVARCHAR(MAX);
DECLARE @id NVARCHAR(MAX) = '3';
DECLARE @password NVARCHAR(128) = ''' UNION ALL SELECT * FROM Person.Password WHERE '''' = ''';
 
SELECT @Sql_Command = '
  SELECT
    *
  FROM Person.Password
  WHERE Password.BusinessEntityID = ' + @id + '
  AND PasswordHash = ''' + @password + '''';
EXEC (@Sql_Command);

The intention is a query that returns data for a given user ID and password, but since there are no protections on either input, the TSQL can easily be hacked into returning additional data from the table.

目的是查询返回给定用户ID和密码的数据，但是由于任一输入都没有保护，因此TSQL可以很容易地被黑客入侵以从表中返回其他数据。

Being able to get a list of usernames, tables, passwords, or any related data can be quite dangerous, even if that data is incomplete. User names can be used to intentionally fail logins and lockout users. Information about schema can be used to determine other ways to attack a server and ultimately steal data.

即使没有完整的用户名，表，密码或任何相关数据的列表，也很危险。 用户名可用于故意使登录失败并锁定用户。 有关架构的信息可用于确定攻击服务器并最终窃取数据的其他方式。

URL字符串的修改 (Modification of URL Strings)

While most modern web sites protect against this, URL hacking is still one of the most common ways in which someone attempts to gain access to data. This method is hard to detect, requires little skill, and determining success or failure is relatively quick.

尽管大多数现代网站都对此加以保护，但是URL黑客攻击仍然是人们试图获取数据访问权的最常见方式之一。 这种方法难以检测，需要的技能很少，并且确定成功或失败的速度相对较快。

If a URL contains search strings, security descriptors, or other sensitive components, then an application needs to validate URL contents prior to processing them. In addition, the application should obscure any URL contents that might be used to gain undesired app information, such as primary key IDs or entity names.

如果URL包含搜索字符串，安全描述符或其他敏感组件，则应用程序需要在处理URL内容之前对其进行验证。 此外，应用程序应遮盖所有可能用于获取不需要的应用程序信息的URL内容，例如主键ID或实体名称。

Maintaining and monitoring weblogs can be an arduous task, but can provide valuable insight into areas in which hackers are trying to maliciously access a given site. Alerting on these logs can give us advance notice of potential attacks and the details of how they are being performed, as well as their origin.

维护和监视Web日志可能是一项艰巨的任务，但可以提供有价值的洞察力，以了解黑客试图恶意访问给定站点的领域。 在这些日志上发出警报可以使我们提前通知潜在的攻击以及如何进行攻击的详细信息以及其来源。

网络/申请表 (Web/Application Forms)

Any place where users can enter freeform data should be given careful attention. This is the source of most SQL injection attacks. Hackers play the role of quality assurance and will enter every odd combination of characters, symbols, or data length in an attempt to trigger an error or unexpected behavior.

用户在任何可以输入自由格式数据的地方都应给予特别注意。 这是大多数SQL注入攻击的根源。 黑客扮演着质量保证的角色，他们会输入字符，符号或数据长度的所有奇数组合，以试图触发错误或意外行为。

I’m curious about what happens when special characters are entered into these text fields. Are they treated like a string (as they should be) or do they interfere with TSQL or app code, causing unexpected behavior?

我对在这些文本字段中输入特殊字符会发生什么感到很好奇。 是否像对待字符串一样（应有的对待），或者它们会干扰TSQL或应用程序代码，从而导致意外行为？

In this scenario, there are enough protections in place to ensure that my attempts at triggering errors or breaking TSQL strings would fail. By greatly restricting what characters are allowed, we can head off SQL injection before it has a chance to rear its ugly head.

在这种情况下，有足够的保护措施可以确保我触发错误或破坏TSQL字符串的尝试失败。 通过极大地限制允许使用哪些字符，我们可以在SQL注入有机会抬起丑陋的头之前阻止它。

员工滥用受限访问权限 (Employee Abuse of Limited Access)

While we never want to consider internal employees as potential bad actors, we need to accept that in an organization large enough, someone may eventually resort to bad behavior, given a good enough opportunity. A login that has limited server access may be able to exploit SQL injection to gain additional access that normally would not be allowed.

尽管我们从不希望将内部员工视为潜在的不良行为者，但我们需要接受的是，在足够大的组织中，如果有足够的机会，某人最终可能会诉诸不良行为。 具有受限服务器访问权限的登录名可能能够利用SQL注入来获得通常不允许的其他访问权限。

Securing against SQL injection removes this avenue of attack and protects an organization from within. This is valuable in a world full of social engineering, phishing, and other attacks that may go beyond the simplicity of a single malicious employee. A hacker with control over app or database access for an internal resource may gain quite a bit of power that the employee didn’t even know they had. We want this access to be minimized as much as possible, and the many protections we implement to counter SQL injection greatly assist in this challenge!

防止SQL注入的安全消除了这种攻击途径，并保护了组织免受内部攻击。 在一个充满社会工程，网络钓鱼和其他攻击的世界中，这很有价值，这可能不仅仅是单个恶意员工的简单性。 可以控制内部资源对应用程序或数据库访问的黑客可能会获得很多员工甚至不知道自己拥有的权力。 我们希望尽可能减少这种访问，我们为抵制SQL注入而实施的许多保护措施极大地帮助了这一挑战！

错误讯息 (Error Messages)

There are a few things more dangerous than exposing error messages in an application. If you are using an app and see the following, what do you think?

有几件事比在应用程序中公开错误消息更危险。 如果您使用的是应用程序，请参阅以下内容，您认为呢？

Some people might move on and ignore this, but any hacker knows that the exposure of this error message accomplishes 2 tasks:

某些人可能会继续前进而忽略了这一点，但是任何黑客都知道暴露此错误消息可以完成2个任务：

1. It provides some information about the application, database, and schema via the error details
   它通过错误详细信息提供有关应用程序，数据库和架构的一些信息。
2. It shows us that errors are not trapped correctly and that there may be an opportunity to inject SQL at the error’s source
   它向我们表明错误没有被正确捕获，并且可能有机会在错误源处注入SQL

Error messages should always be trapped, whether they be SQL, application, or web errors. Once caught, we can log them and provide a friendly (and less-specific) message to the user.

错误消息应始终被捕获，无论它们是SQL错误，应用程序错误还是Web错误。 一旦被捕获，我们就可以记录它们并向用户提供友好（且不太具体）的消息。

如何利用SQL注入？ (How can SQL Injection be exploited?)

Once an entry point is established, a hacker’s actions will only be limited by the security of the user they are operating as. Some examples of unauthorized use include:

一旦建立了入口点，黑客的行为将仅受到其操作用户的安全性的限制。 未经授权使用的一些示例包括：

• Modifying TSQL statements to return additional data
  修改TSQL语句以返回其他数据
• Modify stored procedures, functions, or other database schemas
  修改存储过程，函数或其他数据库模式
• Test for the existence of database or server objects, such as tables or users
  测试是否存在数据库或服务器对象，例如表或用户
• Alter passwords or permissions
  更改密码或权限
• Access components outside of SQL Server, such as server or storage infrastructure
  访问SQL Server外部的组件，例如服务器或存储基础结构
• Delete, steal, alter, encrypt, or attempt to ransom data from within the database
  删除，窃取，更改，加密或尝试从数据库内部勒索数据
• • A sneaky hacker will do this to a different server or service to introduce a distraction
    偷偷摸摸的黑客将对其他服务器或服务执行此操作，从而引起干扰

SQL注入的常见原因 (Common Causes of SQL Injection)

No one intentionally leaves behind security holes that can be exploited with SQL injection. There are many reasons why these security holes come about, and oftentimes they are not because we simply wrote bad code. Here is a shortlist of the most common causes of SQL injection:

没有人故意留下安全漏洞，可以通过SQL注入加以利用。 造成这些安全漏洞的原因有很多，而通常不是因为我们只是编写了错误的代码而已。 以下是SQL注入最常见原因的清单：

旧代码，旧代码或惰性代码 (Old, Legacy, or Lazy Code)

Sometimes code was secure enough or adequate when it was written, but as time passed and technology changed, what was secure 10 years ago is no longer acceptable.

有时代码在编写时是足够安全或足够的，但是随着时间的流逝和技术的变化，十年前的安全性已不再被接受。

As we write new code and create new features, we need to also review old code and features to ensure that things that are old are not also becoming antiquated. Unused or unneeded code should also be removed as it is the most likely to receive zero attention in the future. This balance helps ensure that all code stays secure and relevant when faced with the test of time.

在编写新代码和创建新功能时，我们还需要查看旧代码和功能，以确保旧事物也不会过时。 也应删除不使用或不需要的代码，因为它将来最有可能受到零关注。 这种平衡有助于确保所有代码在经过时间考验时都保持安全性和相关性。

过时/未修补的应用程序 (Outdated/Unpatched Applications)

Making use of unsupported or legacy software or features introduces security holes that may not be patched or caught as quickly as they would with modern software.

利用不受支持的或遗留的软件或功能会带来安全漏洞，这些漏洞可能无法像使用现代软件那样被Swift修补或捕获。

Running patched and modern versions of software are critical to avoiding security exploits, including SQL injection. Continuously monitoring for new security vulnerabilities and reacting as needed is an important step towards avoiding unnecessary surprises.

运行补丁程序和现代版本的软件对于避免安全漏洞（包括SQL注入）至关重要。 持续监视新的安全漏洞并根据需要做出React是避免不必要的意外的重要一步。

安全假设 (Security Assumptions)

Often, we are led to a false sense of security due to the isolation of different application teams or environments. If we are led to believe that an application’s web forms are protected against injection by default, then we might be lax when developing stored procedures or other database objects.

通常，由于隔离了不同的应用程序团队或环境，导致我们产生了错误的安全感。 如果我们被认为默认情况下会保护应用程序的Web表单不被注入，那么在开发存储过程或其他数据库对象时我们可能会松懈。

We should practice optimal security whenever possible and never assume that a high level of security elsewhere will also protect us. Applications change and the assumptions that were true in the past or present may not be true in the future. These assumptions eventually lead to compliance and security auditing failures anyway, and provide no benefit beyond saving a little bit of time now.

我们应该尽可能地实践最佳安全性，并且永远不要认为其他地方的高安全性也可以保护我们。 应用程序发生了变化，过去或现在真实的假设在将来可能不正确。 这些假设最终都会导致合规性和安全审核失败，并且除了现在节省一点时间之外没有其他好处。

无法分层安全 (Failure to Layer Security)

The idea that security is a wall and that surrounding servers and applications in security measures can protect from hackers is no longer valid. More accurately, we should view application security like our homes: full of lots and lots of glass windows that can easily be broken.

安全是一堵墙，采用安全措施保护周围的服务器和应用程序可以免受黑客攻击的想法不再有效。 更准确地说，我们应该像对待家一样查看应用程序的安全性：充满了很多很容易被打破的玻璃窗。

The optimal way to secure an organization’s data is to have layers of security around it. Have a secure database server that is accessed by a secure application server that is accessed by a secure web server. Each of these devices is attached to secure networking devices and monitored by services that can alert when things go awry. The end result is a system where it takes significant effort to access data, to the point where such efforts would be sufficient enough to trip alerts and warn an organization that something bad is going on.

保护组织数据的最佳方法是在其周围具有安全层。 有一个由安全应用程序服务器访问的安全数据库服务器，该应用程序服务器由安全Web服务器访问。 这些设备中的每一个都连接到安全的网络设备，并由可以在出现问题时发出警报的服务进行监视。 最终结果是一个系统，在该系统上需要花费大量精力来访问数据，以至于这样的努力足以触发警报并警告组织某些不良情况正在发生。

Within our personal control will be whatever components we manage, which are likely to be database servers. Build servers as securely as possible and never assume that other application components will shield you from bad actors.

在我们的个人控制范围内，是我们管理的任何组件，很可能是数据库服务器。 尽可能安全地构建服务器，并且永远不要认为其他应用程序组件会使您免受不良行为的影响。

漏洞利用 (Exploits)

How SQL injection is used against up is very much up to the creativity or cruelty of a hacker. With unauthorized access to a database server, the level of severity of the attack will be measured by:

如何使用SQL注入抵制攻击很大程度上取决于黑客的创造力或残酷性。 在未经授权访问数据库服务器的情况下，攻击的严重程度将通过以下方式衡量：

• How long did the attack last before it was detected? How long after detection?
  在检测到攻击之前持续了多长时间？ 检测后多长时间？
• Was any unauthorized data viewed, downloaded, modified, or stolen?
  是否查看，下载，修改或窃取了任何未经授权的数据？
• Were any other systems accessed via the attack?
  是否通过攻击访问了其他系统？
• What are the repercussions of the attack? What is the impact on customers or consumers?
  这次袭击有什么影响？ 对客户或消费者有什么影响？

In the event of a breach, these and many other questions will be asked. The goal will be to fully understand a hack and its implications. In addition, privacy and compliance policies will be reviewed. If the hack also breached these agreements, then the complexity of the situation could be many orders of magnitude higher than it previously was. GDPR, HIPAA, EU-US Privacy Shield, Corporate privacy policies, and more all have an impact on a business and the level of security offered, as well as the necessary reaction when an exploit or breach is discovered. Under many agreements, it is necessary to disclose vulnerabilities, even if there is no evidence of a breach.

发生违规时，将询问这些和许多其他问题。 目的是充分理解黑客及其含义。 此外，还将审查隐私和合规政策。 如果黑客也违反了这些协议，那么情况的复杂性可能会比以前高出多个数量级。 GDPR，HIPAA，欧盟-美国隐私保护盾，公司隐私政策等等，都会对业务和所提供的安全级别产生影响，并在发现利用或破坏行为时做出必要的React。 根据许多协议，即使没有证据表明存在漏洞，也有必要披露漏洞。

Most organizations now have security officers and teams that maintain complete knowledge of all business agreements, compliance agreements, and laws regarding data privacy and security. International organizations will have far greater and more complex needs as the laws of each country will need to be considered when determining how to operate. Many companies will choose to build their organization around the most stringent of requirements as a way to simplify operations and avoid the need to have completely different business models for each country-country relationship.

现在，大多数组织都有安全管理人员和团队，可以完全了解所有业务协议，合规性协议以及有关数据隐私和安全性的法律。 国际组织的需求将越来越大，越来越复杂，因为在确定如何运作时需要考虑每个国家的法律。 许多公司会选择按照最严格的要求建立组织，以简化​​运营并避免为每个国家/地区之间的关系建立完全不同的业务模型。

What can attackers do? Here are some examples:

攻击者可以做什么？ 这里有些例子：

• Download unauthorized data
  下载未经授权的数据
• Delete/modify data
  删除/修改数据
• Permanently destroy data/backups
  永久销毁数据/备份
• Long-term monitor a system
  长期监控系统
• Infect systems with viruses or malware
  用病毒或恶意软件感染系统
• Alter security to allow/disallow access as deemed fit by the hacker
  更改安全性以允许/禁止黑客认为合适的访问
• Encrypt/steal/alter data and hold it for ransom
  加密/窃取/更改数据并保存以进行勒索
• Publicly shame an organization via a web or social media hack
  通过网络或社交媒体黑客公开羞辱组织
• Use data to infiltrate an organization or its business operations
  使用数据渗透组织或其业务运营

If any of this sounds outlandish or more likely to be the contents of a James Bond movie, then we’d be sorely mistaken. All of these scenarios have been the result of SQL injection attacks, and have happened many, many times.

如果这听起来像是奇特的东西，或者更像是詹姆斯·邦德电影的内容，那么我们就会非常误解。 所有这些情况都是SQL注入攻击的结果，并且发生了很多很多次。

The largest SQL injection attack to-date was on Heartland Payment Systems in 2008. The SQL injection attack was used to gain access to credit card processing systems. The attack began in March, 2008, but was not discovered until January, 2009. The company was unable to do business for 5 months afterward and was fined $145 million as compensation for fraudulent payments made.

迄今为止，最大SQL注入攻击发生在2008年的Heartland Payment Systems上。SQL注入攻击用于获得对信用卡处理系统的访问权限。 攻击始于2008年3月，但直到2009年1月才被发现。该公司在5个月后无法开展业务，并因欺诈性付款而被罚款1.45亿美元。

Not all details of hacks and breaches are revealed to the public, so there likely are many more than we know about to date. In its most prevalent years, from 2010-2015, it has been estimated that over 2/3 of all companies and government agencies were vulnerable to SQL injection.

并非所有的骇客和违规细节都向公众披露，因此到目前为止，可能还有很多我们不知道的事情。 在从2010年到2015年的最流行的年份中，据估计，所有公司和政府机构中有超过2/3易受SQL注入攻击。

In general, older systems are targeted first under the assumption that an organization that does not stay up-to-date with software is more likely to be negligent on security. The top-attacked database platforms are Oracle, PostgreSQL, MySQL, and MongoDB. Within each platform, the rate of attacks increased with age. Having newer software versions not only provides more modern security options, but it discourages hackers, who typically are looking for easy/low-risk targets.

通常，较旧的系统首先要针对的目标是，一个不及时了解软件的组织更可能对安全性有所疏忽。 攻击最严重的数据库平台是Oracle，PostgreSQL，MySQL和MongoDB。 在每个平台内，攻击率随年龄增长而增加。 拥有较新的软件版本不仅提供了更现代的安全性选项，而且还阻止了通常会寻找容易/低风险目标的黑客。

我们下一步要去哪里？ (Where Do We Go Next?)

With an understanding of what SQL injection is and its causes, we can begin to formulate strategies to detect and prevent it. This is our ultimate goal and one that is critical to data security and is one that affects any platform where data is stored, whether in SQL Server, MySQL, NoSQL, or some other. In our next article, we will continue this discussion into one where we attack this problem proactively, reducing the chances that we will be put on the defensive during a data breach.

了解什么是SQL注入及其原因之后，我们可以开始制定策略来检测和预防它。 这是我们的最终目标，对数据安全至关重要，并且会影响存储数据的任何平台，无论是在SQL Server，MySQL，NoSQL还是其他平台中。 在下一篇文章中，我们将继续进行讨论，以期我们能主动地解决此问题，从而减少在数据泄露期间被置于防御状态的机会。

进一步阅读 (Further Reading)

Choosing an Authentication Mode

选择身份验证模式

Information on Meltdown and Spectre Vulnerabilities

有关崩溃和幽灵漏洞的信息

Details on xp_cmdshell

xp_cmdshell的详细信息

Xp_cmdshell Proxy Credentials

Xp_cmdshell代理凭证

SQL Injection Overview by Microsoft

MicrosoftSQL注入概述

翻译自: https://www.sqlshack.com/sql-injection-what-is-it-causes-and-exploits/

sql注入利用