SQLインジェクションについて詳しく話すいくつかの散在する知識のポイント

ゼロ、この記事は知識のポイントをカバーしています

sqlmapが馬に関する文章を書く具体的なプロセス

スタックインジェクション

ユニオンインジェクション

コモンインジェクションバイパスポーズ

sql injection precompilation and common bypass poses.

I. sqlmapの文章を馬に書き込む作業（-- os-shell）

1.1 プロセスの簡単な説明

まず、ファイルアップロードファイルを" tmpujhum.php "という名前で記述します。

そして、このファイルアップロードトロイを経由してシェル（tmpbcluy.php）をアップロードします。

コマンドを実行するトロイの木馬の名前は、" tmpbcluy.php " です。

正確なプロセスは、以下で確認できます。  https://xz.aliyun.com/t

1.2 小さな問題

コマンドで直接ファイルを書き込めるのなら、なぜトロイの木馬を書いて先にファイルをアップロードし、このトロイの木馬に文章を渡す必要があるのでしょうか？

答え：***

sqlmapは正式にコードを書き、どこでこのプロセスに従うか、冗談で〜〜〜。

主な理由は、ほとんどのwafはトロイの木馬をアップロードするよりも、直接ファイルを書き込むコマンドを厳しく監視しているからです。

つまり、この「もうひとつ」のアイデアを使うことで、アップロードが成功する確率を上げることができるのです。

