SQL注入和两个查询

发布于 2024-08-19 05:17:36 字数 365 浏览 1 评论 0原文

因此,我阅读了有关 SQL 注入的文章,其中有一个示例:

SELECT * FROM table_name WHERE smth = 'x'; 
UPDATE table_name SET smth ='[email protected]' WHERE user = 'admin';

Why it does not work?或者这是一篇旧文章,现在这种方式是无稽之谈?那么黑客是如何更新mysql的呢? 谢谢。

So, I read article about SQL injection and there was an example:

SELECT * FROM table_name WHERE smth = 'x'; 
UPDATE table_name SET smth ='[email protected]' WHERE user = 'admin';

Why it doesn't work? Or it is an old article and nowadays this way is nonsense? So how hackers update mysql then?
Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

芸娘子的小脾气 2024-08-26 05:17:36

现在大多数站点都使用参数化 SQL,而不是内联 SQL。例如,如果有解析的内联 SQL,类似于以下内容,就会出现上述情况:

非参数化伪

string sql = "SELECT * FROM table_name WHERE smth='" + UserInput + "'";
ExecuteSql(sql);

...其中 UserInput 定义网站上的元素。

您不是向 UserInput 字段添加有效数据,而是添加

UserInput = '';DROP table_name;

...实际上是在查询末尾添加新逻辑,从而导致系统被恶意使用。

参数化语句消除了 SQL 注入的可能性,因为您无法通过将逻辑插入到签名中来修改查询的结构。

如果您尝试将 UserInput 字段设置为恶意查询,但站点在语句中使用了参数,那么您就不走运了。

参数化伪:

Adapter proc;
proc.StoredProcedure = "GetUserNames"
proc.AddParameter("@USER",UserInput);
proc.Execute();

...因为 @USER 现在等于文字“'\;DROP table_name;”,SQL 将其视为常规 ol' 参数。

Most sites nowadays are using parametized SQL -- not inline SQL. The situation would occur above if for instance, there was parsed, inline SQL, similar to the following:

Non-Parameterized Pseudo

string sql = "SELECT * FROM table_name WHERE smth='" + UserInput + "'";
ExecuteSql(sql);

...where UserInput defines an element on the website.

Instead of adding valid data to the UserInput field, you add,

UserInput = '';DROP table_name;

...you would actually be adding new logic to the end of the query, resulting in a malicious use of the system.

Parametized statements eliminate the possibility of SQL injection, since you can't modify the structure of the query by inserting logic into the signature.

If you attempted to set the UserInput field to a malacious query, but the site used parameters in the statement, then you would be out of luck.

Parameterized Pseudo:

Adapter proc;
proc.StoredProcedure = "GetUserNames"
proc.AddParameter("@USER",UserInput);
proc.Execute();

...as @USER is now equal to the literal "'\;DROP table_name;", which the SQL will treat as a regular ol' parameter.

江心雾 2024-08-26 05:17:36

这取决于您如何执行上面的代码。

许多代码语言都有专用的数据库通信类,您可以使用 sql 参数而不是连接字符串来提供这些通信类。

SQL 注入的风险是忘记转义查询中的某些用户输入,从而允许执行格式错误的查询。

It depends on how you execute the code above.

Many code languages have dedicated database communication classes which you can supply with sql parameters instead of concatenated strings.

The risk in SQL injection is forgetting to escape some of the user input in your query thus allowing malformed queries to be executed.

深巷少女 2024-08-26 05:17:36

SQL 注入攻击背后的想法是这样的:

我有一个网站,让用户搜索有关动物的信息。用户输入动物的名称,然后运行:

select * from animals where name = '$[what the user typed in]';

因此,如果他们输入绵羊,查询将变为:

select * from animals where name = 'sheep';

但是,如果他们输入:“绵羊”会怎样?掉落桌子动物'?如果我只是复制他们在查询中输入的内容并运行它,我将运行:

select * from animals where name = 'sheep'; drop table animals;

这会很糟糕。

如果设置网站和数据库的人员不仔细查找和清理用户输入内容中的任何 SQL,这种攻击仍然可能发生。

