Webアプリケーションの脆弱性入門

Share
人がアプリケーションを持っているイラスト

Webアプリケーションは私たちの日常生活に欠かせない存在となっています。しかし、それらのWebアプリケーションが攻撃者からの脅威にさらされていることをご存知でしょうか?Webアプリケーションに脆弱性が存在すると、悪意のある第三者によって個人情報や企業の機密情報が漏洩するリスクが生じます。この記事では、Webアプリケーションの脆弱性の種類について解説します。

脆弱性とは

脆弱性とは(ポイントマークとその周りに人がいる)イメージ

脆弱性とは、プログラムの不具合や設計上のミス等によるバグが原因となって発生したセキュリティ上の欠陥や弱点のことを指します。Webアプリケーションに脆弱性が存在する場合、攻撃者がシステムに侵入し、機密情報を盗み出したり、サービスを乗っ取ったりするリスクが生じます。企業はWebアプリケーションの脆弱性を理解し、それに対処するための適切な対策を講じる必要があります。

脆弱性の種類

脆弱性にはさまざまな種類があります。以下に代表的な例を挙げます。

1. SQLインジェクション

データベースを使って情報を処理するWebアプリケーションは、その多くがユーザからの入力値をもとにデータベースへの命令文を構成しています。SQLインジェクションは、攻撃者がWebフォームなどの入力欄に特定のコードを入れることで不正な命令文を構成し、データベースを不正利用できてしまう脆弱性です。これを悪用することで、例えば、データベースの情報を盗んだり、改ざんしたり、消去したりできる可能性があります。

2. クロスサイトスクリプティング(XSS)

クロスサイトスクリプティング(XSS)は、ネットバンキングや掲示板のように、ユーザから入力された値を処理して出力するWebページに攻撃者が悪意のあるスクリプトを埋め込むことで、Webページを閲覧したユーザのWebブラウザ上でスクリプトを実行させることができる脆弱性です。これを悪用されると、ユーザが意図しない情報の送信や表示ページの改ざんなどのリスクが発生します。

3. クロスサイトリクエストフォージェリ(CSRF)

クロスサイトリクエストフォージェリ(CSRF)は、攻撃者が罠として用意した偽サイトを用いてリンクや画像をクリックさせることで、ユーザが意図していないリクエストを強制的に行わせることができる脆弱性です。例えば、SNSで「いいね!」をする、銀行の振込操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。

4. セッション管理の不備

Webアプリケーションの中には、セッションID(ユーザを識別するための情報)を発行し、セッション管理を行うものがあります。このセッション管理に不備があることで、セッションIDを固定化できたり、有効なセッションIDが推測可能だったりすると、セッションハイジャックと呼ばれる攻撃が成立する危険性があります。これにより、攻撃者が本来のユーザになりすまして権利を行使することで、プライベートな情報の閲覧や、設定の変更などが行われる可能性があります。

5. アクセス制御の不備

Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。例えば、一般ユーザとしてログインした際に管理者としての権利を行使できてしまう権限昇格、パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスすることが可能となるパストラバーサルなどです。不正アクセスや意図しない情報の公開をはじめとした、様々なリスクが生じます。

脆弱性を悪用した攻撃による影響

脆弱性が悪用されると、企業に深刻な影響が及ぶ恐れがあります。脆弱性が引き起こす可能性のある影響の例を、以下に示します。

機密情報の漏洩

攻撃者は、脆弱性を利用して機密情報を盗み出すことができます。クレジットカード情報や個人情報など、大切な情報が漏洩することで、企業の信頼性に係る問題や法的な問題が発生する可能性があります。

データの改ざん

脆弱なWebアプリケーションは、攻撃者によってデータの改ざんが行われる可能性があります。データの改ざんによって、Webアプリケーションの正確性が損なわれたり、信頼性が低下したりする可能性があります。

サービスの停止または遅延

脆弱性を悪用されると、サービスの停止、遅延、またはデータベースの消去といった、システム全体に影響が及ぶ被害を受ける恐れがあり、企業のビジネス活動に重大な影響が生じる可能性があります。

