安全な開発ライフサイクルを使用する

学習の目的

この単元を完了すると、次のことができるようになります。

• 開発ライフサイクルのセキュリティを確保することの重要性を説明する。
  
• サニタイズと検証の欠如を悪用した有名な攻撃 (インジェクション、XSS) を挙げる。
  

ソフトウェア開発ライフサイクルを保護する

1. アプリケーションで対応する要件やユースケースを計画する。
   
2. アプリケーションを設計する。
   
3. コーディングでアプリケーションを実装する。
   
4. アプリケーションが正常に機能していることをテストする。
   
5. 顧客にアプリケーションをリリースする。
   
6. アプリケーションをメンテナンスする。
   

上記のリストは、典型的なソフトウェア開発ライフサイクル (SDLC) 内の 6 つのステップを示しています。以前アプリケーション開発チームで働いたことがある方は、このサイクルの各フェーズには馴染みがあると思います。とはいえ、アプリケーションセキュリティエンジニアの役割がどこに該当するのかはご存じないかもしれません。エンジニアは主に、顧客にリリースする前にアプリケーションのセキュリティをテストするのでしょうか? 重大な脆弱性にパッチを適用して、アプリケーションのセキュリティ確保に注力するのでしょうか? それとも、セキュリティ機能を設計に組み込むように提案するのでしょうか?

アプリケーションセキュリティエンジニアは SDLC の各ステップで重要な役割を担うというのが、その答えです。セキュリティの問題は、アプリケーションのライフサイクルのどのフェーズにおいても発生または検知される可能性があるため、アプリケーションセキュリティエンジニアは、アプリケーションのデータの機密性、整合性、可用性を保護するために一貫して役割を担います。多くの場合、セキュリティは最も脆弱な部分であると考えられています。頑丈な金属の鎖でも 1 つの環が損傷すると切れてしまうのと同じです。そのため、SDLC の各フェーズを保護して、アプリケーションの開発、リリース、メンテナンス全体でセキュリティを確保する必要があります。

たとえば、SDLC の実装フェーズで、開発者が入力のサニタイズと検証を行う確認を導入しなかった場合、コードが脆弱になる可能性があります。そうなると、攻撃者が別のユーザーのデータや管理機能への不正アクセスを可能にするアプリケーション入力をフィード送信できてしまいます。

また、開発チームはアプリケーションを開発する際にオープンソースコードを活用することが多々あります。オープンソースコードは、インターネット上で多くの人が関わって共同で開発されています。このようなコードは、多数の開発者が共同で開発して確認しているため安全性が高い一方で、脆弱性を含んでいる場合もあります。開発チームは、これを常に認識した上で、こういったコードライブラリを確認し、既知の脆弱性のあるコンポーネントを使用していないことを確認する必要があります。

アジャイル開発の世界では、アプリケーション開発チームはより厳しいスケジュールで新しいサービスや機能を提供し続けているため、適切なサイバーハイジーンや変更管理に対する注意が疎かになりがちです。

アプリケーションセキュリティエンジニアは、SDLC のすべてのフェーズで開発チームと連携して作業します。また、推進者、コンサルタント、専門分野のエキスパートとしての役割を担い、アプリケーションが安全に設計されていること、セキュリティ検証が実施された上でコードが実装されていること、開発から品質保証へ、さらに本番への移行全体を通して脆弱性が取り込まれていないことを確認します。

インジェクションとクロスサイトスクリプティング (XSS) から保護する

SDLC のセキュリティ確保は、2 つの有名かつ容易に悪用可能なアプリケーションセキュリティリスク、つまり、インジェクションとクロスサイトスクリプティング (XSS) から保護する際には特に重要になります。アプリケーションの機能について考えてみてください。ほとんどすべてのアプリケーションにとって最も重要な機能の 1 つは、データストア (データベースなど) にデータを格納し、データストアからデータを取得する機能です。開発者はコーディング言語を使用して、ユーザー入力に基づいてアプリケーションにデータベースの操作方法を指示します。たとえば、ユーザーはアプリケーションにログインするとき、ユーザー名とパスワードを入力します。Enter キーを押すと、データベースクエリがトリガーされ、クエリが成功すると、ユーザーはシステムにアクセスできます。

残念ながら、正当なユーザーがアプリケーションと行うすべてのやり取りは、攻撃者が悪意を持って悪用することも可能です。インジェクションの欠陥は、攻撃者が信頼できないデータをコマンドやクエリの一部として送信するときに発生します。開発者が適切に入力の検証やサニタイズを行っていない場合、攻撃者が意図しないコマンドを実行したり、適切な承認なしにデータにアクセスしたりするおそれがあります。その結果、データの損失、破損、漏洩を招くことになります。

かなり恐ろしいと思いませんか? アプリケーションセキュリティエンジニアは、このようなことが起こらないようにするための素晴らしい仕事をしています。また、さまざまなツールと手法を使用して、開発チームがアプリケーションと顧客のデータをこの種の攻撃から保護できるようにサポートします。

• ソースコードレビュー: アプリケーションセキュリティエンジニアがソースコードの一部を判読して、適切なデータの検証とサニタイズを確認する大半が手動のプロセスです。
  
