オンラインショッピングにおける脆弱性の注意点：Webアプリケーションに潜むセキュリティホール（9）
※ご注意
他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。
また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。
今回はオンラインショッピングの機能について調べてみよう。前回までの解説で検査対象としてきたデモサイトにもショッピング画面があるのだが、セッション管理方法が同じだと、これまでと似たような説明になってしまうため、今回はデモサイトは使わずに説明していくことにする。なお、説明に出てくるアプリケーションの仕様は、筆者が独自に考えたものであり、特定のWebサイトを指しているわけではないので注意していただきたい。
検索サイトでショッピングサイトについて調べてみると、さまざまなサイトが存在することが分かる。これらのサイトは仕様はそれぞれ異なるが、含まれる機能はほぼ同じである。
小規模ショッピングサイトにおける脆弱性
小規模のサイトでは、商品を決定して「注文」ボタンを押すと、その内容がメールで送信され、その後の手続きはメールベースとなることが多い。このようなサイトに関しては、今回は対象外とさせていただく。参考までに、このような小規模サイトに存在する可能性がある脆弱性について簡単に説明しておこう。
住所などの個人情報を平文で送信している（SSLを使用していない）
小規模サイトでは会員登録というものがなく、商品購入時に、発送先の情報をすべて送信することが多い。そのため、注文ごとに個人情報を送信することになる。
さらに、このようなサイトは予算の都合もあり、サーバ証明書を使用していないことが多い。重要な情報を送信する場合はSSLによる暗号化を行うべきである。
注文時に入力した個人情報が、Webサーバ上のCSVファイルに記録される
この仕様が全く悪いわけではない。正しい場所にCSVファイルを置いているなら、それで問題はない。問題があるサイトは、このファイルを公開ディレクトリの中に置いてしまっている。ディレクトリ内のファイル一覧が見えなければファイルを見つけることは難しいが、脆弱なサイトでは、このファイル名に関しても「kokyaku.csv」などといった、ありきたりの名前を付けてしまっている。ファイル名の付け方にも注意が必要である。
メール送信時のサニタイジング（無害化）漏れ
これに関しては、前回の「問い合わせ画面に含まれる脆弱性」で説明したようなことと同じである。メールを送信するので、踏み台にすることができるかもしれない。また、うまくいけばOSコマンドも呼び出せたりするかもしれない。この辺りは、完全に実装の仕方次第である。
大規模ショッピングサイトの場合
さて、ここからが今回の本題である。ショッピングサイトには大きく分けて2種類がある。
1つはモノを購入するサイトである。注文すると宅配便などで品物が配送されてくるサイトのことだ。もう1つは、デジタルコンテンツを提供しているサイトである。デジタルコンテンツとは、画像や音声、映像などのデータや、ゲームなどのことを意味する。このようなサイトでは、アプリケーションが脆弱である場合、タダで商品をダウンロードできてしまうため、より注意が必要だろう。
まずは、ショッピングサイトに含まれる主要な機能についてまとめておこう。
- ユーザー登録
- ログイン
- ログアウト
- 商品一覧表示
- 商品詳細表示
- 商品をカートに追加
- カート内の商品を確認
- 配送先の指定
- 決裁方法の指定
細かい機能はほかにもいろいろあるだろうが、最低限必要な機能はこれくらいだろうか。これらの機能を画面遷移順に並べると、図1のようになる。実際には、商品をレジに持っていく際にログイン処理を求めるような仕様にもできるので、必ずこのような画面遷移になるわけではない。
図1 一般的なショッピングサイトに含まれる画面遷移もう1つ、デジタルコンテンツを購入するサイトの例も挙げておこう。主な機能は以下のとおりである。
- ユーザー登録
- ログイン
- ポイント購入
- コンテンツ購入
- ログアウト
先ほどのように、画面遷移図にすると図2のようになる。
図2 デジタルコンテンツを購入するサイトの例本稿はアプリケーション開発が目的ではないので、実装上の細かい点は気にせず、先に進むことにする。
ショッピングサイトが前述したような機能を持っている場合に存在する可能性がある脆弱性について説明していこう。
特に注意が必要な個人情報漏えい
大規模サイトではユーザー登録が必ず存在する。ショッピングサイトの場合は、クレジットカードの情報も登録できるところが多いため、特に気を付ける必要があるだろう。
まず、この情報が漏れるとしたら、どの機能において漏れるのか考える。実装方法に依存するが、以下の点が脆弱であると、個人情報漏えいにつながる。
セッション管理方法
セッションハイジャック（Session Hijack）やセッションリプレイ（Session Replay）、セッション・フィクセイション（Session Fixation）による攻撃を受けた場合、他人へのなりすましが可能となるため、必然的にその人の個人情報にアクセスできてしまうことになる＊1。
ただし、サイトが大きくなると、それなりにしっかりとした作りになるので、セッション管理自体が貧弱であるということはほとんどない。大規模サイトにおける個人情報漏えいは、「正しいセッション管理方法を使用しているのに、セッション管理を使用していない部分」において発生する。アプリケーションに渡されるパラメータの中に、セッションID以外のパラメータが入っていたら要注意だ。
この脆弱性は、ショッピングサイト固有の問題ではないので、あまり深入りせずに、これくらいにしておこう。
設定された価格以外での購入を許すな
価格がパラメータとしてURLやhiddenに入っていて、書き換えが可能な場合がある。この場合、書き換えた値がそのまま通ってしまうことがある。注文を受けた企業側が価格のチェックをちゃんと行っていない場合は、その価格で購入できてしまう。価格を改ざんされないような仕組みにすることが必須だが、注文時に、商品DBとの相互チェックが必要だ。小規模のショッピングサイトでは、管理者の目によるチェックだけになってしまうこともあるだろう。この場合、けた数の違いなら気付くだろうが、数％の違いには気付かない可能性がある。
メジャーなショッピングサイトでは、注文は商品番号を使い、価格はDBから取ってくる仕様がほとんどである。このようになっていると価格を書き換えることは難しくなる。
価格を書き換えることはなかなかできないかもしれないが、デジタルコンテンツの販売サイトは特殊であるため、別の方法によってタダで購入できてしまう場合がある。
デジタルコンテンツの場合は、前もって貨幣の代わりとなるポイントと呼ばれるものを購入し、商品の購入にはそのポイントを使用する仕組みのことである。
ポイント自体を購入する画面では、前述したように価格を書き換えられない限り、安く購入したりすることは難しいだろう。しかし、購入したポイントは、各個人のアカウントに結び付けられる。そのため、認証をバイパスできれば、無料で商品を手に入れることができるかもしれない。認証をバイパスする方法の1つに、SQLインジェクション＊2がある。SQLインジェクションにより認証が成功した後、実際に商品が購入できるかどうかはアプリケーションの実装次第となる。
金を払わずに購入できてしまう場合、実際にはポイントは支払われているかもしれない。この場合、自分以外のだれかのポイントを使っていると思われる。もしくは、ポイントを減らす部分のSQL文もうまくバイパスされ、実際にはポイントが消費されていないにもかかわらず、ポイントの消費に成功したように処理されてしまっているのかもしれない。
どちらにしろ、攻撃者は1円も支払わずに済むため、攻撃は成功である。このように、デジタルコンテンツ販売サイトでは、特に注意が必要である。
他人のショッピングカートの中身を見る
他人のショッピングカートの中身が見えたところで、住所や電話番号まで見えるわけではないが、一応「他人の情報」にアクセスする、ということで、これも脆弱性の1つである。
この脆弱性は、実装上の欠陥により発生する。各ユーザーのショッピングカートに関する情報をどこで管理しているかがポイントとなる。ショッピングカートに関する情報をすべて1つのセッションIDで管理してしまっている場合、セッションIDが脆弱でない限り、他人の情報にはアクセスできない。しかし、ショッピングカートのセッション管理を別にしている場合も考えられる。
例えば、次のような仕様のサイトもあり得るだろう。
1.ショッピングサイトにアクセスすると以下のようなCookieが発行される。
これがショッピングカート用のセッションIDである。
Set-Cookie: cartid=80habc8g270jak3hfh3dhf12bv03
2.ショッピングカートに商品を入れる。
商品情報は cartidを使ってサーバ側で管理されるため、ユーザー側のパラメータは何も変化しない。
3.ショッピングカートの情報を参照するには以下のURIにアクセスする。
viewcart.cgi?cartid=80habc8g270jak3hfh3dhf12bv03
この仕様では、手順1と2は特に問題はないのだが、手順3に問題がある。まず1つ目として、Cookieに入っているパラメータをわざわざURLパラメータとして渡している点である。URLパラメータはProxyやWebサーバのログにすべて残るため、重要なパラメータは付けるべきではない。
2つ目は、上記の処理手順を見ただけでは分からないのだが、実はここに重大な欠陥が存在する。Cookie内にもcartidがあり、URLパラメータにも同じパラメータが付いている。
ここで、Cookie内のcartidを消してからアクセスした場合、どうなるのだろう？ という疑問が出てくる。そこで、実際に試してみると、URLパラメータに付けたcartidが、Set-Cookieで発行されることが分かる。
つまり、他人に手順3のURIにアクセスさせることで、その人のcartidを指定できてしまう。被害者がそのままショッピングを開始した場合、攻撃者はそのcartidを使って、そのユーザーのカートを参照することができる。場合によっては、カートに商品を追加したりすることも可能かもしれない。
これは、セッション管理に対する攻撃であるセッション・フィクセイションと同じ考え方である。
そのほかの脆弱性
ここまでに説明した脆弱性以外には、以下の脆弱性の存在が考えられる。
商品情報を表示するアプリケーションにおけるSQLインジェクション
商品情報を表示するアプリケーションは、必ず商品IDをパラメータとして渡している。アプリケーション内部では、DBから取得していると思われる。このため、この部分はSQLインジェクションの対象となり得る。
配送先住所入力画面におけるクロスサイトスクリプティング
オンラインショッピングでは、ショッピングカートに入れた商品を精算する際、配送先の住所を入力する。この画面は、
- ショッピングカートに商品を追加
- レジに持っていく
- 決済方法の選択
- 配送先の入力
- 買い物完了
といった画面シーケンスの途中に存在する。そのため、この画面に直接アクセスできる場合には、クロスサイトスクリプティングが成功する可能性がある。
このように、ある一連の画面シーケンスの途中の画面に直接アクセスする攻撃は、前回の「問い合わせ画面に含まれる脆弱性」で説明したような方法が使える。まったく別の名前のアプリケーションを使っているのであれば、それに直接アクセスすればよい。
このような脆弱性はテクニカル系に分類されるものであるため、詳しい説明は必要ないだろう。ただし、テクニカル系の脆弱性であっても、アプリケーションのロジックを考えながら検査しないと見つからない場合もあるため、注意が必要である。
←「第8回」へ
「第10回」へ→
著者紹介
中村隆之（なかむらたかゆき）
三井物産セキュアディレクション勤務。 セキュリティコンサルタントとして主にWebアプリケーションのセキュリティ検査に従事しており、大手ポータルサイト、オンラインバンキングなどの数多くの 検査実績を持つ。また、セキュアネットワーク及び暗号関連の研究に携わり、大手製造、官公庁、金融機関へのセキュリティシステム導入など数多くの実績を持つ。
主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サービスも実施中。
- Webアプリケーションの脆弱性を総括する
- OSコマンドインジェクションを防ぐルールを作成する
- mod_securityのXSS対策ルールを作成する
- Webアプリケーションファイアウォールによる防御
- 安全なWebアプリケーション開発のススメ
- オンラインショッピングにおける脆弱性の注意点
- ロジック系の検査 〜 問い合わせ画面に含まれる脆弱性 〜
- Webアプリケーションの検査（3）〜 攻撃されないためのセッション管理の検査方法 〜
- Webアプリケーションの検査（2）〜 Webサイトのセッションまわりを調べる方法 〜
- Webアプリケーションの検査テクニック（1）
- エラーメッセージの危険性
- 気を付けたい貧弱なセッション管理
- 顧客データがすべて盗まれる？！〜OSやデータベースへの攻撃〜
- サーバのファイルが丸見え？！
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。