金銭的な損失

脆弱性のあるWebアプリケーションは、企業にとって金銭的な損失をもたらす可能性があります。攻撃者による不正アクセスでデータが盗難された結果、企業に損害賠償責任が生じる場合があります。

企業の信頼喪失

セキュリティに関する問題が公になると、企業の評判に悪影響を与える可能性があります。顧客やパートナーからの信頼を失うことは、企業にとって非常に重大な損失です。

脆弱性対策の方法

脆弱性の悪用を防ぐためには、以下のような対策が考えられます。

正しい権限管理の実施

ユーザには場面に応じた必要最小限の権限のみ付与することが推奨されます。また、不要な機能やリソースへのアクセスを制限することも脆弱性を軽減させるポイントとなります。

定期的なセキュリティチェックの実施

定期的なセキュリティチェックの実施(セキュリティとパソコンの周りに人)イメージ

Webアプリケーションに対しては、機能追加などのシステム改修時はもちろんのこと、定期的なセキュリティチェックを行うことが重要です。脆弱性スキャンやペネトレーションテストなどの手法を活用し、問題を早期に発見して修正することが大切です。

最新のセキュリティパッチの適用

Webアプリケーションを開発・運用する際には、使用しているフレームワークやライブラリの最新のセキュリティパッチを適用することが必要です。これにより、既知の脆弱性やセキュリティ上の問題を解消することができます。

まとめ

脆弱性のあるWebアプリケーションは、攻撃の潜在的なターゲットになります。セキュリティ対策を徹底し、脆弱性の早期発見と修正を行うことが重要です。また、さまざまな対策手法やセキュリティツールを活用し、脆弱性を作り込まないセキュアな開発環境作りに取り組んでください。企業のデータや顧客の個人情報を守るためにも、脆弱性対策は欠かせません。今回の記事がお役に立てれば幸いです。

セキュリティ診断サービスのサムネ

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

プログラミング言語の脆弱性対策を考える

Share

プログラミング言語のセキュリティは、組織のシステム全体のセキュリティに大きな影響を与えます。「アプリケーションの脆弱性の半数はC/C++に起因する」という報告もあり、プログラミング言語における脆弱性の特徴を理解し、適切な対策を講じることは、いまや組織のセキュリティに不可欠な取り組みといえます。本記事では、プログラミング言語の最新動向、脆弱性が生まれる背景を解説します。

プログラミング言語のトレンド

言語 使用している
開発者の比率
JavaScript69.7%
HTML/CSS 62.4%
SQL 56.9%
Python 41.6%
Java 38.4%
Bash/Shell/PowerShell 34.8%
C# 32.3%
TypeScript 28.3%
PHP 25.8%
C++20.5%
C 18.2%
Go 9.4%
Kotlin8.0%
言語 使用している
開発者の比率
Ruby7.5%
VBA6.2%
Swift6.1%
R5.5%
Assembly4.9%
Rust4.8%
Objective-C4.4%
Scala3.9%
Dart3.7%
Perl3.3%
Haskell1.8%
Julia0.9%

Stack Overflow Developer Survey 2020 より弊社作成
https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

JavaScript、HTML/CSS、SQLなどが上位に並んでいますが、皆さんの予想どおりでしょうか?ちなみに冒頭で述べた、「脆弱性の半数」を生み出すとされるC/C++に関しては、昨今IoTデバイスなどの組込機器やデスクトップアプリケーション等に利用目的が収れんしてきているといわれ、その使用率は減少傾向にあります。また、リストには記載がありませんが、日本に限ってみると、COBOLなどのレガシーシステム向けの言語がいまだ根強いシェアを保っているのはご存じの方も多いことでしょう。

なお、弊社での診断傾向としては、JavaScriptのほか、Pythonが目立っています。今後については、「オーバーヘッドが少なく、静的型付け言語である」という特徴をもつTypeScriptなどが、軽量さの望まれるサーバレス環境での需要につながるものとみられます。また、Android端末向けにKotlinの需要も高まると予測しています。以下、ご参考に、プログラミング言語と主な利用分野のマッピングを示します。

