2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WEBアプリにおける『脆弱性』とは??

Posted at

初めに

皆さん、おつかれさマッチョです🦍

今回は、WEBアプリケーションにおける『脆弱性』とは何かについて、備忘録も兼ねて記事を作成しました。

皆さん、「脆弱性にはどのようなものがありますか?」という問いに対してスムーズに答えることが出来ますでしょうか?

お恥ずかしながら自分は、スムーズに答えることが出来ません....

今回の記事は、そのような『脆弱性について詳細に理解していない』方向けの内容となっております。
是非こちらの記事を参考にしていただき、WEBアプリにおける『脆弱性』の危険性等について学んでいただければと思います。

脆弱性とは?

ではまず、『脆弱性』について簡単にお話ししていこうと思います。

『脆弱性』をそのまま解釈すると「脆くて弱い性質」となりますが、意味としてはこの言葉通りとなります。

WEBアプリケーションにおける脆弱性とは....

CGIやサーブレットなどクライアントからの要求に対して、動的に応答するプログラムに内在するセキュリティ上の問題

の事を指します。

つまり、「クライアントからのリクエストに対してサーバーが動的に応答するプログラムにて、特定のセキュリティ問題が存在する」これが、WEBアプリケーションにおける『脆弱性』という事になります。

脆弱性が生まれてしまう原因は?

WEBアプリケーションの開発において脆弱性が生まれてしまう原因は様々だと思います。

が、大きく分けると以下の通りだと思います。

  • アプリケーションの設計ミス
    セッションの管理方法の不備・クライアントからの入力を検証するためのロジックが存在しない、などのコード自体に問題があるパターン

  • サーバに関する設定ミス・アプリケーションの管理ミス
    サーバーに関する設定のミスによる情報の漏洩やアクセス制限の設定ミス・コンテンツ配置ミスなどによって問題が発生するパターン

  • 既知の脆弱性、パッチの未適用
    サードパーティ製品にて発見されたバグに対してパッチの適用漏れによって問題が発生するパターン

1. アプリケーションの設計ミス

Webアプリケーションは複数のプログラムやシステムによって動作しています。Webアプリケーションを構築するプログラム(ロジック)にミスがあることで、不具合が起きる可能性があります。脆弱性が確認されたときに、まず疑うべき箇所の一つです。

2. サーバに関する設定ミス・アプリケーションの管理ミス

プログラム(ロジック)等にミスがなくとも、ネット上に置かれたときに脆弱性が生まれるケースがあります。Webアプリケーションをインストールするサーバーの設定、運営するデータや情報のコンテンツ管理の設定が脆弱性の原因となるケースも少なくありません。

3. 既知の脆弱性、パッチの未適用

Webアプリケーションのインストール時には問題がなくても、時間がたって脆弱性が生まれることもあります。通常は定期的に修正パッチやプログラムが配信されますが、更新作業を怠ることで、既知の脆弱性が放置されたままとなってしまいます。アプリケーション開発者は、使用しているパッケージ等の更新を小まめに行うことが不可欠です。

WEBアプリケーションにおける主要な脆弱性

では、WEBアプリケーションにおける主要な脆弱性について説明していきたいと思います。

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

クロスサイト・スクリプティング(以下『XSS』)は、掲示板や入力確認画面等で、ユーザが入力した内容をそのまま表示するWebアプリケーションが原因となる脆弱性です。

攻撃者が悪意ある任意のスクリプトをWEBアプリ上に仕込み、そのスクリプトがクライアント側で実行されることで、Cookieの盗難などの被害を起こす攻撃となっています。

攻撃者が用意したWEBサイトとXSS脆弱性のあるWEBサイトをまたがって発生するため、「クロスサイト」という名で呼ばれているみたいです🤔

具体的な攻撃例

【掲示板サイトでのXSS攻撃】

前提条件

  • 被害者が利用する掲示板サイトでは、投稿した内容が他のユーザーにも表示される
  • サイトには、投稿内容を適切にサニタイズ(無害化)する仕組みがなく、HTMLやJavaScriptのコードがそのまま表示されてしまう脆弱性がある

攻撃の流れ

  1. 攻撃者が悪意のあるスクリプトを投稿
    まず、攻撃者がとある悪意のあるスクリプトを投稿する。
    例えば、スクリプトが実行されると被害者のブラウザでアラートが表示されるだけでなく、document.cookieで取得したクッキー(例えばセッションID)を攻撃者のサーバーに送信するコードが含まれている。

  2. 被害者が掲示板を閲覧する
    他のユーザー(被害者)が掲示板を閲覧すると、このスクリプトが自動的に実行される。被害者が意識しないうちに、クッキー情報が攻撃者に送信されてしまう。

  3. 攻撃者がセッションを乗っ取る
    もしこのクッキーが被害者のセッションIDであれば、攻撃者はその情報を使って被害者のアカウントにログインし、被害者になりすまして操作することが出来る。これにより、攻撃者は個人情報を盗んだり、アカウントを悪用したりすることが出来る。

