Coldfusion SQL 注入?未通过 Web 应用程序检查
Coldfusion SQL injection? failing a web application inspection
好吧,我很困惑,我有一个 CF11 Web 应用程序未通过 SQL 注入的 Web 应用程序审计报告,该报告由 Acunetix 制作。
无论如何,该报告在我的网站上提供了 10 个易受 sql 注入攻击的页面,但我检查了代码,实际上我在每个这些实例中都使用了 cfqueryparam
处理程序调用的查询之一示例
<cfquery datasource="#application.DSN#" name="qResult" result="r">
update #table# s
set s.loader_status = <cfqueryparam cfsqltype="cf_sql_varchar" value="#ucase(arguments.status)#">
<cfif isDefined("bio_loader_status") and bio_loader_status neq ''>
, s.bio_loader_status = <cfqueryparam cfsqltype="cf_sql_varchar" value="#ucase(bio_loader_status)#">
</cfif>
, s.session_id = NULL
, s.session_expiration = NULL
<cfif isDefined("arguments.rowid") and arguments.rowid neq ''>
where s.rowid = CHARTOROWID(<cfqueryparam cfsqltype="cf_sql_varchar" value="#arguments.rowid#">)
</cfif>
</cfquery>
我读过的所有内容都告诉我,我可以免受 sql 攻击(使用 cfquery 参数、使用 datasurce 和 table 变量等),但该报告声称并非如此
URL encoded GET input rowid was set to 1'"
Error message found: Error Executing Database Query
GET /index.cfm/status?rowid=1'%22&type=billing HTTP/1.1
任何人都可以阐明我做错了什么吗?还是报告的假设不正确?
进一步证明 Alex 的断言:
They want you to graciously handle the fact that rowid is not a number, they don't want to see the standard error message
我以前的雇主对他们的应用程序进行定期渗透测试(渗透测试)。 CF 输出的错误消息只会在屏幕上呈现攻击字符串。这适用于您需要或希望调试信息显示在屏幕上的非生产、非 QA 环境。在生产中,您永远不想透露代码在哪里出错。
错误消息 GET /index.cfm/status?rowid=1'%22&type=billing HTTP/1.1
告诉攻击者可以进一步攻击哪个文件及其路径,以及 URL 参数。如果此文件包含在您的请求堆栈中并且可以直接请求该文件,那么您可能会面临进一步的攻击。您需要捕获此错误并输出一条消息。
如果您必须登录才能访问此 URL,那是一回事。 public URL 不应该包含任何特定于该问题的信息。不要输出类似 The rowID must be an Integer
或 rowID is invalid
的内容。那只会引起更多的攻击。 Invalid request
适用于 public URL 错误。
现在,对于 <cfqueryparam>
实际上无法阻止注入攻击的情况。我以前公司的一些遗留存储过程使用动态 SQL。很像在 CF 中,字符串将在 proc 内连接起来,SQL 执行命令将 运行 最终的 SQL 字符串。可以将编码的字符串传递给 <cfqueryparam>
,然后将其拼凑在一起时注入到 proc 内的 SQL 字符串中。为此,我们不得不更新成堆的旧过程来验证字符串参数,寻找要拒绝的特定字符串。
如果可能,您应该向我们的堆栈添加一个 Web Application Firewall to your infrastructure. The Online ColdFusion Meetup Group is having a presentation on one software based WAF for CF applications tomorrow. I'm sure it will be recorded if you can't attend. I just last night finished moving my current CF site to AWS, where we made sure to add their WAF 以确保安全。这并不意味着我们不需要正确捕获错误并显示适当的消息,但是当您可以让它在请求到达应用程序服务器之前拒绝已知的攻击向量时,它确实会减轻负载。
好吧,我很困惑,我有一个 CF11 Web 应用程序未通过 SQL 注入的 Web 应用程序审计报告,该报告由 Acunetix 制作。
无论如何,该报告在我的网站上提供了 10 个易受 sql 注入攻击的页面,但我检查了代码,实际上我在每个这些实例中都使用了 cfqueryparam
处理程序调用的查询之一示例
<cfquery datasource="#application.DSN#" name="qResult" result="r">
update #table# s
set s.loader_status = <cfqueryparam cfsqltype="cf_sql_varchar" value="#ucase(arguments.status)#">
<cfif isDefined("bio_loader_status") and bio_loader_status neq ''>
, s.bio_loader_status = <cfqueryparam cfsqltype="cf_sql_varchar" value="#ucase(bio_loader_status)#">
</cfif>
, s.session_id = NULL
, s.session_expiration = NULL
<cfif isDefined("arguments.rowid") and arguments.rowid neq ''>
where s.rowid = CHARTOROWID(<cfqueryparam cfsqltype="cf_sql_varchar" value="#arguments.rowid#">)
</cfif>
</cfquery>
我读过的所有内容都告诉我,我可以免受 sql 攻击(使用 cfquery 参数、使用 datasurce 和 table 变量等),但该报告声称并非如此
URL encoded GET input rowid was set to 1'"
Error message found: Error Executing Database Query
GET /index.cfm/status?rowid=1'%22&type=billing HTTP/1.1
任何人都可以阐明我做错了什么吗?还是报告的假设不正确?
进一步证明 Alex 的断言:
They want you to graciously handle the fact that rowid is not a number, they don't want to see the standard error message
我以前的雇主对他们的应用程序进行定期渗透测试(渗透测试)。 CF 输出的错误消息只会在屏幕上呈现攻击字符串。这适用于您需要或希望调试信息显示在屏幕上的非生产、非 QA 环境。在生产中,您永远不想透露代码在哪里出错。
错误消息 GET /index.cfm/status?rowid=1'%22&type=billing HTTP/1.1
告诉攻击者可以进一步攻击哪个文件及其路径,以及 URL 参数。如果此文件包含在您的请求堆栈中并且可以直接请求该文件,那么您可能会面临进一步的攻击。您需要捕获此错误并输出一条消息。
如果您必须登录才能访问此 URL,那是一回事。 public URL 不应该包含任何特定于该问题的信息。不要输出类似 The rowID must be an Integer
或 rowID is invalid
的内容。那只会引起更多的攻击。 Invalid request
适用于 public URL 错误。
现在,对于 <cfqueryparam>
实际上无法阻止注入攻击的情况。我以前公司的一些遗留存储过程使用动态 SQL。很像在 CF 中,字符串将在 proc 内连接起来,SQL 执行命令将 运行 最终的 SQL 字符串。可以将编码的字符串传递给 <cfqueryparam>
,然后将其拼凑在一起时注入到 proc 内的 SQL 字符串中。为此,我们不得不更新成堆的旧过程来验证字符串参数,寻找要拒绝的特定字符串。
如果可能,您应该向我们的堆栈添加一个 Web Application Firewall to your infrastructure. The Online ColdFusion Meetup Group is having a presentation on one software based WAF for CF applications tomorrow. I'm sure it will be recorded if you can't attend. I just last night finished moving my current CF site to AWS, where we made sure to add their WAF 以确保安全。这并不意味着我们不需要正确捕获错误并显示适当的消息,但是当您可以让它在请求到达应用程序服务器之前拒绝已知的攻击向量时,它确实会减轻负载。