図:主要プログラミング言語と現在利用されている代表的分野

プログラミング言語の脆弱性 ― 言語ごとに異なる特徴を知る

プログラミング言語の脆弱性を考える場合、特定の言語に固有のものと、言語間で共通のものを押さえておく必要があります。

例えば、C/C++では、その脆弱性の7割がメモリハンドリングのミスに起因するといわれており、メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにすることが、重要なセキュリティ対策となります。そのほか、言語固有の脆弱性として代表的なものは、Javaでの「安全でない入力に対するデシリアライゼーション」の問題、JavaScriptでの「パストラバーサル」や「暗号」の問題、PHPでの「クロスサイトスクリプティング(XSS)」や「SQLインジェクション」などになります。

なお、2000年代後半以降にリリース開始された比較的新しいプログラミング言語(Kotlin、Golang、Rustなど)については、上記とは若干が異なる観点からの注意が必要です。まず、こうした言語では、セキュアコーディングのための様々な関数やライブラリなどが用意され、セキュリティに関する手厚い対策が組み込まれているのですが、その一方で、セキュリティの機能が増えれば増えるほど関連ドキュメントが膨大になり、把握が追いつかないという課題が生じています。例えば、Kotlinの場合、Kotlin自体のドキュメンテーションではセキュリティ関連の記述はNULLの安全性に触れる程度なのですが、セキュアコーディングに取り組もうとすると、膨大なAndroid Developer Guideを参照する必要があります。また、相互運用性への配慮も必要です。例えばKotlinやGolangはJavaと一緒に利用するケースが多いため、こうした言語で開発を行う場合には、Java側の環境を考慮したうえでのセキュアコーディングが不可欠になり、それが開発の難易度を押し上げているという状況があります。

プログラミング言語の脆弱性 ― 全言語に共通の特徴を知る

続いては、すべての言語に共通する脆弱性です。これは大きく以下の3つに分類できます。

情報漏洩
・表示する必要のない機微な情報(ユーザ名やIDなど)の露呈
・不要なシステム情報の公開
入力検証の不備
・不正なパラメータの許容、XSS、SQLインジェクション
・HTTPヘッダ分割
認可・認証関連の脆弱性
・オブジェクトやファイルなどへのアクセス認可の不備
・認証情報の保護機構や暗号化の不備

脆弱性が発生する背景

以上述べてきたような脆弱性は、なぜ発生するのでしょう。その背景には、開発現場における以下のような課題があると考えられます。

・プロジェクトベースで人員が変わることが多く、知識や経験の共有が行われることがまれ
・脆弱性やセキュアコーディングに対する意識、知識レベルがプログラマによって異なる
・ギリギリのスケジュールでプロジェクトが進むことが多く、知識や経験の共有まで手が回らない
・セキュリティへの対応が明示的な業務として遂行されるのではなく、プログラマやプロジェクトメンバー1人1人の善意に依存する面が強い

具体例で説明しましょう。先ほど、PHPではXSSやSQLインジェクション等の脆弱性がよく見られると述べました。しかし、PHPでも、バージョン4以降であれば「htmlspecialcharacters」という関数を利用することでXSSの回避に必要な特殊文字のエスケープ処理ができます。SQLインジェクションについても、プレースホルダの利用による回避が可能です。このように、すでに対策が存在する場合であっても、プログラマ間で知識や経験の共有が行われていない場合、ソースコード診断やステージング環境でのWebアプリケーション脆弱性診断が実施されない限り、脆弱性は放置されることになります。また、「機微な情報の露呈」という問題については、個人情報保護などの法制度に対する知識が共有されておらず、そもそも課題として認識されていないという可能性があります。なお、知識共有のハードルは、セキュリティ機能が充実しているゆえに把握すべき情報量が膨大で、他の言語との互換性等まで含めた配慮が求められる最近のプログラミング言語では、さらに高いといえるでしょう。

