Apache 日志文件中的奇怪引荐来源网址：空字符串和看起来像 MySQL 的代码
Strange referers in Apache logfiles: empty string and what looks like MySQL code
我已将我的日志文件读入 R，当我查看 referer 时，有一些奇怪的条目：
> logs <- read.table("logfile")
> referer <- data.frame(table(logs$referer))
> head(referer, 2)
Var1 Freq
1 157
2 - 250290
Apache 使用破折号 (-) 来表示缺少的引荐来源网址。那是第 2 行。那么第 1 行中的空字符串 (``) 是什么意思？正如我所见，这只有在 Apache "forgot" 将 referer 写入日志文件时才会发生。
这是 157 个带有空 referer 字符串的条目之一（我已经匿名化了客户端 ip 和我的网站 URL）：
173.244.xxx.xxx - - [17/Apr/2018:08:07:46 +0200] "GET /feeds/atom.xml HTTP/1.1" 200 18820 www.my-website.com "" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36; +collection@infegy.com" "-"
但最神秘的引荐来源是这样的：
554fcae493e564ee0dc75bdf2ebf94caads|a:2:{s:3:"num";s:280:"*/ union select 1,0x272f2a,3,4,5,6,7,8,0x7b24617364275d3 ...
我把末尾的字符串截掉了（它持续了相当长的时间），因为我不知道它是否包含敏感信息。我有大约 20 次这样的 referer 访问，都来自同一个客户端 ip，其中大多数请求的资源在我的服务器上不存在，例如 //user.php 和 //cm.php.
在我看来，这些至少部分是 MySQL 查询。 a:2:{s:3:"num";s:459:" 是序列化数组的开头。我使用这种格式将 Web 表单中的一些数据存储在 MySQL 数据库中。但是这个处理发生在服务器端，永远不会发送到用户的浏览器。无论如何，MySQL 查询如何最终成为引荐来源网址？我可以理解有人可能会尝试将 MySQL 代码输入到网络表单中，但这并不构成引荐来源网址的一部分。
任何解释都很好。
这看起来像是 SQL 注入尝试。如果 SQL 尝试成功，日志将不会显示。
虽然这通常会显示在 URL 字段中，但没有理由不显示在您日志中的 HTTP 引荐来源网址字段中。
这是针对内部基础设施的攻击。许多组织使用集中式系统来获取日志，然后使用报告基础设施来支持查询日志。开发人员在设计安全系统方面相当糟糕，Referer 领域的 SQL 正试图利用这一点。
攻击者还可以尝试将片段存储在 Referer 字段中，然后将其用于其他类型的攻击。
只要您没有使用制作不良的软件来查询日志，就应该没问题。
这 — https://resources.infosecinstitute.com/sql-injection-http-headers/ — 提供了一些进一步的信息。
此外，如评论中所述，考虑用户 webreadr 读取网络服务器日志文件。
而且，经过进一步审查，这似乎是一个攻击者团体发起的一场活动，旨在破坏 "Ecshop" 内容管理系统 (https://github.com/SecWiki/CMS-Hunter/tree/master/Ecshop/ecshop2.x_code_execute)。如果您是 运行，您可能需要对您的服务器进行三重检查。
我已将我的日志文件读入 R，当我查看 referer 时，有一些奇怪的条目：
> logs <- read.table("logfile")
> referer <- data.frame(table(logs$referer))
> head(referer, 2)
Var1 Freq
1 157
2 - 250290
Apache 使用破折号 (-) 来表示缺少的引荐来源网址。那是第 2 行。那么第 1 行中的空字符串 (``) 是什么意思？正如我所见，这只有在 Apache "forgot" 将 referer 写入日志文件时才会发生。
这是 157 个带有空 referer 字符串的条目之一（我已经匿名化了客户端 ip 和我的网站 URL）：
173.244.xxx.xxx - - [17/Apr/2018:08:07:46 +0200] "GET /feeds/atom.xml HTTP/1.1" 200 18820 www.my-website.com "" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36; +collection@infegy.com" "-"
但最神秘的引荐来源是这样的：
554fcae493e564ee0dc75bdf2ebf94caads|a:2:{s:3:"num";s:280:"*/ union select 1,0x272f2a,3,4,5,6,7,8,0x7b24617364275d3 ...
我把末尾的字符串截掉了（它持续了相当长的时间），因为我不知道它是否包含敏感信息。我有大约 20 次这样的 referer 访问，都来自同一个客户端 ip，其中大多数请求的资源在我的服务器上不存在，例如 //user.php 和 //cm.php.
在我看来，这些至少部分是 MySQL 查询。 a:2:{s:3:"num";s:459:" 是序列化数组的开头。我使用这种格式将 Web 表单中的一些数据存储在 MySQL 数据库中。但是这个处理发生在服务器端，永远不会发送到用户的浏览器。无论如何，MySQL 查询如何最终成为引荐来源网址？我可以理解有人可能会尝试将 MySQL 代码输入到网络表单中，但这并不构成引荐来源网址的一部分。
任何解释都很好。
这看起来像是 SQL 注入尝试。如果 SQL 尝试成功，日志将不会显示。
虽然这通常会显示在 URL 字段中，但没有理由不显示在您日志中的 HTTP 引荐来源网址字段中。
这是针对内部基础设施的攻击。许多组织使用集中式系统来获取日志，然后使用报告基础设施来支持查询日志。开发人员在设计安全系统方面相当糟糕，Referer 领域的 SQL 正试图利用这一点。
攻击者还可以尝试将片段存储在 Referer 字段中，然后将其用于其他类型的攻击。
只要您没有使用制作不良的软件来查询日志，就应该没问题。
这 — https://resources.infosecinstitute.com/sql-injection-http-headers/ — 提供了一些进一步的信息。
此外，如评论中所述，考虑用户 webreadr 读取网络服务器日志文件。
而且，经过进一步审查，这似乎是一个攻击者团体发起的一场活动，旨在破坏 "Ecshop" 内容管理系统 (https://github.com/SecWiki/CMS-Hunter/tree/master/Ecshop/ecshop2.x_code_execute)。如果您是 运行，您可能需要对您的服务器进行三重检查。