Webアプリケーションセキュリティ：ケーススタディ

Webアプリケーションのセキュリティは、10年以上にわたって情報セキュリティに対するトップ10の傾向と脅威になっています。 実際、現代のビジネスプロセスと日常生活は、複雑なインフラストラクチャシステムからIoTデバイスに至るまで、さまざまな面でWebアプリケーションの使用にますます依存しています。 それでも、Webアプリケーションを保護するための特別なツールはほとんどありません。ほとんどの場合、開発者に割り当てられます（または解決されることを願っています）。 これは、さまざまなフレームワーク、衛生、データクリーニング、正規化などの使用です。 それにもかかわらず、これらのツールを使用しても、「クラシックWeb」のすべての脆弱性においてWebはより安全になりませんでした。 この記事では、この脆弱性を防ぐ方法については説明しませんが、Webアプリケーションファイアウォールを使用してWebアプリケーションを操作から保護する方法については説明しません。

Webアプリケーションの保護は以前何でしたか？ Webサーバーの適切な構成から、サイトの不要なファイルとコードのセクションを削除し、最小限の制御を行います。 実際、チャネルは弱く、DDoSは広がらず、脆弱性はほとんどなく、アプリケーションは単純であり、ユーザーアクションはいくつかのシナリオで予測可能でした。

時間が経つにつれて、Webアプリケーション、サーバーインフラストラクチャ、および相互作用がより複雑になり、コードがより膨大で扱いにくくなりました。これにより、いわゆる 「表面攻撃」。 ウェブは非常に人気があり、経済成長の可能性が現れました。これは当然、この分野で他人の労働を違法に使用したい人を引き付けました。

Webアプリケーションに対する攻撃の数と種類は指数関数的に増加し始め、条件付きで2つのカテゴリに分類できます（情報セキュリティの概念に基づく）。

• 情報の機密性を侵害することを目的とした脅威;
• 情報の可用性を侵害することを目的とした脅威。

これは主に、脆弱性の悪用、および2番目にサービス拒否攻撃に関するものです。 また、計画およびアプリケーション開発段階で（テストツール、デバッグ、コード分析などを使用して）いくつかの攻撃を回避しようとすると、インターネットにWebアプリケーションを配置すると、インターネットサイト（特に人気のある活動または会社）が攻撃され始めますほとんどすべての方向に：

• 自動脆弱性利用システム。
• プロのサイバー犯罪者;
• 初心者、恋人。

それらにはさまざまな方法、方法、ツールがあります。それらは、Webアプリケーションをハッキングまたは無効にするという1つの目標によってのみ結合されています。

練習と統計

十分な理論、練習に移りましょう。 開発者の多くの反対者は、すぐに（または既に）脆弱性がないこと、ファッショナブルで安全なフレームワークがあること、何千人もの人々がソースコードをチェックしていること、ハッカーがすぐに死ぬことを訴えます。 しかし、実際にはどうですか？

「情報セキュリティ」ブログを見て、最近「ホットな」ものを見てみましょう。

ケース：4月3日：位置情報用の銀行ソフトウェアの0day（トピック削除）

脆弱性の種類：SQLインジェクション、RCE、認証バイパス。

説明：銀行のジオロケーションサービスへの参加のフォームでのブラインドインジェクション。 このサービスは重要であり、インターネットで利用できます。

リスク：ビジネスプロセス、セキュリティ、盗難、評判。

保護：SQLインジェクションの悪用のパターンを特定し、ブロックします。引用符の使用、特別な構成-この例では、スリープ機能。



ケース：3月24日：ピザ配達サイトのハッキング、mobidel.ruのハッキング

脆弱性タイプ：安全でない直接オブジェクト参照、XSS保存、セッションキャプチャ

説明：チェックなし、従来のクライアント側攻撃。

リスク：ビジネスプロセス、セキュリティ、盗難、評判。

保護：XSSベクトルの悪用パターンを特定してブロック-htmlコードインジェクション関数、異なるIDの複数の承認リクエストを使用します。



ケース：3月22日：実際のGitリポジトリのプライバシーについて少し

