SQL 注入 - 存储过程调用没有危险(在 iSeries 上)?

发布于 2024-07-27 22:15:14 字数 491 浏览 5 评论 0原文

我已经做了一些搜索,但我有一个关于 SQL 注入的具体问题,希望我能得到一些输入,因为我相信我可能在字段数据清理等方面搞错了:-

我有一个 java 程序调用 iSeries 上的存储过程。 存储过程在幕后有 CL/RPG 代码。 存储过程通过参数的方式调用,数据来自网页。 例如,调用如下所示:-

call library.prog('field1Value', 'field2Value')

我是否需要担心通过网站输入“field1Value”等的任何字符,或者因为它是存储过程调用,所以不存在 sql 注入的危险吗? 这是否取决于幕后的 RPG 程序是否在其自己的 SQL 语句中使用“field1Value”作为处理的一部分?

传递到过程中的字段长度是固定长度,因此我们无法将“dodgy”字符转换为它们的 html 等效字符。

感谢任何对此的反馈(不一定是 iSeries 特定的)(我预计这可能是一个愚蠢的问题!)。

I've done some searching around but I have a specific question on SQL Injection and hope I can get some input as I believe I may be getting the wrong end of the stick to do with field data sanitising etc :-

I have a java program calling a stored procedure on an iSeries. The stored procedure has CL / RPG code behind the scenes. The stored procedure is called by way of parameters with the data coming from a web page. For example the call would look like the following:-

call library.prog('field1Value', 'field2Value')

Do I need to worry about any characters entered via the website into 'field1Value' etc or, because it is a stored procedure call, does the danger of sql injection not exist? Does it depend on whether the RPG program behind the scenes uses 'field1Value' in its own SQL statement as part of that processing?

The field lengths passed into the proecdure are fixed length so we cannot, for example, convert 'dodgy' characters into their html equivalent.

Appreciate any (I'm anticipating this might be a stupid question!) feedback (not necessarily iSeries specific) on this.

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

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

发布评论

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

评论(3

薄暮涼年 2024-08-03 22:15:14

除非您使用这些参数在 proc 本身中构造动态 sql,否则您应该没问题,

也不能通过检查参数来清理它,

请参阅此处: SQL teaser..尝试保护这个

下面是sql server语法

我可以像这样

prDropDeadFred ' declare @d varchar(100) select @d = reverse(''elbaTdaB,elbatecin elbat pord'') exec (@d)'

或这样

prDropDeadFred ' declare @d varchar(100) select @d = convert(varchar(100),0x64726F70207461626C65204E6963655461626C652C4261645461626C65) exec (@d)'

或5000种你不知道的其他方式 调用过程关于

unless you are using those parameters to construct dynamic sql in the proc itself you should be fine

also you cannot clean it by checking the parameters

see here: SQL teaser..try protecting this

below is sql server syntax

I can call a proc like this

prDropDeadFred ' declare @d varchar(100) select @d = reverse(''elbaTdaB,elbatecin elbat pord'') exec (@d)'

or like this

prDropDeadFred ' declare @d varchar(100) select @d = convert(varchar(100),0x64726F70207461626C65204E6963655461626C652C4261645461626C65) exec (@d)'

or 5000 other ways that you won't know about

一江春梦 2024-08-03 22:15:14

如果被调用的程序使用输入参数来构造动态 SQL,将信息传递给另一个这样做的程序,或者将其存储在数据库表字段中(稍后在其他程序中用于动态 SQL),那么您可能不安全。

You might NOT be safe, if the called program uses the input parameters to construct dynamic SQL, passes the information to another program that does, or stores it in a database table field which is later used for dynamic SQL in some other program.

不顾 2024-08-03 22:15:14

如果您使用 JDBC CallableStatement,那么您是安全的。 CallableStatement只是PreparedStatement的一个子类型,SQL注入攻击应该是不可能的。 我能想到的唯一方法是,如果您的存储过程正在执行动态 SQL,则这不是真的。

If you're using the JDBC CallableStatement, then you're safe. CallableStatement is just a subtype of PreparedStatement, and SQL injection attacks should not be possible. The only way I can think of for this not to be true would be if your stored procedure was executing dynamic SQL.

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