我需要在我们被分配维护的非IT应用中修复一些安全问题。它位于Microsoft Access前端(SQL Server后端)。
有没有人知道SQL注入是否可以通过Microsoft Access控件的RecordSource或RowSource属性完成?例如,如果我将列表框的记录源设置为
Me.SomeListBox.Recordsource = 'SELECT * FROM SomeTable WHERE SomeField = ''' & Me.txtSomeTextBox & '''.
我不确定微软是否已针对这些属性进行内置预防,因此我想知道是否应该通过清理功能运行Me.txtSomeTextBox。
这当然是一个快速修复...应用程序将在今年晚些时候重新设计并从Access(yay!)迁移出来。
先谢谢你们!
答案 0 :(得分:2)
可以使用VBA消除WHERE条件中字段名称的明显使用。
Sub btnLogin_OnClick()
If instr(0, me.txtBox, someFieldName) > 0 Then
Msgbox("Foo Bar!")
Else
Login
End If
End Sub
答案 1 :(得分:1)
在您的情况下,注入无法进入sql server。通过链接表访问本地查询仅限于sql语句。因此,尽管可以“少量”注入到Access中,但是sql字符串不能作为多个sql语句到达SQL服务器,在给定的示例中也无法运行服务器端SQL。
因此,“内置预防”是将此类SQL限制为一个字符串。
因为结果字符串不能是多个sql语句,并且由于文本框结果被“引用”,所以您只能提供字符串表达式作为条件,并且在给定的示例中无法注入sql。 / p>
如果某人可以根据文本框的示例VBA sql + concat发布一个有效的注入示例,那么我无所不能。
因此,虽然在Access中可能发生“一些”注入情况,但您所知道的示例肯定不是我所知道的这种情况。
一个有知识的用户也许可以在该表达式中运行一个VBA()函数,但是他们必须知道实际VBA函数的名称。即使在这种情况下,也不会执行您不希望执行的某些SQL。
我想可以查看删除记录的任何sql字符串,并且可以查看用户提供的值/表达式,但是您给出的示例不是典型的sql注入风险。
答案 2 :(得分:0)
如果你正在进行字符串连接,那么你很容易受到攻击。
答案 3 :(得分:0)
要回答您的原始问题:这取决于控件。列表框和组合框可以将“选择查询”作为其记录源。不是动作查询。
“文本框”控件只能绑定到表格字段。
这些控件对任何最终用户都不可用,因此当它们被编译为.accde文件类型时,它们可以重新定义记录源。
答案 4 :(得分:0)
Me.SomeListBox.Recordsource = 'SELECT * FROM SomeTable WHERE SomeField = ''' & Me.txtSomeTextBox & '''
您可以做一个包装,只是为了避免破坏组成的SQL查询 例如
Me.SomeListBox.Recordsource = 'SELECT * FROM SomeTable WHERE SomeField = ''' & Replace(Me.txtSomeTextBox,"'","''") & '''
在这种情况下,您添加了成对的'符号('->''),查询不会中断。
答案 5 :(得分:0)
将字符串与用户输入串联是危险的!
我设置一个例子。使用此SQL:
CREATE TABLE SomeTable (SomeField varchar(20), read_permission int)
INSERT INTO SomeTable VALUES ('a', 1), ('b', 1), ('c', 0)
此VBA代码:
Private Sub FilterButton_Click()
Me.SomeListBox.RowSource = "SELECT * FROM SomeTable WHERE SomeField = '" & Me.txtSomeTextBox & "' AND read_permission = 1"
End Sub
貌似,您创建了基于行的权限。组合框中仅显示带有read_permission = 1
的行。
但是,如果用户在文本框中输入 ' OR 1=1 OR'
,他突然可以查看所有数据(甚至包括带有read_permission = 0
的行。
在用户输入中用{{1}}替换'
似乎使执行SQL注入更加困难。我找不到任何可以破坏它的字符串。但是最好的主意可能是找到另一种构建sql字符串的方法。
''