2つ目は、スタックインジェクション。
/{br

2.1 スタッキング・インジェクションとは

SQLでは、セミコロン(;)はSQL文の終わりを示すのに使われます。

SQL文が;で終わった後、次の文を作り続けるとしたら、一緒に実行されますか？

この考え方は、スタックド・インジェクションも生み出すのですね。

2.2 スタッキング注入の有無を判断する方法とは？

~id=1 "通常

~try " id=1a ", エラーが報告されたと仮定すると、データが強く回転されていないことを示す

~エラーが報告されないと仮定すると、";" はクエリに代入されず、SQL 文の終端として使用されることを意味します。

~この時、この位置でスタッキングインジェクションが発生する可能性が高いです

2.3 制限事項

  スタックインジェクションの限界は、以下のようなあらゆる環境で実行できないことです。 

  は、サポートされていないAPIやデータベースエンジンによって制限されるかもしれない、その 

  もちろん、攻撃者がデータを変更できなかったり、一部のプログラムを呼び出すことができなかったりするのは、権限の不足が原因であることも考えられます。

III. ユニオンインジェクション

3.1 原理

SQLインジェクションの大半は、このポーズを利用しています。

詳細は省きますが、直接、前回の記事を参照してください。

3.2 スタックド・インジェクションとの相違点

違いは、unionやunion allは実行できる文の種類が制限されており、クエリ文の実行にしか使えないことである。

スタックインジェクションは、あらゆるステートメントを実行することができます。

**例えば、以下の例では、スタッキングは正常に実行でき、ユニオンインジェクションは実行できません**。

ユーザーの入力です。1; DELETE FROM products サーバーサイドで生成されたSQL文は以下の通り。

  Select * from products where productid=1;DELETE FROM products

クエリを実行すると、1つ目はクエリ情報を表示し、2つ目はテーブル全体を削除します。

IV. 一般的なSQLインジェクションのバイパスポーズ

4.1 Wafの特徴。

 wafsの大半は、通常のマッチングによるリクエストをフィルタリング/インターセプトしています。

 通常、wafは同時にN個のルールをオンラインにしており、これらのルールが同時に有効な場合、1個だけブロックされることになります。

4.2 wafsを回避する核となる考え方。

 注入されたsql文は、wafの正規のマッチングルールをバイパスしながら、普通に解析・実行することができます。

4.3 共通の考え方

のデータです。

  ケース ,, 非常に古いwafはバイパスすることができる

  暗号化、復号化、符号化

  等価関数 union select == union all select

  特殊記号

  デシリアライズ

  アノテーションの混同、mysqlの機能。   

                   database/**/() == database()  

                   インラインコメントは，/* sqlバージョン番号 sql実行内容 */ などで，詳細を展開しない。      

モダリティ

 コミット方法の変更、一部のwafはデフォルトでgetしか検出しない（しかし、バックエンドがpostを受け取らないと仮定するのは有用ではない）。

 ミューテーション

その他

  FUZZ        

    ファジーテスト、スクリプト/ツールを使用して多数のペイロードを生成し、どのステートメントがwafを超えることができるかを確認するために直接ブラストwaf。  

  データベース機能

    mysqlの機能です。

      union%23a%0Aselect 1,2,3#.

    == union#a (変更記号) select 1,2,3#  

    == union select 1,2,3#

        , mysqlの機能。

       /*!select * from users*/ は正常に実行されます。

  ゴミデータのオーバーフロー

  HTTPパラメータ汚染   

      複数のパラメータがある場合、通常、最後のパラメータがデフォルトで使用されます。  

                ,,?id=1/**&id=-1%20union%20select%201,2,3%23*/  

                   は、「1/**-1 union select 1,2,3#*/ 」です。

                の場合、" /* コンテンツは実行されません */ "ので、WAFは安全だと考えています。

    しかし、Apacheの性質上

                      は、結局次のような引数を受け取ることになります。" -1 union select 1,2,3#*/ "

  静的リソース        

      以下は、静的リソース、つまり本来はphp?id=1がphp/a.txt (b.js etc)?id=1 に変更されたものです。  

       結果は影響を受けませんが、いくつかの古いwafを渡すことができます。

パラメータ汚染を伴うコメントを使ってwafsを回避する成功率は高い     

sqlmapでの注意点

~UAは、変更が付属しており、パラメータを変更することができ、あなたはBaiduや他の検索エンジンのUAに変更することができます

~成功率を上げるためにwafをバイパスするスクリプトを設定することができ、そのスクリプトは非常に簡単に書くことができる

~自分でテストする場合は、パラメータを指定してsqlmapのトラフィックをburpにプロキシし、通常のブラウザのトラフィックと比較して違いを確認することが可能です。

~必要に迫られた瞬間、接続プロキシプールが直接ブルートフォースでドライの開始で

V. Sqlインジェクションのプリコンパイルと共通バイパスポーズ

5.1 概要

プリコンパイルは一般的にJavaフレームワークにおいて、多くのインジェクションを傍受しながらSQL文の効率を向上させるために使用されます。

が、まだバイパスすることができます。

5.2 具体的な方法

5.2.1 ASC

アプリケーションのシナリオ

ASC/DESCは、アプリケーションが複数のデータを表示するときに使用され、通常、順方向または逆方向のソートが可能です。

ASC/DESC は SQL 文のキーワードで、セマンティックに影響し、シングルクォートでは発生しないものです

ASC/DESCはフロントエンドで受信すること、すなわちインジェクションされる危険性があることが想定されます。

対処方法

より安全な方法はホワイトリストを使うことであり、ソートの方法は2つしかなく、簡単な条件判断文で可能である。

<?php
 if($_POST['order'] === 'DESC'){
        $order = 'DESC';
    }else{
        $order = 'ASC'
    }

5.2.2 テーブル名/フィールド名

アプリケーションのシナリオ

テーブル名とカラム名は、シンタックスツリーを生成するプリコンパイル処理中に

プリプロセッサは、解析された構文木をチェックする際に、データテーブルとデータカラムが存在するかどうかを判断します。

この2つは具体的な値でなければならず、プレースホルダの ? は置き換えられない。

テーブル/フィールド名がフロントエンドのパススルーとして受け取られる、つまりインジェクションのリスクがあると仮定した場合

対処方法

による注文の場合、以下を参考にしてください。

5.2.3 order by

order by は、ソートの基準となるフィールドを指定するために使用されますが、先に説明したように、フィールド名は

order by以降のフィールドがフロントエンドのパススルーとして受け取られる、つまり注入されるリスクがあると仮定すると

具体的な迂回方法は、"case when " で検索するといくつか出てきます。

対処方法

SQL文の直接スプライシングを避けるために、カラム名を定数として定義することができます。

を作成し、スプライスをホワイトリストに登録することで、効果的にSQLインジェクションを防止することができます。

もちろん、受信文を正規のマッチングだけでフィルタリングすることも可能ですが、この方法ほど簡潔で効果的ではありません。

フロントエンドのフォーム

  <form action="" method="post">
      <select name="order">
          <option value="0">id</option>
          <option value="1">name</option>
          <option value="2">age</option>
      </select>
      <input type="submit" name="submit">
  </form>

ホワイトリスト機能。

  <?php
      $i = $_POST['order'];
   switch($i){
          case 0:
              $order = "id";
              break;
          case 1:
              $order = "name";
              break;
          default:
              $order = "age";
              break;
      }

5.2.4 まとめ

ASC/DESCが受信したフロントエンドの着信、すなわちインジェクションされる危険性があることを想定しています。

テーブル名/フィールド名が受信フロントエンドパススルーであると仮定した場合、すなわちインジェクションされるリスクがある場合

order byの後のフィールドが受信したフロントエンドパススルーであると仮定すると、すなわちインジェクションのリスクがある。

まとめ

sqlインジェクションの記事は以上です。sqlインジェクションの詳細については、過去の記事を検索するか、以下の記事を引き続き閲覧してください。