• 静的テスト: プログラムのコードを調査しますが、その際にプログラムを実行する必要のないソフトウェアテスト手法です。たとえば、静的コード解析では、Web アプリケーションへの信頼できないユーザー入力のデータフローの確認と、データがコマンドとして実行されるかどうか (これは望ましくない結果である) の確認が行われることがあります。
  
• 動的テスト: プログラム実行中にプログラムのコードを調査するソフトウェアテスト手法です。
  
• 自動化テスト: テストスクリプトを使用して、コードの実際の結果と予想される結果を比較することにより、ソフトウェアを評価します。
  
• コマンドとクエリの分離: 常にデータをコマンドとクエリから分離します。どの手法もアクションを実行するコマンドか、コール元にデータを返すクエリのいずれかである必要があり、両方であってはならないという考え方に基づいています。クエリではアプリケーションやそのデータの状態が変更されることは決してありません。また、コマンドでは状態を変更できますが、決して値が返されることはありません。これにより、攻撃者が Web インターフェースを介してオペレーティングシステムのコマンドを指定し、そのコマンドを実行して悪意のあるプログラムをアップロードしたり、パスワードを取得したりすることを防ぐことができます。
  
• 許可リスト: 許可される文字やコマンドの許可リストを実装することで、ユーザー入力を検証し、許可されていない文字を使用するコマンドや許可されていないコマンドを URL やフォームデータで実行できないようにすることができます。たとえば、許可リストによって次の特殊文字がエスケープされたり、絞り込まれたりする場合があります。( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , `
  
• その他: MITRE の「Common Weakness Enumeration (CWE) (共通脆弱性タイプ一覧 (CWE))」では、コマンドインジェクションから保護する際に考慮すべきその他の事項に関する役立つリソースを参照できます。
  

インジェクションに加えて、データの検証とサニタイズやコードのテストとレビューを介した SDLC のセキュリティ確保が失敗する原因となるもう 1 つのリスクは、アプリケーションがクロスサイトスクリプティング (XSS) に対して脆弱になる可能性があることです。XSS は、適切な検証が行われることなく、アプリケーションで信頼できないデータが新しい Web ページに追加されるときに発生します。

次の画像は、XSS がどのように発生するのかを示すフローです。まず、攻撃者が信頼済み Web サイトに悪意のあるコードを挿入し、無防備なユーザーにそのコードを送信します。次に、Web ページで悪意のあるスクリプトがデータベースに保存されます。その後、被害者がその Web サイトにアクセスし、安全だと信じてサーバーからのデータを要求します。すると、悪意のあるスクリプトを含むデータが Web ページサーバーを経由してユーザーのコンピューターに渡されて、実行されます。最後に、攻撃者にコールバックされ、ユーザーの情報が侵害されます。その間もずっと、ユーザーは信頼済み Web サイトで安全なオンラインセッションに参加していると信じて疑いません。 

XSS を使用して被害者のブラウザーで悪意のあるスクリプトを実行することで、悪意のある攻撃者はユーザーのセッションを乗っ取ったり、Web サイトを改ざんしたりできます。また、ユーザーを悪意のあるサイトにリダイレクトして、そのサイトでマルウェアのダウンロードを促したり、攻撃者が盗むためにログイン情報を入力させたりすることもできます。その結果、被害者のコンピューターがマルウェアに感染して、機密情報が盗まれたり、攻撃者が分散型サービス拒否攻撃を実行するために使用できるボットネットの一部となって組織のネットワークをトラフィックで溢れさせてしまい、正当なユーザーのアクセスが制限されたりする可能性があります。

アプリケーションセキュリティエンジニアは XSS について考慮する必要があります。XSS は悪用しやすい攻撃ベクトルであり、ハッカーが入手可能な自動化ツールを自由に使用して狙うことができる広範なセキュリティ上の弱点でもあるためです。

ある試算によれば、すべてのアプリケーションの 3 分の 2 で XSS に対する脆弱性が見つかるとされています。そう聞くと不安になりますが、アプリケーションセキュリティエンジニアが SDLC のセキュリティを確保する上で、刺激的で重要な役割を担っていることも意味しています。そうすることで、エンジニアは、アプリケーションでユーザー入力が検証されるようにすることや、別のユーザーやシステム管理者が後で表示できるサニタイズされていない入力が保存されないようにすることができます。また、これを行うために、信頼できないデータを有効なブラウザーコンテンツから分離して、設計で自動的に XSS をエスケープするコーディングフレームワークを使用し、状況に応じたエンコードを適用します。

まとめ

SDLC 全体を通じてアプリケーションとそのデータを保護できるようにするための重要な考慮事項をいくつか説明しました。次は、アプリケーションセキュリティエンジニアにとってもう 1 つの重要な考慮事項である、アプリケーションコンポーネントの適切な設定について学習しましょう。 

リソース

• PDF: OWASP Proactive Controls for Developers (OWASP 開発者向けプロアクティブコントロール)
• 外部サイト: OWASP Testing for SQL Injection (OWASP SOQL インジェクションのテスティング)
• 外部サイト: OWASP Injection Prevention Cheat Sheet (OWASP インジェクション防止早見表)
• 外部サイト: OWASP Cross Site Scripting Prevention Cheat Sheet (OWASP クロスサイトスクリプティング防止早見表)