sql-injection urls,参数长度是安全问题吗?
我收到很多涉及 SQL 注入尝试的点击,这些尝试涉及越来越长的参数。我限制 php 中的参数将它们转换为正整数或零,但我不确定是否存在某种涉及很长参数的技巧可能会导致我出现问题(缓冲区溢出问题?)。
我知道 php 中的 suhosin 补丁对过长的参数进行了某种修补,尽管我目前还没有这样做。我应该怎样做才能保护自己免受此类情况的影响(来自我的日志)?
ProductId=47&ItemId=-1025+UNION+SELECT+0x6d6567613164756d706572,0x6d6567613264756d706572,0x6d6567613364756d706572,0x6d6567613464756d706572,0x6d6567613564756d706572,0x6d6567613664756d706572,0x6d6567613764756d706572,0x6d6567613864756d706572,0x6d6567613964756d706572,0x6d65676131064756d706572,0x6d65676131164756d706572,0x6d65676131264756d706572,0x6d65676131364756d706572,0x6d65676131464756d706572,0x6d65676131564756d706572,0x6d65676131664756d706572,0x6d65676131764756d706572,0x6d65676131864756d706572,0x6d65676131964756d706572,0x6d65676132064756d706572,0x6d65676132164756--
I'm getting a lot of hits that involve sql injection attempts that involve increasingly long parameters. I am limiting the parameters in php to cast them as positive ints or zero, but I'm not certain that there isn't some kind of trick involving really long parameters that could cause me problems (buffer overflow problems?).
I know that the suhosin patch in php has some kind of patching of excessively long parameters, though I don't have that in place currently. What should I do to protect myself against cases like this (from my logs)?
ProductId=47&ItemId=-1025+UNION+SELECT+0x6d6567613164756d706572,0x6d6567613264756d706572,0x6d6567613364756d706572,0x6d6567613464756d706572,0x6d6567613564756d706572,0x6d6567613664756d706572,0x6d6567613764756d706572,0x6d6567613864756d706572,0x6d6567613964756d706572,0x6d65676131064756d706572,0x6d65676131164756d706572,0x6d65676131264756d706572,0x6d65676131364756d706572,0x6d65676131464756d706572,0x6d65676131564756d706572,0x6d65676131664756d706572,0x6d65676131764756d706572,0x6d65676131864756d706572,0x6d65676131964756d706572,0x6d65676132064756d706572,0x6d65676132164756--
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以使用 intval() 来验证用户输入。如果解析失败,它将以整数形式返回输入或 0。在你的例子中就是后者。
You may use intval() to validate the user input. It will return the input as an integer or a 0 if parsing fails. The latter would be the case in your example.
使用准备好的语句。这些参数在发送到数据库之前会被转义,不会造成任何损害。
更新
相同的机制也可以应用于用户提供的其余内容。
使用
htmlspecialchars()
转义从用户处获得的所有数据。这对于 XSS 攻击也应该是安全的(在大多数情况下)Use prepared statements. The parameters are escaped before send to the database and could not do any damage.
UPDATE
The same mechanism could be applied to the rest of user supplied content too.
Use
htmlspecialchars()
to escape all data, you get from the user. This should also be safe to XSS attacks (in most cases)总是检查所有输入参数。也是为了长度。如果你不信任它,就封锁整个IP。我今天遭受了 100 多次这样的攻击,但由于桌子上有大量“脏话”,我幸存了下来。如果字符串包含任何不良单词 -> 阻止整个 IP。
Well always check all input parameters. Also for length. If you don't trust it, block the whole IP. I had 100+ attacks like this today, but due to an extensive table with "bad words" I survived. If string ontains any bad word->block whole IP.