こうした課題を解決するには、プログラマ個人の知識・技術レベルを高めることはもちろんですが、それ以上に重要なのは、組織を挙げての体系的な取り組みであるといえます。

先手を打った対処がカギ

そこでぜひ取り入れたいのが、プログラミング言語に関わる脆弱性が生じていないかを、開発の初期段階から継続的に点検する取り組みです。これは「DevSecOps」とも呼ばれる考え方で、「開発(Dev)」・「運用(Ops)」に「セキュリティ(Sec)」の観点を組み込むことで、システムのセキュリティ強化を図るものです。開発プロジェクトは常に時間との闘いですが、だからといって脆弱性への対応を先送りしてはなりません。対処が事後になればなるほど、影響範囲が広がり、コストも肥大する恐れがあります。

以前の記事でも解説しましたが、何よりも、初期段階からの取り組みが重要です。例えば、人員の流動が激しいプロジェクトベースの現場では、開発の早期からソースコード診断を含むテスト活動を実施し、脆弱性をコード単位で効率的に解消していくことによって、各段階で積み上げられた知識や経験を、後続の工程で活用することが可能になります。また、近年主流になっているアジャイル型の開発手法でもこれは有効で、短い開発サイクルが繰り返される中で早期に・こまめにテストや修正を行うようにすることで、セキュリティを強化できるのみならず、プロジェクト全体の工数も抑制できます。なお、短いサイクルでテストを回すには、SaaSタイプのソースコード診断サービスの利用を検討してもよいでしょう。

先手を打って脆弱性に対処できれば、脆弱性の要因となっていた様々な課題に取り組む余裕も生まれます。結果として、セキュリティと開発効率をともに高められる好循環を実現できるのではないでしょうか。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

Webアプリ脆弱性の代表格「クロスサイトスクリプティング」の攻撃事例と対策

Share

クロスサイトスクリプティング(XSS:Cross Site Scripting)とは、サイバー攻撃に悪用される脆弱性のひとつです。

この脆弱性を悪用した攻撃の多くが、Webサイトを横断(Cross Site)して行われたためこの名称がつけられました。現在では攻撃類型が増えたことから、必ずしもサイト横断的な攻撃でなくても、クロスサイトスクリプティングと呼ばれることがあります。

今回は、クロスサイトスクリプティングを悪用したサイバー攻撃の事例やその対策について説明します。

クロスサイトスクリプティングの種類

クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる(できる)事象を指します。

クロスサイトスクリプティングの脆弱性には、大きく分けて下記の3種類があります。

1.反射型
攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの

2.蓄積型
攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの

3.DOMベース
Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

クロスサイトスクリプティング脆弱性が悪用された事件による騒動

クロスサイトスクリプティングの脆弱性が悪用された被害が多数報告されています。なかでも有名なのは、過去に二つの大手ITサービスで発生した事件です。

2010年、YouTubeとTwitterで、クロスサイトスクリプティングの脆弱性を悪用した攻撃が相次いで発生、虚偽情報を知らせるポップアップが表示されたり、ユーザが意図しない投稿が繰り返されたりするなど、世界中で騒動となりました。

Twitterへの攻撃は、ユーザが意図しない投稿を行うもので、見つけた脆弱性がどう動くのか実験したいというちょっとした出来心が攻撃意図に含まれていたと言われています。YouTubeについてはフェイクニュースをポップアップで表示するなどのいたずらに近い内容でした。いずれも被害は軽微で、すぐに気づくことができた点は幸運だったといえるでしょう。

クロスサイトスクリプティングを悪用した攻撃の本当の危険性と恐ろしさ

クロスサイトスクリプティング攻撃の危険性