2. SQLインジェクション

大抵のWEBアプリケーションでは、背後でDB管理システムが稼働しています。
SQLは、DBに接続する際に使用されるプログラミング言語です。

SQLインジェクションとは、このSQLをWEBアプリケーション内のHTMLフォームやURLパラメータに挿入することで、WEBブラウザ上からDB内の情報を操作してしまう攻撃のことです。

具体的な攻撃例

【ログイン画面上のパスワード入力欄にSQL文を挿入することで、任意のIDでログインを成功させてしまう例】

前提条件

  • ユーザがアカウント情報を入力することで、WebアプリケーションがSQL文を発行。データベース内の情報と照会が行われ、ログインの可否が判断されるという処理が行われる

攻撃の手順

とある入力フォームに、「NozomiGori」というユーザーIDと「0000」というパスワードを入力し、ログインボタンをクリックすると、WEBアプリケーションは以下のSQLを発行し、DBへ照会を行う。

"SELECT * FROM users WHERE userid = 'NozomiGori' AND password = '0000'"

このSQLでDBへ紹介した結果、情報が一致すればログインが成功します。

では、同じログインページで「NozomiGori」というユーザーIDと「'OR' 1 '=' 1」というパスワードを入力し、ログインボタンをクリックしてみます。すると、WEBアプリケーションは以下のSQLを発行します。

"SELECT * FROM users WHERE userid = 'NozomiGori' AND password = ''OR'1'='1'"

これだと'1' = '1'という恒真式がOR演算の対象となってしまうので、WHERE旬全体が常に真(TRUE)となり、パスワードが何であってもログインが成功するようになってしまいます。
URLパラメータでユーザーID・パスワードを送信している場合、アドレスバーへ直接SQL文を挿入することで同じことが可能となってしまいます。

SQLインジェクションはこのように、SQLで利用される特殊記号の入力を、そのまま受付けてしまうようなWebアプリケーションに対して実行できてしまう非常に危険な攻撃となっています。

3. CSRF

クロスサイトリクエストフォージェリ(以下『CSRF』)とは、WEBアプリケーションの「セッション管理」機能に潜む、セキュリティ上の脆弱性を狙った攻撃です。

攻撃者は、WEBアプリケーションにログイン中のユーザーに不正なリンクを踏ませるなどして、あたかもそのユーザーが操作をしたかのように、WEBアプリケーションに不正なリクエストを送信。アプリケーション側は「ログイン中のユーザーから送信されたリクエストだな。」と認識して、不正なリクエストを実行してしまいます。

CSRFの具体的な被害内容として、『ECサイトやオンラインバンキングで身に覚えのない決済をさせられる』『SNSや掲示板で意図しない投稿をされる』などがあります。


ログインした利用者からのリクエストが、「正規のリクエストか?それとも不正なリクエストか?」を識別する仕組みを持たないWEBアプリケーションだと、その脆弱性から攻撃対象になりやすくなってしまいます。

具体的な攻撃例

【オンラインバンキングの振込操作を悪用するCSRF攻撃】

前提条件

  • 被害者(ユーザー)は、あるオンラインバンキングサービスにログインし、セッションが有効な状態にある
  • 攻撃者は、このバンキングサービスにおける振込操作を悪用したい

攻撃の流れ

  1. 攻撃者が仕掛ける罠ページの準備
    攻撃者は、とあるリンクを含む悪意のあるページを作成する。
    例えば、画像のURLに見せかけて、実際には攻撃者の口座に振り込むリクエストを送るリンクなどである。

  2. 被害者が罠ページを開く
    被害者が攻撃者の送ったリンクやメール、SNSで共有されたリンクをクリックして、この罠ページを開いてしまう。

  3. 被害者のセッションを利用して不正リクエストが送信される
    被害者が罠ページを開いた瞬間、バックグラウンドで攻撃者の用意したリクエストが自動的に送信されてしまう。このリクエストは、被害者が既にバンキングサービスにログインしている状態のセッションを利用して実行される。

  4. 被害者の口座から攻撃者の口座に送金が行われる
    バンキングサービス側では、正規のユーザー(被害者)からのリクエストとして認識され、攻撃者の口座への送金が実行されてしまう。

最後に

今回は、WEBアプリケーションにおける脆弱性について主要なものをピックアップして、備忘録としてまとめさせていただきました!


私自身、脆弱性についてある程度分かっていたつもりですが、いざ説明するとなると出来ないというかなりお恥ずかしいレベルでした...💦

今後WEBエンジニアとしてWEBアプリケーションの開発を行っていく上で、脆弱性は必ず理解しておかなければいけない技術の内の一つなので、今後も脆弱性に関する技術記事を都度作成していこうと思います💪🔥

ここまで拝読いただき、ありがとうございました🦍

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?