清理用户创建的动态 SQL 查询。只允许 SELECT(不允许 INSERT、UPDATE、DELETE、DROP、EXEC 等...)

发布于 2024-10-18 14:13:03 字数 1087 浏览 2 评论 0原文

我正在使用 Microsoft SQL Server 2005 数据库开发一个 ASP2.0 网站。 我需要实现一个功能,允许用户创建一个选择查询(不要太复杂),以便网站显示带有查询结果集的页面。 我的问题是如何清理查询以确保没有插入/更新/删除/删除或其他恶意注入。

另外,我需要将查询封装在“with”子句中,以便我可以将标识列添加到结果集中。 (我需要它才能在页面上正确显示结果)

用于格式化查询的 CSharp 代码如下所示(稍微简化):

string query = txtQuery.Text;
query = query.ToLower();
query = query.Trim();
int orderByIndex = query.LastIndexOf("order by");
string orderBy = "";
if (orderByIndex != -1)
{
    orderBy = query.Substring(orderByIndex);
    query = query.Replace(orderBy, "");
}
query = "with query as (" + query + ") select row_number() over(order by (select 0)) as rowID, * from query " + orderBy;

我想创建一个存储过程来执行查询。我在想这样的事情:

CREATE PROCEDURE usp_execute_query
@sql nvarchar(max)
with execute as 'RestrictedUser'
as
begin
    exec sp_executesql @sql
end

RestrictedUser 看起来像这样:

CREATE USER RestrictedUser WITHOUT LOGIN
EXEC sp_addrolemember db_datareader, RestrictedUser

我的问题是: 有没有办法检查存储过程中 RestrictedUser 的角色以确保它们没有被篡改?如果有的话,就会引发错误。 你认为这整件事是正确的做法吗?有什么建议吗?

I am developping an ASP2.0 website with a Microsoft SQL server 2005 Database.
I need to implement a functionality which allows users to create a select query (nothing too complex) so that the website displays a page with the result set of the query.
My question is how can I sanitize the query to make sure there is no insert/update/delete/drop or other nefarious injection.

also, I need to encapsulate the query in a "with" clause so that I can add an identity column to the result set. (I need that to display the results correctly on the page)

my CSharp code to format the query looks like this (simplified a little):

string query = txtQuery.Text;
query = query.ToLower();
query = query.Trim();
int orderByIndex = query.LastIndexOf("order by");
string orderBy = "";
if (orderByIndex != -1)
{
    orderBy = query.Substring(orderByIndex);
    query = query.Replace(orderBy, "");
}
query = "with query as (" + query + ") select row_number() over(order by (select 0)) as rowID, * from query " + orderBy;

I want to create a stored procedure to execute the query. I was thinking of something like this:

CREATE PROCEDURE usp_execute_query
@sql nvarchar(max)
with execute as 'RestrictedUser'
as
begin
    exec sp_executesql @sql
end

with RestrictedUser looking like this:

CREATE USER RestrictedUser WITHOUT LOGIN
EXEC sp_addrolemember db_datareader, RestrictedUser

My questions are:
Is there a way to check the roles of RestrictedUser within the stored procedure to make sure they haven't been tampered? And raiserror if they have.
Do you think this whole thing is the right way to go? Any suggestion?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

落墨 2024-10-25 14:13:03

危险威尔·罗宾逊!每当您允许用户传递任意 SQL 时,您都会遇到各种安全问题。堵住每个洞的可能性很小。另外,“清理”查询的能力取决于您解析查询的能力。您可以自己解析 SQL,但无论怎么想都不是微不足道的。另外,因为这是一个 Web 应用程序,所以您需要将自己的技能与许多可能更有执行 SQL 注入攻击经验的人进行比较。

创建具有非常有限的权限的用户是一件好事(并且可能是您最好的选择)。但是,您需要对他们有权访问的内容(系统存储过程、系统视图等)非常挑剔。换句话说,db_datareader 不够受到足够的限制。您需要创建一个全新的规则,并只授予他们对非常特定项目的权限。

请记住,即使您可能成功地限制了用户(在这种情况下也称为黑客)可以看到的数据片段,您仍然容易受到 DOS(拒绝服务)攻击。

Danger Will Robinson! Any time you're allowing a user to pass arbitrary SQL, you're running into all sorts of security issues. The odds of you plugging every hole are slim. Plus, the ability to "sanitize" a query is predicated on your ability to parse the query. It is possible to parse SQL yourself, but it's not trivial by any stretch of the imagination. Also, because this is a web app, you're pitting your skills against a lot of people with probably more experience performing sql injection attacks.

Creating the user with very limited permissions is a good thing (and likely your best shot). However, you will need to be fastidious about what they have access to (system stored procs, system views, etc). In other words, db_datareader is not limited enough. You'll want to create an entirely new rule and only given them permission to very specific items.

Keep in mind that even though you might succeed in limiting what pieces of data the user (aka hacker in this scenario) can see, you're still vulnerable to DOS (Denial of Service) attacks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文