SQL学習5——SQL注入関連


記事の目次
  • ユニオン
  • について$
  • 違い
  • ドルで表名
  • に入ります。
  • SQL注入を防止する方法
  • PreparedSttement
  • PreparedSttementは何ですか?
  • PreparedSttementのメリット
  • PreparedSttementはSQL注入を防止する
  • 限界性
  • ここでいくつかのあいまいな概念を補足します。
    SQL注入部分はユニオンなどに関連していますが、簡単にまとめてみます。
    ユニオン
    簡単にユニオンというのは同じ仕組みの結果をまとめた感じです。
  • ユニオン操作子は、2つ以上のSELECT文の結果セットを統合するために使用されます。
  • ユニオン内部のSELECT文は同じ数の列を持つ必要があります。列も似たようなデータタイプを持つ必要があります。また、SELECT文ごとの列の順序は同じでなければなりません。
  • SELECT column_name(s) FROM table_name1
    UNION
    SELECT column_name(s) FROM table_name2
    
  • は、デフォルトでは、ユニオンオペレータが異なる値を選択します。重複可能な値はユニオンALLを使用してください。https://www.w3school.com.cn/sql/sql_ユニオン.asp
  • について
    https://www.cnblogs.com/luohanguo/p/9122398.html 結論:xi注入はSQL注入を大きく防ぐことができます。SQL注入を防ぐことができません。
    違います
  • 菘は、着信データを文字列として扱い、order by #user_id#などの着信データに自動的にダブルクォーテーションを付けます。着信値がidであれば、解析されたsqlはorder by "id"です。
  • ドルは、到来したデータを直接にsqlに表示する。order by $user_id$、着信値がidであれば、解決されたsqlはorder by idである。
  • ドルの方法は、一般的にデータベースオブジェクトに着信するために使用される。(ここではSQL注入問題に注意しなければならない)
  • ドルの方法は、一般的にデータベースオブジェクトに着信するために使用される。(ここではSQL注入問題に注意しなければならない)
  • $方式の着信表名
    $A方式は、一般的に、データベースオブジェクト、例えば、着信テーブル名を入力するために使用されます。(ここではSQL注入問題に注意しなければならない)
  • 例子:select * from ${table_Name} where name = #{name}
  • この例では、テーブル名がuser; delete user; --であれば、動的解析後sqlは以下の通りである。
  • select * from user; delete user; -- where name = ?;の後のステートメントは注釈されていますが、元々ユーザに問い合わせたステートメントはすべてのユーザ情報を検索することとユーザテーブルを削除するステートメントとなり、データベースに致命的な損傷を与えます。
  • ですが、テーブル名がパラメータで渡された場合は、$このような使い方ではsql注入に注意するように注意してください。
  • SQL注入防止方法
    SQL注入防止方法:
    まず、ユーザーの入力をいつまでも信じないでください。
  • はSQLを使用しないで、NoSQLを考慮します。
  • 正規表現、文字列フィルタリング。
  • パラメータは、PreparedSttementと結合されています。
  • は、入力されたパラメータを正規表現を用いてフィルタリングする。
  • JSPでは、この関数を呼び出して、パケットの不正文字またはJSPページ判定コードを確認する。JSP参照JSPフィルタを使用してSQL注入を防止する
  • PreparedSttement
    Preparedstatementの処理メカニズムを参照してください。
    プレハブとは何ですか?
    PreparedSttementは、java.sqlパッケージの下のインターフェースであり、SQL文クエリを実行するために使用され、connection.prepardStatiment(sql)メソッドを呼び出してPreparedStitmentオブジェクトを得ることができる。データベースシステムはsql文をプリコンパイルして処理します。(JDBCドライバがサポートすれば)プリプロセッサ文はあらかじめコンパイルされています。このプリコンパイルされたsqlクエリ文は将来のクエリーで再利用できます。そうすると、Sttementオブジェクトが生成したクエリ速度よりも速いです。
    PreparedSttementの強み
    動的パラメータ化クエリを書くことができます。--は、SELECT interest_rate FROM loan WHERE loan_type=?プレースホルダ動的割当値を利用してパラメータを照会します。
  • はStatementよりも速いです。
  • は、SQL注入を防止することができる

  • PreparedSttementはSQL注入を防止します。
    パラメータ化クエリを使用する場合、データベースシステム(eg:MySQL)は、パラメータの内容をSQLコマンドの一部として扱わず、データベースでSQLコマンドのコンパイルを完了した後、パラメータを使用して動作しますので、パラメータに破壊的なコマンドが含まれていても、データベースで実行されません。データベースは私のテンプレート化したSQL文だけを実行して、事前にデータベースでコンパイルします。パラメータの中で破壊的な命令を実行しません。
  • は、SQL文字列を組み合わせる際に、先に入ってきたパラメータを文字に置換する(シングル引用符文字を連続して2つの単引用符文字に置換する)。これは、SQLデータベースにおいて、2つの単引用符文字が文字のうちの1つの単引用符文字とみなされるため、
  • 例えば、
  • 着信文字列:strSQL = "SELECT * FROM users WHERE name = ' " + userName + " ';"
  • 文字の置き換えをしないと:userName = " 1' OR 1=1 "
  • に置き換えると、userNameを文字に置き換えると、strSQL = "SELECT * FROM users WHERE name ='1' OR 1=1'となり、最後に生成されたSQLクエリ文は、userName = " 1'' OR 1=1"
  • となる。
  • このようにデータベースは、SQL注入を回避するために、nameが「strSQL = "SELECT * FROM users WHERE name = '1'' OR 1=1'」であるレコードをシステムに検索することができる。
    限界性
    SQLの注入攻撃を防ぐために、PreparedStatimentは一つのプレースホルダ(?)に複数の値があることを許さず、INフレーズクエリが実行されるとこの問題は難しくなります。