一方、上記のようないたずら目的ではない攻撃では、正規サイトと全く見分けがつかないフィッシングサイト等へ誘導されたり、ログイン状態の維持のために利用しているCookieなどのセッション情報を盗まれたり、入力した情報(例えばパスワードやクレジットカードの番号やセキュリティコード)が盗まれるといったことが行われます。この結果、アカウントへの不正アクセス、クレジットカード情報・個人情報の漏えい、あるいはクレジットカードの不正利用などが行われることがあります。またスクリプトの実行による任意コードの実行やマルウェア感染といった問題も存在します。このようにクロスサイトスクリプティング脆弱性は悪用された場合に甚大な被害が発生する可能性が高いという点に危険性があるといえます。

ユーザに被害が出てから発覚することのリスク

Webアプリケーションを利用するユーザの側では、身に覚えのないクレジットカードへの課金など、具体的な被害が発生するまで攻撃を受けたことにすら気づかないこともあるでしょう。一方のWebアプリケーション開発側・運用側でも、実際にユーザやクレジットカード会社から被害発生を知らされるまで気づかないというケースもあります。

ユーザ側の視点でみると、「自分が被害に遭ったのに、サイトの運営者が気付いていないなんて」と憤る可能性もありますし、「こんな不完全なサイトを運営するなんて」と不信感を抱く可能性もあるでしょう。クロスサイトスクリプティング脆弱性のあるサイトを運用することはともすればユーザの信頼を損なう結果に結びつく可能性があるのです。

クロスサイトスクリプティングの発見報告状況

SQAT.jp を運営する株式会社ブロードバンドセキュリティが行ったWebアプリケーション脆弱性診断の2020年上半期の統計によれば、クロスサイトスクリプティングは、検出される全脆弱性の約5%を占めています。

冒頭で「Webアプリ脆弱性の代表格」と述べている割にあまり比率が多くない、と感じるかもしれませんが、むしろ古くから警鐘が鳴らされ、対策も公表されているにもかかわらず、新たに作られたWebサービスにも(ステージング環境の診断を含むとはいえ)一定割合存在する点に注目すべきでしょう。

クロスサイトスクリプティングは入出力制御に関する問題です。したがって金融・保険業界、情報通信産業やECサイト関連等の、「オンラインでの商取引を厳格に行う必要がある業界」「個人情報や決済情報を厳密に扱う必要がある業界」では、クロスサイトスクリプティングを含む入出力制御に関する問題への対策が厳格に行われています。これらの業界では開発段階でのソースコード診断やステージング環境での脆弱性診断などを行って必要な修正を施したうえで本番環境へ移行しているケースが多いのです。

このように、シフトレフトの考えに基づいて開発中にソースコード診断を行う、開発の最終段階やWebサイトの改修などの都度こまめに脆弱性診断を行うことで、クロスサイトスクリプティングの脆弱性をより早い段階で解消する効果は見逃せないものではないでしょうか。

クロスサイトスクリプティングの脆弱性を発見し対処する必要性

以前の記事で紹介した裁判事例では、WebアプリケーションにSQLインジェクション脆弱性を発生させた開発会社に対して、実際に損害を被った企業向けに約2,200万円の損害賠償支払いを命じる判決が2014年に下されています。

また、2020年6月に公布された改正個人情報保護法においては、サイバー攻撃によって個人情報漏えいが発生した場合でも、被害者個人(本人)と個人情報保護委員会への通知が義務付けられました。違反には最高で1億円の罰金が科され、悪質な場合は社名も公表されます。2022年の施行に先立ち、具体的な運用方法について年内に政令や規則がまとめられる見通しですが、今後、Webサイトを運営する企業の義務と万が一の場合の責任は重くなることが予想されます。

先にみたように、クロスサイトスクリプティングの脆弱性に気づかず放置することで、フィッシングに悪用されるケースや、不正アクセス、情報漏えいなどさまざまな被害が生じる可能性があります。

本稿執筆時点の2020年、クレジットカード情報をWebサイト上で盗むためにクロスサイトスクリプティングの脆弱性を悪用する攻撃が問題となっており、現在もクロスサイトスクリプティングが脆弱性の代表格であることに変わりはありません。

クロスサイトスクリプティングの対策方法

クロスサイトスクリプティングの脆弱性を生み出さないための対策としては、以下の方法が挙げられます。

