猫でもわかるWebプログラミングと副業

本業エンジニアリングマネージャー。副業Webエンジニア。Web開発のヒントや、副業、日常生活のことを書きます。

情報セキュリティスペシャリスト(情報処理安全確保支援士)H27春午後Ⅰ問1 セッションハイジャック/セッションフィクセーション

もくじ

f:id:yoshiki_utakata:20180413095415j:plain

過去問ページ

IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2015、平成27年)

設問1 (1), (2)

Cookieドメインに紐付いています。Cookieのsecure属性を付けないと、http通信でもCookieが送信されてしまうため、盗聴の危険があります。

kenzo0107.hatenablog.com

よって(1)としてはhttp通信である画面Bが正解、(2)は上記に述べたとおりです。

設問2

(1)

これは問題の誘導があまり良くないと思う。

U主任: 図6全体を通して気になる点はありますか

これでどうしても図6ばかり見てしまうが、どちらかと言えば重要なのは図4である。(あるいは、図9をまで見るとヒントのようなものが書いてある)

商品検索が実行されると、サーバーは応答時に名前がKENSAKUであり、値を検索文字列とする Set-Cookie ヘッダを返す。

ここに注目しなければならない。HTTPのヘッダとボディは改行によって分かれている。商品検索をする時に

/search?query=jewelry と検索すると *1 、レスポンスヘッダに

Set-Cookie: KENSAKU=jewelry

が返ってくるわけだ。その結果図6のリクエストZのように、Cookie: KENSAKU=jewely というCookieがつくようになる。

ここで、検索クエリを図7のようにするのだ。図7のa以外の部分を文字列エンコード無しで見てみるとこうなっている

<html><body><scritpt>alert("1")</script></body></html>

scriptタグが埋め込まれている。aの解答は %0d%0a%od%0a だが、これは図8のASCIIコードで見ると CR LF CR LF である。CRLFは改行を表しているので、%0d%0a%od%0a は改行2つである。図7のクエリを検索ページのリクエストにつけるとこうなる。

/search?query=%0d%0a%od%0a%3chtml%3e%3cbody%3e%3cscritpt%3ealert%28%221%22%29%3c%2fscript%3e%3c%2fbody%3e%3c%2fhtml%3e

システムが改行を正しく処理できていないと、レスポンスヘッダには以下のようになってしまう

Set-Cookie: KENSAKU=

<html><body><scritpt>alert("1")</script></body></html>

KENSAKU= の部分で改行されてしまうのである。ここで、HTTPの仕組みにより <html><body><scritpt>alert("1")</script></body></html> この部分はレスポンスヘッダではなくレスポンスボディとして処理されるので、スクリプトが実行されるという仕組みである。

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

攻撃者がページにscriptを埋め込む攻撃方法をクロスサイトスクリプティングという。

(3)

「改行文字を除去する」など改行によって影響でないような変更であれば良いと思われる。

設問3

(1)

これは、ログイン前に払い出されるセッションとログイン後に払い出されるセッションのIDが一緒であること(あるいはログイン前にセッションIDが払い出されてしまっていること)が後述のセッションフィクセーションの問題につながってきているので、見比べるべきは

  • 09行目または17行め(ログイン前のセッション)
  • 27行目(ログイン後のセッション)

である。少しわかりづらい問題ではあるかなと思う。

(2), (3)

セッションフィクセーションの問題で、攻撃者Jは利用者Kのアカウントになりすますことを目的としている。攻撃者Jが払い出したセッション01234を利用者KのCookieにセットした上で利用者Kにログインさせようというものである。ログイン前にセッションIDが払い出されており、かつログインした後もセッションIDが変わらないことを利用した攻撃手法である。

ここで設問2の脆弱性を利用して、改行の後にSet-Cookie: SESSIONID=01234を付けたようなクエリを、脆弱性のある画面Cをつかって利用者Kに送り込む。これで利用者KはCookieのセッションIDが01234になってしまい。その後まんまとログインさせられてしまうわけである。

攻撃者はセッションID01234を利用することで利用者KとしてこのWebシステムを利用できるようになる。

fに入る文字は 01234 となる。

(3)については上記で述べた通りである。

(4)

ログイン後に新しいセッションIDを払い出したり、あるいはログイン前にセッションIDが不要なのであれば払い出さないといった対策が考えられる。

参考

*1:URLは一例。問題文中には出てこない