检测 SQL 注入 [英] Detect SQL Injection

查看:22
本文介绍了检测 SQL 注入的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我来到一家已经有一个完全成熟的项目的公司……但在我之前在这里工作的编码人员没有遵循约定,也没有使用参数化 SQL 查询……结果,在我这里有超过 1000 个地方一个非常庞大的项目,可能容易受到 SQL 注入的影响......

I came to a company that already has a fully grown project... but coders that worked here before me didn't follow conventions and didn't use parametrized SQL queries... as a result there is over 1000 places in a very huge project that can possibly be vulnerable to SQL injection...

我需要找到一个能够自动检测代码中是否存在 SQL 注入的解决方案.因此,例如,有一个表单允许用户输入有关产品的评论,该评论将在提交时发送到数据库......我们如何确保用户没有输入有害查询而不是普通文本?

I need to find a solution that will automatically detect if there is an SQL injection in the code. So, for example there is a form which allows user to enter comments regarding a product, which will be sent to database on submit... how can we make sure that a user didn't enter a harmfull query instead of a normal text?

是否有任何高级代码/正则表达式/魔术可以检测此文本是否包含一段 SQL 查询而不是普通无害文本?我将接受任何链接、任何语言的代码片段,甚至可以为我做这些的商业软件.

Is there any advanced code/regular expression/magic that can detect if this text contains a piece of SQL query instead of normal harmless text? I will accept any links, pieces of code in any language or even commercial software that will do that for me.

谢谢

推荐答案

这里没有灵丹妙药.SQL 注入可以以许多模糊的形式出现,并尝试使用正则表达式或防火墙中的其他形式来检测它们,或者应用程序可以保护您免受最简单形式的 SQL 注入,但经验丰富的黑客可以轻松通过.正如 AdaTheDev 已经指出的那样,检查您的代码的自动化工具,例如 MS 代码分析工具,可能会给您一个启动,但同样没有灵丹妙药.您需要完成整个申请.

There is no silver bullet here. SQL injections can come in many obscured forms and trying to detect them using regular expressions or another form in your firewall, or application can protect you from the most simple forms of SQL injection, but an experienced hacker will simply get through. As AdaTheDev already noted, automated tools that inspect your code, such as the MS Code Analysis Tool, might give you a kick start, but again there is no silver bullet. You will need to go through your whole application.

当这是很多工作时,您应该制定计划.首先,制定一个指导方针,说明如何减轻这些类型的攻击.还尝试将您的应用程序分成几个部分,从非常关键到不太关键.通过这种方式,您可以更好地估算修复错误的成本,并让管理层决定可能要花费的成本以及他们愿意承担的风险.未经身份验证的用户可以访问的应用程序部分是最关键的.如果每个人(在世界上)都可以在您的应用程序中创建一个帐户,那么这些用户可以访问的所有功能都非常重要.人口越少,您越信任这些用户,风险就越小.您也许可以稍后修复这些部件.但永远不要低估一个好的黑客.他/她可能会破坏具有高权限的用户的帐户,并使用该帐户开始测试 SQL 注入的可能性.

When this is a lot of work, you should make a plan. First of all, make a guideline that states how these types of attacks can be mitigated. Also try to divide your application in parts, from very critical to less critical. This way you can better estimate the costs of repairing the bugs and can let management decide what it may cost and thus what risk they are willing to take. Parts of your application that unauthenticated users can access are most critical. If everybody (in the world) can create an account in your application, all functionality that these users can access is highly critical. The smaller the population and the more you trust those users, the smaller the risk. You perhaps can get away with fixing these parts later. But never underestimate a good hacker. He/she might be able to compromise the account of a user with high privilege and start testing for SQL injection possibilities using that account.

始终尝试采用纵深防御策略,拥有多层(或多层)防御.例如,永远不要从应用程序中以 SA 的身份连接到您的数据库.创建一个仅具有所需权限的帐户,甚至可能创建多个 SQL 帐户,每个角色(或一组角色)一个帐户.虽然限制对数据库的权限对降低风险有很大帮助,但同样,不要将其视为单层防御.例如,本文解释了黑客如何滥用当她能够进行 SQL 注入时,使用较低权限的帐户.

Always try to have a defense in depth strategy, have multiple (or many) layers of defence. For instance, do never connect with your database as SA from within your application. Create an account with just the privileges that are needed and perhaps even create multiple SQL accounts, one account per role (or per a group of roles). While restricting the privileges to the database help a lot in mitigating the risk, again, don't bet on it as a single layer of defense. This article for instance, explains how a hacker can abuse a lower privilege account when she's able to do SQL injection.

很佩服你在这里问这个问题,因为我过去见过很多开发人员只是不想知道,这很可怕,因为企业经常信任它的开发人员(这也很可怕)).

It is admirable that you ask this question here, because I’ve seen many developers in the past who just don’t want to know, which is very scary, because the business often trusts its developers (which is scary as well).

祝你好运.

这篇关于检测 SQL 注入的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