1.JavaScript実行のために埋め込まれる特殊文字を変換して処理(エスケープ処理)することや入力文字種を制限して特殊文字を許容しないといった対策を行う

2.正規のスクリプトが悪用されないようにするため、処理中に文字列が意図しないスクリプトとして解釈されないようにホワイトリストなどによる検証を行う

3.DOMベースXSS対策として、DOM操作用のメソッドやプロパティを使用する

4.Webアプリケーション開発にあたって信頼性の高いライブラリを利用する

また、Webアプリケーションへの入力値のチェックなどを行うWAF(Webアプリケーションファイアウォール)を用いた防御なども考えられるでしょう。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決をはかることができない点に注意が必要です。

クロスサイトスクリプティングを脆弱性診断で発見し、適切に対応して利用者の安全を守り、組織の顔であるWebサイトやWebアプリケーションの健全性を維持することは、WebサイトやWebアプリケーションを運営する企業や組織にとって必ず行わなければならない義務といえるかもしれません。

まとめ

・クロスサイトスクリプティングはサイバー攻撃に悪用されるWebアプリケーション等の脆弱性のひとつです。
・蓄積型や反射型、DOMベースなどの種類があります。
・Webサイト等に悪意のあるスクリプトを混入させることで攻撃を行い、ユーザの情報を盗み出すなどの被害が発生します。
・「特殊文字の変換処理」「入力文字種の制限」などの対策実施によって防ぐことができます。
・クロスサイトスクリプティングに限らずWebアプリケーションの脆弱性を積極的に発見し対処することは運営者の社会的義務です。

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

ソースコード診断の必要性とは?目的とメリットを紹介

Share

WEBアプリケーションは、プログラムの集合体であり、 ソースコードとはシステムやWebアプリを動かすコンピュータプログラムのことです。 このプログラムの集合体は現在では人間から読み書きしやすい言語で書かれていることが多くWebアプリケーションは人間にも読みやすいプログラムのテキスト、ソースコードの集合体と言い換えることができるようになっています。

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことですが、その中でも診断対象によりさまざまなサービスがあります。この記事では、その中の「ソースコード診断」を取り上げて、その定義、特徴、メリット、目的などを紹介します。

ソースコード診断とは?

脆弱性診断とは、システムのセキュリティ上の問題点を洗い出す検査のことを指します。
診断対象により、さまざまな脆弱性診断サービスがあります。

まず、企業が開発したWebアプリケーションが挙げられます。
問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。
次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査するネットワーク診断があります。
そのほか、近年増加の一途をたどる スマホアプリケーションや IoT機器を対象とした脆弱性診断もあります。

このうち、ソースコード診断とは、アプリケーションのソースコード(開発者が書いたプログラム)を解析して、セキュリティ上および品質上の問題をコーディングレベルで検査する診断のことをいいます。

ソースコード診断

ソースコード診断には、ツールを用いて自動的に処理するツール診断(自動診断)と、セキュリティエンジニアが目視で確認する手動診断があります。

効率的に網羅性を確保できる自動診断ツールの支援は欠かせません。

一方手動診断は、機械的に検出できず、人間による判断が必要な脆弱性を発見します。手動のみで行う場合もありますが、多くはツール診断と組み合わせて網羅性と精度を上げていきます。

ソースコードを開示するため、ソースコード診断はホワイトボックステストと呼ばれます。これに対して、ソースコードや設計書を見ずに、システムの外部からアクセスして脆弱性や動作を検証する方法をブラックボックステストと呼びます。

ソースコード診断の特徴とメリット

ブラックボックステストでは検出が難しい脆弱性がソースコード診断なら検知できる場合があります。具体的には 「ソースコード診断で検出できる脆弱性」で後述します。

ブラックボックステストは、すでにソフトウェアあるいはシステムが機能していることを前提とした、リリース前あるいはリリース後に実施します。これに対して、ソースコード診断はその前段である開発プロセスから実施できるため、テスト結果を受けてプログラムを修正することが可能です。