脆弱性タイプ：安全でない直接オブジェクト参照、情報漏えい

説明：重要なオブジェクトへの直接アクセス。

リスク：攻撃を開発するためのアプリケーションに関する情報を取得します。

保護：リポジトリサービスファイルへの複数の呼び出しを検出してブロックします。



ケース：3月12日：ある晩のWebサービスの信頼できる承認

脆弱性タイプ：SQLインジェクション

説明：典型的な開発者、fig-figおよび本番環境。

リスク：あいまいさによるセキュリティ。

保護：SQLインジェクション（ユニオン、セレクトなど）の悪用のパターンを特定してブロックします-それがどこにあるか（ソースコードがある場合）を知っていても、攻撃者はそれを悪用できません。



ケース：3月6日：通信プロバイダーがハックする方法：実際の攻撃の分析

脆弱性タイプ：SQLインジェクション

説明：Webを介した境界のハッキング、ネットワークへの侵入。

リスク：ビジネスプロセス、セキュリティ、盗難、評判。

保護：脆弱性検索の自動手段（ヘッダー、呼び出しの頻度（解析）による）の使用パターンを識別してブロックします。

これが彼らの言うことすべてです。 Webアプリケーションは壊れており、引き続き壊れます。 安全なコード、推奨事項、ベストプラクティスなどを開発するための指示はありません。 動作しません。 Webアプリケーションのハッキングを防止するには、追加の保護対策、または安全対策さえ必要です。 これは、現代のWAFが万能薬であることを意味するものではありません。 これは、Webアプリケーションの破損を防ぐための安全対策の1つです。

パターン検出

上記のケースの主なパターンを見てみましょう。

注射剤

SQLインジェクションの活用。 まず、攻撃者（または自動ツール）は、あるパラメーターまたは別のパラメーターに引用符を代入するときのアプリケーションの動作を調べます。

site?id=1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インジェクションがあり、サイトにエラー（クラシック）が表示されると仮定します。SQL構文にエラーがあります。 単純な引用符をブロックできますか？ アイデアはイエスですが、オコナー、サービス、または管理パネルなど、引用符の使用が非常に適切な姓をどうすればよいでしょうか？ （同じマークダウンマークアップにより、多くの誤検出が発生します）。

 site?search=O'Connor
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなリクエストは、エクスプロイトと直接関係するものではなく、サウンディングプローブリクエストと呼ばれる場合があります。 つまり そのようなリクエストはブロックする必要がありますが、他のルールが定義されていないエリアでは。 また、リクエストの発信元のIPアドレスを確認する必要があります。このアドレスからの攻撃が以前にあった場合、ブラックリストに登録されます。 -評価ポリシーに基づいてブロックできます。

攻撃者はこの脆弱性を発見しました。今、それを悪用しようとします（最初に、フィールドの数を選択します）：

 site?id=1+union+select+null,null/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、最初の例のように：

 demo'+sleep(10)+'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの要求は、操作の試みに明示的に関連しており（通常は多数あります）、保護機器によってブロックする必要があります。 しかし、スコープを考慮する価値があります-リクエストの本文にある場合、Webアプリケーションを使用して危険な構造を変換（またはクリーンアップ）する必要があります。 たとえば、私の記事では、Habrは要求の壊れた構文を誓わず、通常どおり（実行せずに）引用符と攻撃パターンを公開できます。

攻撃 攻撃者はWebアプリケーションの配置方法を知っています（上記の例のようにコードがあります）。たとえば、drop / infile / outfile / dumpfile / load_fileのような特別なリクエストを使用して、攻撃の構造を事前に準備できます。

 site?id=1+union+select+null,LOAD_FILE('/etc/passwd'),null/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは明らかな攻撃であり、ブロックする必要があります（再びルールの適用ゾーンで）。 ポイントシステムを基礎とする場合、このデザインは多くのペナルティポイントを取得する必要があります。ユニオン選択パターン（およびバリエーション）、 LOAD_FILE関数、特殊文字の存在およびそれらの潜在的に危険な組み合わせ（ '/ 、 / etc / passwdサービスファイル、およびシンボルへのアクセス終了/コメント/ *。

