sql注入 安全_安全基础sql注入

sql注入 安全

As one of the most historically prominent vulnerabilities out there, SQL injections have likely caused millions (if not billions) of dollars worth of damages to thousands of companies over the last 20 years. The vulnerability was first documented in 1998 by Phrack contributer and security researcher Jeff Forristal. The internet never recovered.

作为目前历史上最突出的漏洞之一，SQL注入在过去20年中可能对数千家公司造成了数百万美元(甚至数十亿美元)的损失。 该漏洞由Phrack贡献者和安全研究员Jeff Forristal于1998年首次记录。 互联网从未恢复。

那是什么 (So what is it?)

To understand what a SQL Injection Attack is, we need to have a brief primer on how User Interfaces typically communicate with the backend or database:

要了解什么是SQL注入攻击，我们需要简要了解一下用户界面通常如何与后端或数据库进行通信：

When a user submits a form, or takes some other action requiring feedback from the backend, that data is communicated either with the help of an API or with a language like PHP that communicates on the server level but is triggered in-browser.

当用户提交表单或采取其他措施要求后端提供反馈时，该数据将在API的帮助下或在服务器级别进行通信但在浏览器内触发PHP之类的语言进行通信。

In the case of an API, the browser sends a request to an endpoint that contains all of the data needed to fulfill a request. The API then sends a response, and the code in the webpage handles the received data. With PHP, the code that speaks to the server is loaded by the webserver itself and is triggered by calling the file name from the browser. For example, to submit a form, a file named ‘submit.php’ could be declared as the ‘action’ in the HTML of the form. When the user clicks the button to submit, that file is then called and parameters are sent either through POST data, or as URL parameters in a GET request.

在使用API​​的情况下，浏览器将请求发送到包含满足请求所需的所有数据的端点。 然后，API发送响应，网页中的代码将处理收到的数据。 使用PHP，与服务器对话的代码由Web服务器本身加载，并通过从浏览器调用文件名来触发。 例如，要提交表单，可以在表单HTML中将名为“ submit.php”的文件声明为“操作”。 当用户单击按钮提交时，将调用该文件，并通过POST数据或作为GET请求中的URL参数发送参数。

On the server, let’s say the data is being used to query a database. The unsafe way to do this, that opens the application up to an injection attack, is to simply interpolate the supplied data into the database query (most commonly a SQL query).

假设在服务器上，数据被用于查询数据库。 使应用程序容易受到注入攻击的不安全方法是简单地将提供的数据插值到数据库查询(最常见的是SQL查询)中。

一个简单的例子 (A Simple Example)

Here’s an example of some server side code that might handle the request:

这是一些可能处理请求的服务器端代码的示例：

You can see that the $size variable, which is coming from the request, is essentially being placed into the query without transforming the data contained whatsoever. This means that an attacker can place whatever data they would like into the query. Notice that the $size variable is enclosed in single quotes in the query. The query is expecting a string enclosed in these quotes, and will accept anything provided so long as it is the correct syntax. You might also notice that the SQL query isn’t explicitly closed with a semicolon, which is also bad practice.

您可以看到，来自请求的$ size变量实际上已放入查询中，而不会转换任何包含的数据。 这意味着攻击者可以将他们想要的任何数据放入查询中。 请注意，$ size变量在查询中用单引号引起来。 该查询期望这些引号中包含一个字符串，并且将接受所提供的任何内容，只要它是正确的语法即可。 您可能还会注意到，SQL查询没有用分号显式关闭，这也是一种不好的做法。

让我们利用它！ (Let’s exploit it!)

With this code, there’s nothing stopping an attacker from sending something this with the request:

使用此代码，没有什么可以阻止攻击者通过请求发送此信息：

size=’ OR 1=1; —

size ='OR 1 = 1; -

which would transform the query into this:

它将查询转换为：

SELECT id, name, inserted, size FROM products WHERE size =’’ OR 1=1; —

在产品尺寸=''或1 = 1的情况下，从产品中选择ID，名称，插入的尺寸-

This transforms the intended query into something unintended; the query now returns every record because the OR statement says ‘if the size is this, or 1=1’. Well, 1 does equal 1, so all records match that query. The double hyphens comment out anything following, essentially blocking it from being part of the query.

这会将预期的查询转换为意外的内容。 查询现在返回每条记录，因为OR语句显示“如果大小是这个值，或者1 = 1”。 好吧，1等于1，因此所有记录都与该查询匹配。 双连字符会注释掉后面的所有内容，从本质上阻止了它成为查询的一部分。

Something more malicious might take the form of this request:

更恶意的内容可能采取以下要求的形式：

size=’; DROP TABLE products;

size ='; DROP TABLE产品；

Which would execute a query to drop the products table after executing the first query.

在执行第一个查询后，该查询将执行查询以删除产品表。

The possibilities are endless. An attacker can query tables like information_schema.tables to see which tables are in a database, and then begin to enumerate those tables without having any prior knowledge of how the database is setup. This is how user data is stolen and data is manipulated.

可能性是无止境。 攻击者可以查询诸如information_schema.tables之类的表来查看数据库中有哪些表，然后开始枚举这些表，而无需事先了解如何设置数据库。 这就是窃取用户数据和处理数据的方式。

预防 (Prevention)

So how can you stop something like this from happening? Sanitize user input, and don’t plug data directly into a SQL query. Sanitization just means either removing or ‘escaping’ characters that can mess with a query (like quotes, hyphens, and semicolons). You can avoid plugging data directly into a query by using an ORM library, or Object-Relation Mapping, in your code which provides a layer of abstraction from the raw queries and will often come with built-in protections from injection attacks and other vulnerabilities.

那么如何阻止这种事情发生呢？ 清理用户输入，不要将数据直接插入SQL查询。 清理只是意味着删除或“转义”会干扰查询的字符(例如引号，连字符和分号)。 您可以避免在代码中使用ORM库或对象关系映射将数据直接插入查询中，该代码提供了原始查询的抽象层，并且通常带有针对注入攻击和其他漏洞的内置保护。

结论 (Conclusion)

That’s basically it. In the wild, these injection points are often hard to reach and take lots of trial and error and special tooling to uncover due to the age and exposure of the vulnerability. But, they’re still out there, ready to be exploited by those with the time and knowledge.

基本上就是这样。 在野外，由于漏洞的年龄和暴露程度，通常很难到达这些注入点，并且需要进行大量的反复试验和特殊工具才能发现。 但是，它们仍然存在，随时可供有时间和知识的人利用。

翻译自: https://medium.com/@c.andrewlong/security-basics-sql-injection-7a1f75ab3a5d

sql注入 安全