開発の手戻りを減らすことでコストや工数削減につながります。詳細は「ソースコード診断の有効性」を参照してください。

ソースコード診断を実施する目的

ソースコード診断の目的は、プログラムに作りこんでしまった脆弱性を網羅的に検出することです。開発時に繰り返し実施し、開発者が修正していく運用が想定されています。

ソースコード診断の有効性

ソースコード診断は開発段階初期から実施可能です。リリース直前やリリース後に脆弱性が発見される可能性を抑えることで、より効率的で信頼性の高いシステム開発が可能になります。

CPE-Coreとはソースコード内の脆弱性と品質面の問題を検査する当社の自動静的解析ツールです。

システムのセキュリティを確保する方法

開発(Dev)、運用(Ops)、セキュリティ(Sec)を一体にしてシステムライフサイクルを回すDevSecOpsという考え方が注目を集めています。DevSecOpsとは、開発の全工程において、開発チームと運用チームが相互協力し、その一環にセキュリティを組みこむことで、アプリケーション開発のセキュリティを確保していく考え方のことをいいます。ここでは、開発プロセスのどこで、セキュリティを確保するための施策を実施するか説明します。

DevSecOpsにおけるセキュリティ対策

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。
セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

一般的なセキュリティ対策として多くイメージされている「Webアプリケーション脆弱性診断」は「テスト」「リリース」工程におけるセキュリティ対策の一つ。
その一つ手前工程の「製造」工程におけるセキュリティ対策の一つが「ソースコード診断」です。

セキュアプログラミング

ソースコード診断の前に、そもそもシステムの設計・開発段階で、開発者が脆弱性を作りこまないようにする手法があります。これをセキュアプログラミングと呼びます。セキュアプログラミングで開発し、本当に脆弱性を作りこんでいないかどうかソースコード診断でチェックします。

ソースコード診断で検出できる脆弱性

一般的なWebアプリケーション脆弱性診断(ブラックボックステスト)では検出しにくい脆弱性も、ソースコード診断(ホワイトボックステスト)では発見できる場合があります。
たとえば未使用のコード、ログファイルによる情報の露出、エラーメッセージによる情報の露出などは、ソースコードを直接確認することで検知可能になります。

以下はWebアプリケーション診断とソースコード診断の両方の観点で検出可能な脆弱性です。
ここでは代表的な脆弱性(セキュリティバグ)について説明します。これらのバグを突く攻撃の名称としても用いられています。

バッファオーバーフロー

プログラムを実行する際に確保するメモリ上のバッファ領域に対して、このサイズを超過するデータを書き込めるようになっているバグです。攻撃者は超過する部分に不正なプログラムを書いて実行します。

フォーマットストリング

プログラム中の、書式設定用の関数(フォーマットストリング)の引数の処理に関するセキュリティバグです。正しくは、引数として不正な値が入力された場合には、処理を止めてエラーメッセージを返さなければなりません。

SQLインジェクション/コマンドインジェクション

SQL(データベースを定義、操作する言語)文や、その他のコマンドが入力された場合でも、エラーにせずに処理してしまうバグです。攻撃者の観点からは、コマンドを注入(インジェクション)する形になるため、この名が付いています。攻撃の入り口はアプリケーション上の通常の入力欄で、ここに不正な値を入力することで攻撃を開始します。

クロスサイトスクリプティング

悪意のあるスクリプト(プログラム)をユーザのコンピュータに注入して、複数のWebサイトをまたいで(クロスサイト)行う攻撃や、その攻撃で利用される脆弱性を指します。

まとめ

・ソースコード診断はソースコード(開発者が書いたプログラム)を解析し、セキュリティ上の問題点を発見する
・開発フェーズの初期から実施することで、リリース直前に脆弱性が発見されるようなスケジュールに影響するトラブルを防止する
・一般的なWebアプリケーション脆弱性診断では検出しにくい脆弱性も、ソースコード診断を実施することで開発段階から検出ができる

Security Report TOPに戻る
TOP-更新情報に戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像