Xss

それでは、XSSに進みましょう。 ペイロードには非常に多くのバリエーションがあり、それらはより多様で複雑です。 この場合、Webアプリケーションを保護し、ユーザーがデータをブロックせずに入力フォームに入力できるようにする必要があります。 これは、アプリケーションレベルとセキュリティ機能の両方で実行する必要があります。

たとえば、電話を入力する最も単純な形式（入力された値とタイプを検証せずにオプションを使用します）は、ユーザーのスキルと想像力により入力できます。

標準的に：

 +7 999 999 99 99
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

壊れたスペース：

 +79999999999
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

習慣的に：

 +7 (999) 999-99-99
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヨーロッパの方法で：

 +7.999.999.99.99
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり ユーザーは、このような単純なフォームであっても、シンボルの使用とその組み合わせのいくつかのバリエーションを使用できます。多くのフィールドを含む大きなWebフォームはどうでしょうか。 そして、彼らがテキストを飾る/強調することを提案したら？ あなたの会社：

 ++" ""++
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、そのようなリクエストはブロックされません;ここには危険な組み合わせはありません。 「通常の」xssプローブも非常に簡単に検出されます。

 alert( prompt( onload= onerror= onmouseover= location.href= document.cookie(
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、脆弱性を悪用しようとする試みが明らかになる可能性があるため、そのようなリクエストはブロックされます。

XSS検出に対するより深刻な要求があります-たとえば、古典的なジャンル（実際には老化しない） -raz0rからのユニバーサルXSSベクトル：

 javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40&#47;&#42;'/-/*&#39;,/**/eval(name)//&#41;;width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリクエストには、XSSで「撮影」するほぼすべてのものが含まれています。 このような要求は明確な攻撃であり、すぐにブロックする必要があります。

脆弱性スキャナー

通常、攻撃の前兆は、1つまたは別のユーティリティを使用してWebアプリケーションをスキャンしています。 明確な兆候：1つのIPから異なるページへの頻繁なアクセス、404以上のエラー。 これは検索ボットになる可能性があります（禁止することは決してありませんが、これがボットであることを確認する必要があります-ユーザーエージェントフィールドをチェックしてもこのような保証はありません）。 クローラーでもパーサーでもかまいません-申し訳ありませんが-解析させてください。サーバーが弱い場合は、1分あたりのリクエスト数で「食欲」に制限することができます。 スキャナーは別の問題です：まず第一に、ユーザーエージェント/サービスヘッダーによってすぐに識別できます（そして、それらを使用するほとんどの人はそれを決して変更せず、おそらくそれについて推測さえしません）：例えば、 ：acunetix、w3af、netsparker、niktoなど そのような呼び出しは、攻撃者の作業を促進しないように（およびログを詰まらせないように）直ちにブロックする必要があります。 ヘッダーがまだマスクされている場合、多数の404エラー、認証試行、サービスファイルへのアクセスによってスキャナーを識別できます。

保護

上記の例で見たように、さまざまな技術、プラットフォームが使用されています。したがって、最新の保護装置はこれを考慮する必要があります。 すべての場合において、WAFを使用することにより、脆弱性の悪用、および悪用の試みを報告する通知システムを防ぐことができます。

特定の脆弱性の悪用を避けるために、最新のWAFは次のことを行う必要があります。

• トラフィックを即座に処理する
• 不正なリクエストをブロックします。
• ボットのアクティビティを検出します。
• 任意のhttp / httpsプロトコルを使用できること。
• Webアプリケーションプラットフォームに依存しない。
• ブルートフォース攻撃、クロールなどを検出できる
• Webソケットなどで作業できること。
• 誤検出を最小限に抑える。
• ブロックDoS（L7）;
• 以下を含む新しい攻撃を特定してブロックする 機械学習を使用します。
• 攻撃シグネチャの最新の更新されたデータベースが含まれています。
• 最新かつ更新されたIP評価データベースが含まれています。
• 仮想パッチを適用します。