他の記事
結果が公表されたので、報告したけど既に他の人が報告済みで報奨金をもらえなかった脆弱性と、すでにLINEが把握しているからと認定されなかった脆弱性を紹介する。
【コーポレート】脆弱性報告による報奨金支払い制度「LINE Bug Bounty Program」の結果について | LINE Corporation | ニュース
アクセストークンを平文で送信する
すでにLINEが把握しているからということで認定されなかった。
LINEの認証はX-Line-Access
という独自HTTPヘッダを付与することで行われている。ユーザー検索などで他人のプロフィール画像を表示するときは、http://obs-jp.line-apps.com/os/p/uユーザーID/preview
から取得していた。このとき、HTTPなのにX-Line-Access
が付与されていた。うろ覚えだけど、このX-Line-Access
を使っても、他のLINEの操作はできなかった気がする。だから後回しだったのかも。今はプロフィール画像の取得がHTTPSになっている。
*.line-apps.comの重要なCookieにセキュア属性が付与されていない
9月9日に報告。すでに他の人が報告済みとのことでダメだった。
LINEバイトなどがこのドメイン上でウェブサイトとして実装されている。利用規約によると、「(15) 重要ではないCookieのセキュアフラグ属性の不在」は対象外らしいが、セッションIDという重要なCookieにもセキュアフラグが付与されていなかった。
普通のウェブサイトならば、ターゲットにHTTPのページを踏ませれば奪取できるけれど、LINEの場合はアプリ内のWebViewで動いているので、ブラウザで開かせても意味が無い。LINEに送ったリンクはアプリ内のWebViewではなく、ブラウザで開かれてしまう。幸い、画像等の静的リソースはHTTPで取得しているので、この通信を書き換えて、http://hogehoge.line-app.com
にリダイレクトさせるとCookieが取得できる。
LCSLoaderのXSS
同じく、9月9日に報告。
LINEバイトなどが読み込むLCSLoader_20150326.jsには下記のような部分がある。
sVer=getValueFromCookie("cordovaVersion");
:
document.write('<script type="text/javascript" src="https://scdn.line-apps.com/channel/sdk/js/android/' + sVer + '/cordova_20150326.js"></script>');
一見、Cookieに値を書き込めるのはLINEのサイトからだけなので、Cookieの値をエスケープせずに書き出しても問題は無いと思える。このスクリプトが読み込まれるのがHTTPのサイトだけならば確かにそうだが、HTTPSの場合は、HTTPでCookieを改竄することでHTTPSのページにスクリプトを注入できるので問題になる。
このサイトも静的リソースはHTTPで読み込んでいるので、上記のセキュア属性無しCookieと同様にリダイレクトして、その通信を改竄してCookieを書き換えることができる。ただし、このスクリプトが実行されるのはページが読み込まれるときのみで、以降の操作はAjaxで処理されている。一旦LINEに戻り、LINEバイトを開いてもLINEバイトを開く直前にアプリでCookieが上書きされてしまう。parttime-channel.line-apps.com
ではなくline-apps.com
に対してCookieを発行することで、スクリプトが動いた。Cookieはドメインが短い方が優先されるらしい。
Cookieを経由するというちょっと変わったXSSだし、攻撃するには違うドメインにCookieを発行するという一工夫が必要なので、これはいけるかなと思ったものの、他の人が先に報告していたとのこと。残念。もっと早くに探していれば……。