- 締切済み
Pro*C 静的SQLでもSQLインジェクション対策は必要ですか？
- みんなの回答 （2）
- 専門家の回答
みんなの回答
- めとろいと（@naktak）
- ベストアンサー率36% (785/2139)
確証はありませんが、プリペアドクエリとして動作する為、 SQLインジェクション対策は必要ないように感じます。 動作して確認する環境が言えないので定かではありませんが・・・。 一度単純なファイルを作ってみて、どういう風に動くか 確認してみてはいかがでしょう？
- めとろいと（@naktak）
- ベストアンサー率36% (785/2139)
Oracle Pro*Cは利用した事がないので何とも分かりませんが、 静的、つまり生成するSQL文は全てリテラル文字列で、外部からの干渉を受ける立場にないのに、 どうやってSQL文に文字を注入するのでしょうか？
お礼
すみません、静的SQLという表現はよくなかったですね。 例えば以下のような埋め込みSQLで、ホスト変数(in_pass)に どのような値が設定されても、１つの値として扱われるという 確証を得たいのです。 EXEC SQL SELECT user, pass INTO :str_user, :str_pass FROM foo WHERE pass = :in_pass; in_pass ← "' OR 'A'='A" でも大丈夫？
関連するQ&A
- SQLインジェクション対策
Webアプリにて入力フォームからのSQLインジェクション対策を行いたいと思っているのですが その１つとしてpreparedstatement SQLを使用することを考えています。 これを使用すればシングルクォーテーションを使った 悪意のあるSQL文を挿入されることが防げると思うのですが他に何か考慮することって あるのでしょうか。
- ベストアンサー
- Java
- SQLインジェクションについて
SQLインジェクション対策についてご質問があります。 SQLを入力してそのまま実行するプログラムを作ろうとしています。 ユーザーが入力したSQLをプログラム側でSQLインジェクションを含むかどうかの判定が できるようにしたいのですが、可能なのでしょうか？ よろしくお願い致します。
- 締切済み
- その他（プログラミング・開発）
- SQLインジェクション対策
SQLインジェクション対策で $hoge = htmlspecialchars($hoge); $hoge = mysql_real_escape_string($hoge); を使おうと思っていますが、どちらを先に書けばよいでしょうか？
- 締切済み
- PHP
- prepareでSQLインジェクション対策？
PHPでMySQLを操作しています。 PDOのprepare()を使えば（プレースホルダを使えば？）、SQLインジェクションは必ず発生しないと言えますか？ もし、そうだとすれば、SQLインジェクション対策はかなり簡単ですよね？でも、セキュリティの話でよく取り上げられるということは、実際は他の問題が発生したりするんですかね？
- ベストアンサー
- PHP
- SQLインジェクション対策
SQLインジェクション対策を考えています。いろいろ検索しましたが漠然とした内容ばかりで参考になりません。具体例、攻撃方法を教えてください。現在は ' のみを排除しています。改行などは有効でしょうか？関数化するつもりですがどういう文字列を対象とすればいいか教えてください。
- 締切済み
- その他(データベース)
- SQLインジェクションの対策
SQLインジェクションの対策 いつもお世話になっております。 SQLインジェクションの対策についてお伺いいたします。 もともと↓のようなSQL文だったものを "select user_id from table where user_id='{$user_id}'" 以下のように変更しました。 "select user_id from table where user_id='" . mysql_real_escape_string($user_id) . "'" 以下のように実行されていたSQL文は select user_idfrom table where user_id='10001' and 'a'='a' ↓のようにエスケープ処理して実行されるようになりました。（入力値は「10001' and 'a'='a」） select user_id from table where user_id='10001\' and \'a\'=\'a' ですが、phpMyAdminで実行してみるとどちらのSQL文も同じ結果が取得できてしまいます。 これでは対策になっていないと思ったので、質問させていただきました。 （magic_quotes_gpcはoffに設定しています。） なにか他の方法がいいのでしょうか。 ご教示よろしくお願いいたします。 ＜環境＞ PHP 5.1.6 MySQL 5.0.45
- ベストアンサー
- PHP
- SQLインジェクションが発生する理由
初めての質問です。よろしくお願いします。 今現在、SQLインジェクションというものが問題になっていますよね いろいろなサイトを回って調べて見たのですが、具体的な対策として、「'（シングルクォーテーション）」などの特殊文字を確実にエスケープすること、くらいしか対策が書かれておりません。 特殊文字のエスケープさえしっかりしておけばSQLインジェクションは発生しない、という印象を受けたのですが、SQLインジェクションがおきてしまったサイトではエスケープ処理をしていなかったということなのでしょうか？ それとも、エスケープ処理をしていても何らかの方法で不正なSQLの命令を実行されてしまうのでしょうか？ どうにもわからなくて困っているので、どうかよろしくお願いいたします。
- ベストアンサー
- その他(データベース)
- PreparedStatementを利用するとSQLインジェクションの対策になるのか？
会社の同僚からＤＢの更新時は StatementではなくPreparedStatementを使えと言われました。 それがSQLインジェクション対策になるというのですが Javadocを見てもSQLインジェクションの話は書かれていませんし 同僚も明確な回答ができなかったので いまいち腑に落ちないでいます。 そこでお聞きしたいのですが、ＤＢの更新時に PreparedStatementを使用すると防ぐことができて Statementを使用すると防ぐことができない攻撃パターンとは 具体的にどのようなものが考えられるのでしょうか？
- 締切済み
- Java
- Pro*C/C++について
今回OracleのデーターベースにはC言語でアクセスするということで、 Pro*Cを使ってSQL文をCに埋め込むということなのですが今例文なんかを探しています。 なにかいいホームページがあれば教えていただけないでしょうか？ またいいPro*Cについての参考書もあればぜひ教えてください。 よろしくお願いします。
- ベストアンサー
- その他(データベース)
- SQLインジェクション対策
SQLインジェクション対策として、変数を直接SQLに埋め込むのではなく、PDOのprepareメソッドを利用して作成したステートメントに値をバインドする形式にする場合、ユーザー定義関数をどのように 修正すればいいですか？ function update_item_stock($db, $item_id, $stock){ $sql = " UPDATE items SET stock = {$stock} WHERE item_id = {$item_id} LIMIT 1"; return execute_query($db, $sql); } function execute_query($db, $sql, $params = array()){ try{ $stmt = $db->prepare($sql); return $stmt->execute($params); }catch(PDOException $e){ set_error('更新に失敗しました。'); } return false; } 上記のユーザー定義関数を下記のようにbindValueを用いて表す場合、$stmt->bindValueの部分を 上記のどこに追加すればいいですか？ try { $sql = 'UPDATE item_stock SET stock = ?, update_date = ? WHERE item_id = ?'; $stmt = $db->prepare($sql); $stmt->bindValue(1, $update_stock, PDO::PARAM_INT); $stmt->bindValue(2, $date, PDO::PARAM_STR); $stmt->bindValue(3, $item_id, PDO::PARAM_INT); $stmt->execute(); $complete_msg[] = '在庫変更に成功しました。'; } catch (PDOException $e) { $err_msg[] = '更新に失敗しました。理由：' . $e->getMessage(); }
- 締切済み
- PHP
お礼
はい、実際に試してみたところ、問題はなさそう (１つの値として扱われてそう)なのですが。 Pro*C(埋め込みSQL)に関する情報が少なく、 いまいちはっきりしないのです。