The idea behind SQL injection attacks is this:

I have a website that let's users searching for information about animals. The user types in the name of the animal, then it runs:

select * from animals where name = '$[what the user typed in]';

so if they type in sheep, the query becomes:

select * from animals where name = 'sheep';

However, what if they type in: `sheep'; drop table animals'? If I simply copy what they typed into the query and run it, I'll run:

select * from animals where name = 'sheep'; drop table animals;

which would be bad.

This kinds of attacks can still happen if the person setting up the website and database isn't careful to look for and clean up any SQL that is in something the user enters.

红尘作伴 2024-08-26 05:17:36

DB 101 强烈警告 SQL 注入,因此现在大多数开发人员都意识到了这一点并阻止了它。这通常是通过使用某种预准备语句来完成的,其中参数是通过防止执行任意 SQL 的机制注入的。惰性编程仍然会导致漏洞,而且它们确实存在,但盲目的动态 SQL 构建越来越少见。

DB 101 warns ardently about SQL injection, so most developers these days are aware of it and prevent it. This is most often done by using some sort of prepared statement where your parameters are injected via a mechanism that prevents arbitrary SQL from being executed. Lazy programming can still lead to vulnerabilities and they're out there, for sure, but blind dynamic SQL building is rarer and rarer.

甜是你 2024-08-26 05:17:36

当您有查询“模板”并且需要用户输入来填写某些查询时,SQL 注入攻击就可能发生。例如,您可能有一个执行以下操作的 PHP 脚本:

<?php
$smth_value = $_POST["smth"];  // some form field
$smth_user  = $_POST["user"];  // some other form field
$smth_email = $_POST["email"]; // yet another form field

$sql1 = "SELECT * FROM table_name WHERE smth = '".$smth_value."'";  
$sql2 = "UPDATE table_name SET smth ='".$smth_email."' WHERE user = '".$smth_user."'";

mysql_query($sql1);
mysql_query($sql2);    
?>

如果某人知道我的表的结构(或以某种方式弄清楚了),他们可以通过将 SQL 文本放入表单字段来“注入”SQL 到我的查询中结果我的 SQL 变量字符串看起来像两个用分号分隔的有效查询。例如,某人可以在“smth”表单字段中输入如下内容:

';DELETE FROM table_name WHERE 1=1 OR smth='

然后 $sql1 最终会看起来像:

SELECT * FROM table_name WHERE smth = '';DELETE FROM table_name WHERE 1=1 OR smth=''

... 然后就会出现 table_name 中的所有数据。

这就是为什么 PHP 中有像 mysql_escape_string 这样的函数来帮助保护字符串免受此类攻击。如果您知道变量应该是数字,请将其转换为数字。如果有文本,请将其包装在字符串转义函数中。这就是防御的基本思路。

SQL injection attacks are possible when you have query "templates" and you require user input to fill in some of the query. For example, you might have a PHP script that does something like this:

<?php
$smth_value = $_POST["smth"];  // some form field
$smth_user  = $_POST["user"];  // some other form field
$smth_email = $_POST["email"]; // yet another form field

$sql1 = "SELECT * FROM table_name WHERE smth = '".$smth_value."'";  
$sql2 = "UPDATE table_name SET smth ='".$smth_email."' WHERE user = '".$smth_user."'";

mysql_query($sql1);
mysql_query($sql2);    
?>

If an individual knew the structure of my table (or figured it out somehow), they could "inject" SQL into my queries by putting SQL text into the form fields that results in my SQL variable strings looking like two valid queries separated by a semicolon. For example, someone could type into the "smth" form field something like:

';DELETE FROM table_name WHERE 1=1 OR smth='

and then $sql1 would end up looking like:

SELECT * FROM table_name WHERE smth = '';DELETE FROM table_name WHERE 1=1 OR smth=''

... and there goes all the data from table_name.

That's why there are functions in PHP like mysql_escape_string to help guard strings from these kind of attacks. If you know a variable is supposed to be a number, cast it to a number. If you have text, wrap it in a string escaping function. That's the basic idea on how to defend.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文