開発者が知っておくべきアプリ攻撃の 3 つの兆候
アプリは攻撃を受けています。 攻撃は驚くべき頻度で発生しており、メリーランド大学が実施した調査によると、攻撃は 39 秒ごとに発生しており、成功確率も驚くほど高い。
これらのアプリのセキュリティ確保の負担がますます重くなっている開発者は、この脅威を十分に認識しています。 NodeSource と Sqreen が 2017 年後半に Node.js 開発者を対象に実施した調査では、「回答者の 3 分の 1 以上 (34%) が、今後 6 か月以内に自社が大規模な攻撃の標的になる可能性が高いと考えている」ことが判明しました。 攻撃の 86% における最初の攻撃ベクトルはアプリケーション自体か ID のいずれかであるという当社の調査結果を考慮すると、その考えは十分に合理的です。
「回答者の 35% が、攻撃が発生したときにそれをどのように識別すればよいか分からなかった」という事実を知ると、不安になるかもしれません。 彼らはそれを予期していますが、それが起こったときにそれをどのように認識すればよいかわかりません。 進行中の攻撃を識別する方法がわからない場合、攻撃を阻止するのは非常に困難です。
そのため、攻撃に対するリアルタイム保護を一切使用していない Node.js 開発者が 23% (23 パーセント) いる状況はさらに深刻です。
良いニュースは、アプリケーション配信の現状に関する当社の独自の調査によると、ほとんどの組織は、攻撃に対して何らかのリアルタイム保護を使用しています。 5 社中 4 社が、 Web アプリケーション ファイアウォール(57%)、ランタイム アプリケーションの自己保護 (11%)、ユーザー行動分析 (26%) など、2 つ以上のテクノロジを使用しています。
これらすべてのテクノロジーに共通する特徴は、開発者に欠けていることが多い「可視性」です。 攻撃を検出し（できれば特定し）、異常な動作を認識できなければならないため、可視性は必要です。
アプリケーションとそのサービスには、かなり予測可能な使用パターンがあります。 たとえば、シングル サインオン (SSO) アプリケーションでは、月曜日の午前中は使用量が多く、金曜日の午後は使用量が少なくなる傾向があります。 金融アプリケーションは、給料日、納税期間の終了、会計年度の締め切りなどの金融イベントの直前に頻繁に使用される傾向があります。
消費者向けアプリケーションであっても、予測可能な使用パターンがあり、それを使用して異常な（潜在的に危険な）動作を検出することができます。 たとえば、2017 年 4 月にMalauzai Software は、435 以上の銀行と信用組合から収集した使用データ (73 万人のアクティブなインターネットおよびモバイル バンキング ユーザーによる 1,320 万件のログインをカバー) に基づく月次「リトル データ」レポートの 1 つを発表しました。 その中で、 「エンドユーザーの 100% が残高を確認し、最近の取引履歴を確認しています。」 これは、残高と最近の履歴がランディング ページに表示されるため、誰でも確認できるからです。 そして、これが彼らが来る理由です。 77% の確率です。 ユーザーが行うことの 77% は、残高と履歴の確認だけです。 デジタルバンキングにおける全体的なやり取りのうち、残高や履歴を超えて他のタスクを実行するのはわずか 23% です。」
したがって、他の種類の取引に対する突然の関心は、攻撃の兆候である可能性があると推測できます。
残念ながら、このような統計は、すべてのアプリケーションで常に利用できるとは限りません。 そのため、可視性（監視）が重要になり、異常が明らかになる基準を確立できるようになります。 もちろん、すべての異常が攻撃を示すわけではありません。 週の半ばに SSO サービスの使用量が急増するのは、企業のパスワードを変更する期限が迫っているためか、月曜日と火曜日が休日でオフィスに誰もいなかったためである可能性があります。 それでも、ベースラインがあれば、攻撃が進行中であることを示す動作を識別するのに有利になります。
これら 3 つの異常な使用パターンが実際に攻撃である可能性がある場合は、必ず確認してください。 なぜなら、かなり頻繁にそうなるからです。
1. 接続が劇的に増加しました。 もしかしたら、あなたの投稿がただ話題になっているだけかもしれませんが、他にも何か起こっている可能性もあります。 接続率が大幅に上昇した場合は、ネットワーク トラフィックがそれに応じて増加しているかどうかをすぐに確認することをお勧めします。 そうでない場合は、スパイダーマンの感覚が刺激され、攻撃される可能性があることがわかります。 GET フラッドは、アプリケーションに大量の HTTP GET を噴射するだけで、他に何も行わないため、HTTP ベースの DDoS 攻撃の中で最も簡単に実行できます。 目的は、できるだけ多くの接続を消費して過負荷状態に追い込むことだけなので、実際の URL にアクセスしようとさえしないこともよくあります。
ログインを提供する URL またはサービスが特に増加している場合は、アクセスを取得するためのブルート フォース攻撃の被害者になる可能性があります。
攻撃が継続している兆候として、サーバー エラー、パフォーマンスの低下、リソースの枯渇がないか確認してください。
2. 送信応答のサイズ。 突然、送信応答が大きくなった場合、攻撃者がアクセスすべきでないデータにアクセスした、窃盗攻撃が成功したことを示している可能性があります。 攻撃者はワイルドカードを使用してデータに不正にアクセスすることが多いため、これは SQLi 攻撃が成功したことを示す主な危険信号の 1 つです。 SQLi は十分に理解されている攻撃ベクトルなので、今ではこの問題はカバーされていると思われるかもしれません。 しかし、SQLi は、数多くの業界レポートにおいて、毎年一貫して最も成功する攻撃の上位にランクされています。
基本的に、この攻撃はデータアクセスの制限を回避するように設計されています。 そのため、攻撃では 1 つのレコード (または数個のレコード) を受信するのではなく、数千のレコードを受信する可能性があります。 攻撃が成功すると、返されるデータの量が通常よりも大幅に多くなるため、攻撃が成功したことが目立ちます。
応答サイズに大きな違いがある場合は、直ちに調査する必要があります。
3. クラッシュして失敗します。 これらは、欠陥や誤って「不正な」入力によって説明できる場合もありますが、新しい（または古い）脆弱性を悪用する目的で、サードパーティのライブラリや Web サーバー プラットフォーム（またはアプリケーション）のバッファーをオーバーランしようとする試みを示している可能性もあります。 今日ではシステムが自動的に「再起動」できるのは良いことですが、再起動が必要な理由を無視するのは良くありません。
時折発生するクラッシュを無視したくなるかもしれませんが、無視しないでください。
クラッシュや障害を無視せず、障害のあるシステムを検査できるまで隔離できるアーキテクチャを検討してください。
もちろん、これはすべてを網羅したリストではありませんが、アプリケーションが攻撃を受けている可能性がある場合を特定し、その攻撃を阻止できるようにするための良いスタートとなります。
安全にお過ごしください!