2

黑客到达了我的数据库用户列表和其他表。

首先,我通过使用在所有事务中使用参数化命令

command.Parameters.Add("@Parameter1", SqlDbType.NVarChar).Value

所有事务都是存储过程。

我将每个站点导航插入数据库。具体数据库表如下;

ID int (PK)
UserID int (null)
URL nvarchar(500)
IPAddress nvarchar(25)
CreatedAt datetime

项目UserID从代码中获取信息是否打开了会话。

CreatedAtDateTime.UtcNow

IPAddress代码如下:

public static string GetIPAddress(HttpContext context)
{
    string ipAddress = context.Request.ServerVariables["HTTP_X_FORWARDED_FOR"];

    if (!string.IsNullOrEmpty(ipAddress))
    {
        string[] addresses = ipAddress.Split(',');
        if (addresses.Length != 0)
            return addresses[0];
    }

    return context.Request.ServerVariables["HTTP_CLIENT_IP"] ?? context.Request.ServerVariables["REMOTE_ADDR"];
}

但是URL,从网站当前 URL 填充所有查询字符串。( Request.RawUrl)

通常,当用户访问该站点时,如上所述,Log 会插入到数据库中。正常插入以下记录。示例数据如下所示:

ID      UserID    URL                        IPAddress      CreatedAt
1        NULL     /User                      1.22.33.444    2019-12-12 16:22:33.441
2        NULL     /User/MyOrders             1.22.33.444    2019-12-12 16:24:33.441
3        NULL     /User?utm_source=email     1.22.33.444    2019-12-12 16:29:33.441

黑客以某种方式将一条记录插入数据库,如下所示:

ID      UserID    URL                        IPAddress                     CreatedAt
4        NULL     /User                      (select(0)from(select(sle     2019-12-12 17:22:33.441
5        NULL     /User/MyOrders             -1; waitfor delay '0:0:9'     2019-12-12 17:24:33.441
6        NULL     /User?utm_source=email     prvNA0R6'; waitfor delay      2019-12-12 17:29:33.441
7        NULL     /User?utm_source=email     -1' OR 2+198-198-1=0+0+0+     2019-12-12 17:29:33.441

如您所见IPAddress,专栏是 SQL 查询攻击。IPAddress字段长度限制为 25 个字符。以下 SQL 查询文本被 SQL 截断。

URL在我看来,黑客通过更改或IPAddress作为 SQL 脚本使用 SQL 注入来获取数据库记录。

知道黑客是如何到达我的数据库的,以及从现在开始如何避免攻击吗?

编辑

存储过程如下:

create procedure SP_InsertLogNavigation
    @URL nvarchar(150),
    @UserID int,
    @IPAddress nvarchar(25),
    @CreatedAt datetime
as
    insert into LogNavigation (URL, UserID, IPAddress, CreatedAt)
    values (@URL, @UserID, @IPAddress, @CreatedAt)

存储过程的用法如下:

public bool Save(LogNavigation logNavigation)
{
    int affectedRows = 0;

    InitializeSqlFields("SP_InsertLogNavigation");

    command.Parameters.Add("@URL", SqlDbType.NVarChar).Value = logNavigation.URL;
    command.Parameters.Add("@UserID", SqlDbType.Int).Value = Validation.IsNull(logNavigation.UserID);
    command.Parameters.Add("@IPAddress", SqlDbType.NVarChar).Value = logNavigation.IPAddress;
    command.Parameters.Add("@CreatedAt", SqlDbType.DateTime).Value = logNavigation.CreatedAt;

    try
    {
        Connect();

        affectedRows = command.ExecuteNonQuery();
    }
    catch (SqlException)
    {
    }
    finally
    {
        Disconnect();
    }

    return affectedRows != 0;
}
4

1 回答 1

8

所以我断言你实际上并没有屈服于 SQL 注入攻击。如果您只使用参数化查询,则攻击者试图获得访问权限但失败了。

但是,您的表之所以出现攻击尝试,是因为这些代码行:

string ipAddress = context.Request.ServerVariables["HTTP_X_FORWARDED_FOR"];

return context.Request.ServerVariables["HTTP_CLIENT_IP"] ?? context.Request.ServerVariables["REMOTE_ADDR"];

您必须了解,客户几乎可以完全控制提交给您网站的标头。攻击者可以将标头修改为他们想要的任何值。

这些参数由客户端在其请求中提供:

HTTP_X_FORWARDED_FOR
REMOTE_ADDR
HTTP_CLIENT_IP

在您的情况下,攻击者提供了包含 SQL 注入代码的欺骗标头,您已将其忠实地放置在 IP 地址列中的数据库中。

在评论中编辑以下 OP 查询

OP问:

太好了,但我只有一个问题。她/他如何将超过 25 个字符传递到我的服务器端

请求标头没有指定的大小限制,尽管它们是各种实现应用的实际限制(即 Apache 中的 8Kb)。客户端可以发送任何长度的请求标头,不超过您的网站主机软件允许的长度。

但是,由于您的 SP 配置了最大长度为 25 个字符的参数,因此溢出的文本在持久保存到数据库时会被截断。

于 2019-12-17T08:59:10.950 回答