如何通过过滤php中的URL参数来阻止SQL注入攻击? [英] How to block SQL injection attacks by filtering the URL parameters in php?
问题描述
我目前正受到以下形式的 URL 的攻击:
/act/test.php?CourseId=66'+and(%2f**%2fsElEcT+1+%2f**%2ffRoM(%2f**%2fsElEcT+count(*),%2f**%2fcOnCaT((%2f**%2fsElEcT(%2f**%2fsElEcT(%2f**%2fsElEcT+%2f**%2fcOnCaT(0x217e21,ifnull(MailingDate,char(32)),0x217e21)+%2f**%2ffRoM+contin5_Mailing.Customers+%2f**%2flImIt+1400,1))+%2f**%2ffRoM+information_schema.%2f**%2ftAbLeS+%2f**%2flImIt+0,1),floor(rand(0)*2))x+%2f**%2ffRoM+information_schema.%2f**%2ftAbLeS+%2f**%2fgRoUp%2f**%2fbY+x)a)+and+'1'='1和
/act/index.php?Ad=999999.9+%2f**%2fuNiOn%2f**%2faLl+%2f**%2fsElEcT+0x393133353134353632312e39我希望通过在我的网站的 PHP 处理早期对 url 进行相当简单的验证来阻止这些类型的攻击.</p>
由于这种类型的攻击的特征似乎是%2f*"(意思是/*"，我猜它正在注入注释)，因此我使用了这种对这种特定攻击有效的笨拙方法:
$UrlParms = $_SERVER['REQUEST_URI'];$FoundAnomalies = (strpos($UrlParms, '%2f*'));//* 如果我们发现参数异常如果($FoundAnomalies){LogErrorToFileOnly("BOGUS URL: ".$FoundAnomalies." ".$UrlParms);死()；}将错误记录到文件中并在实际输出任何 HTML 之前终止.这显着降低了我服务器上的 CPU 和内存负载，因为它在实际打开数据库并执行此失败的 SQL 注入后尽早而不是稍后出现故障.
我知道这是一种打地鼠"的方法，但是您能告诉我这是否合理，以及是否还有其他字符串可供查找以指示 SQL 注入攻击?或者向我指出任何可以更好地处理这个问题的通用 php 代码?请注意，我只对在 PHP 执行的早期查看 URL 和参数的代码感兴趣，而对稍后在代码中使用哪些参数是合法的一无所知.
历史注释:我在 15 年前使用 PHP 和 MySQL 编写了这个电子商务代码，它一直运行到今天.但是当时的标准并没有真正考虑到这种安全性，也不知道当时是否存在SQL注入.重写整个网站所付出的努力并不值得，所以请不要劝我擦洗每个单独的参数等等.我今天会写不同的，但我只是想尝试检测 SQL在 php 处理中首先使用简单的 URL 过滤注入然后中止.
最终编辑 5/11/2018:
尽管有反对者，我还是创建了一些 PHP 代码和 Javascript 来很好地解决了这个问题(以及许多相关问题)，并且一直在阻止攻击我的商业网站的活跃黑客.它已经工作了两个月.代码在我的回答中发布在下面.
有些 Web App Firewall 产品使用网址白名单来尝试过滤掉任何未经授权的网址类型.
- 绿色SQL
- Oracle 数据库防火墙
- Apache mod_security
通常，您需要教导"这些防火墙哪些类型的 URL 是合法的，然后防火墙拒绝任何不在白名单 URL 列表中的请求.
但在我看来，修复您的代码以使用 SQL 查询参数比将 WAF 产品集成到您的网站要少得多.
如果您想避免一次重写大量代码，并且您更喜欢打地鼠"方法，我鼓励您一次修复一个 PHP 页面中的代码，因为您检测到尝试SQL注入攻击.当然从 index.php 开始.如果攻击者发现主页可以抵抗 SQL 注入，大多数人可能会认为您的其余页面也是安全的，并转移到其他站点.但您永远不知道，他们可能只是测试您的所有页面.如果您是黑客，不是吗?
这仍然不是一个好计划，因为如果您延迟修复代码，您就会被黑客入侵.但至少它可以随着时间的推移分散工作.
P.S.:您评论说 SQL 注入在 15 年前可能还不是一回事，但事实上:
<块引用>关于 SQL 注入的第一次公开讨论开始于 1998 年左右；例如，Phrack 杂志 1998 年的一篇文章.
那是 20 年前的事了！
参见 https://en.wikipedia.org/wiki/SQL_injection#History
I am currently being attacked with a URL of the form:
/act/test.php?CourseId=66'+and(%2f**%2fsElEcT+1+%2f**%2ffRoM(%2f**%2fsElEcT+count(*),%2f**%2fcOnCaT((%2f**%2fsElEcT(%2f**%2fsElEcT(%2f**%2fsElEcT+%2f**%2fcOnCaT(0x217e21,ifnull(MailingDate,char(32)),0x217e21)+%2f**%2ffRoM+contin5_Mailing.Customers+%2f**%2flImIt+1400,1))+%2f**%2ffRoM+information_schema.%2f**%2ftAbLeS+%2f**%2flImIt+0,1),floor(rand(0)*2))x+%2f**%2ffRoM+information_schema.%2f**%2ftAbLeS+%2f**%2fgRoUp%2f**%2fbY+x)a)+and+'1'='1
and
/act/index.php?Ad=999999.9+%2f**%2fuNiOn%2f**%2faLl+%2f**%2fsElEcT+0x393133353134353632312e39
I wish to block these types of attacks with a reasonably straightforward validation of the url early in the PHP processing of my website.
Since a signature of this type of attack seems to be "%2f*" (meaning "/*" which is injecting a comment, I guess), I used this hamfisted approach which does work for this specific attack:
$UrlParms = $_SERVER['REQUEST_URI'];
$FoundAnomalies = (strpos($UrlParms, '%2f*')); //* If we found anomalies in the parameters
if ($FoundAnomalies)
{
LogErrorToFileOnly("BOGUS URL: ".$FoundAnomalies." ".$UrlParms);
die();
}
which logs the error to a file and dies before actually outputting any HTML. This has significantly reduced the cpu and memory load on my server by failing early and not later after actually opening a database and executing this failed SQL injection.
I know this is kind of a "whack-a-mole" approach, but can you tell me if this seems reasonable and whether there are any other strings to look for that indicate a SQL injection attack? Or point me to any general purpose php code that would handle this better? Note that I am only interested in code that would look at the URL and parameters very early on in the PHP execution and knows nothing about what parameters are legal for use later in the code.
Historic note: I wrote this e-commerce code 15 years ago using PHP and MySQL and it continues to function to this day. However, the standards of the time didn't really consider this type of security, and I don't know if SQL injection even existed at the time. The effort it would take to rewrite the entire website is not really worth it, so please don't admonish me to scrub every individual parameter, etc., etc. I would write it differently today, but I just want to try to detect SQL injection with simple URL filtering first thing in the php processing then abort.
Final edit 5/11/2018:
Despite the naysayers, I have created some PHP code and Javascript that solves this problem (and many related problems) nicely, and has been thwarting the active hackers attacking my commercial website. It has been working for two months now. The code is posted below in my answer.
There are Web App Firewall products that use URL whitelisting as an attempt to filter out any unauthorized types of URLs.
- GreenSQL
- Oracle Database Firewall
- Apache mod_security
Generally you need to "teach" these firewalls what types of URLs are legitimate, and then the firewall rejects any request that isn't in the list of whitelisted URLs.
But in my opinion, fixing your code to use SQL query parameters is less work than integrating a WAF product into your site.
If you want to avoid rewriting lots of code all at once, and you prefer a "whack-a-mole" approach, I encourage you to fix the code in one of your PHP pages at a time, as you detect attempted SQL injection attacks. Start with index.php of course. If attackers sees that the homepage is resistant to SQL injection, most might assume the rest of your pages are secure too, and move on to other sites. But you never know, they might just test all of your pages. If you were a hacker, wouldn't you?
This still isn't a good plan, because you're like to get hacked if you delay fixing your code. But at least it spreads out the work over time.
P.S.: You commented that SQL injection may not have been a thing 15 years ago, but in fact:
The first public discussions of SQL injection started appearing around 1998; for example, a 1998 article in Phrack Magazine.
That's 20 years ago!
See https://en.wikipedia.org/wiki/SQL_injection#History
这篇关于如何通过过滤php中的URL参数来阻止SQL注入攻击?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
