カテゴリー: Security

htmlspecialcharsは脆弱

追記：現在のPHPでは問題ありません。パフォーマンスを考えるとhtmlspecialchars()の利用をお勧めします。新しいエントリを参照してください。

PHPのHTMLエスケープ

PHPにはHTMLの文字列として出力する関数が2種類あります。

• htmlspecialchars() <,>,&,’,”等のHTML特殊文字をエンティティ化する
• htmlentities() HTMLエンティティ化が必要な文字全てをエンティティ化する

あまり脆弱性に関係なさそうですが文字エンコーディングとの組み合わせで攻撃に利用される可能性があります。このようなシナリオです。BBSやブログのコメントなどユーザが送信したデータをHTMLページの一部として表示するアプリケーションがあるとします。

• ワザとアプリケーションが期待している文字エンコーディングと異なる文字エンコーディングでデータを送信し、その中にJavaScriptを実行可能なデータを入れる
• データが保存されページが表示された際には異なる文字エンコーディングのデータが表示され文字化けする。

通常、文字化けしたページが表示されるにとどまる場合が多いと思われますが以下の状況が考えられます。

• 文字エンコーディングが指定されていない場合、ブラウザが文字エンコーディングを自動判別し本来の文字エンコーディングとは異なる文字エンコーディングが利用されていると判断しJavaScriptが実行される。
• ユーザが文字化けしたコンテンツを参照するために「明示的」に文字エンコーディングを変更し、その際にJavaScriptが実行される

htmlspecialcharではISO-2022-JPのマルチバイトスタート文字列などはエンティティ変換されないため意図した文字エンコーディング以外でページが表示された場合、JavaScriptが実行される可能性があります。htmlentitiesで変換していれば指定された文字エンコーディング以外のデータはエンティティ変換されます。このため意図した文字エンコーディング以外の文字エンコーディングでページが表示されてもJavaScriptが実行されることはありません。

本来、すべてのアプリケーションはユーザからの入力等が正しい文字エンコーディングがあるかチェックし不正なエンコーディングが含まれている場合はエラーとして処理を停止すべきです。このように正しく入力をチェックしている場合はhtmlspcialcharsを利用していても問題が発生する事はありませんが、このチェックが無い場合はhtmlentitiesを使用していないとJavaScriptインジェクション（XSS)に対して脆弱になります。

UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意
http://slashdot.jp/security/article.pl?sid=05/12/21/2318216

これはUTF-7を使用した例です。scriptタグを隠すSJIS、EUC-JP、ISO-2022-JP等を利用した攻撃例も知られています。

RavMonE.exe付きVideo iPod

なんとなくMacつながりでウィルス付きMP3プレイヤーの次はウィルス付き（RavMonE.exeは感染型Adwareだそうです）Video iPodが出荷されていたそうです。

http://www.wagang.jp/blog/logdata/eid64.html によると

RavMonE.exeウイルス。こいつに感染すると、リムーバブルディスクのアイコンがダブルクリックで開かなくなり、アクセス速度が遅くなったりします。実害はそれだけ。でも、凄くウザイ。
で、これがまたヘンなウイルスみたいですねえ。このページでは、传染性杀毒软件、すなわち「伝染性アンチウイルスソフト」と称しています。なんでも、中国国産アンチウイルスソフト、瑞星殺毒の自動監視をONにしてると、リムーバブルディスクが監視対象になってRavMonE.exeが自動でコピーされ、ダブルクリック時にエクスプローラを開かずにRavMonE.exeを実行するようにレジストリが書き換えられる、そのEXEファイルと設定が、当該リムバディスクを繋いだ他のパソコンにも連鎖的にコピーされていく、ってことみたいです。

と記述されています。アンチウィルスソフト（瑞星殺毒）の自動監視機能で感染?というのはよく分からないですがミイラ取りがミイラになった、ということなのでしょう。RavMonE.exeでぐぐると中国語のサイトがかなりヒットします。Appleの書き方だと「こんなウィルスに脆弱なWindowsが悪い」などと書いているので瑞星殺毒の自動監視をONにしていなくても感染するようにも思えます。いずれにせよ実行すれば同じことなのでRavMonE.exeがiPodに入っていたら実行しないことが重要と思います。信頼できると思われる製品にexeファイルが入っていたら普通、実行してしまうとは思いますが..

We recently discovered that a small number – less than 1% – of the Video iPods available for purchase after September 12, 2006, left our contract manufacturer carrying the Windows RavMonE.exe virus.

2006年9月12日以降に購入したVideo iPodに影響があるようです。どこの地域に出荷されたiPodが対象になるのか分かっていれば記載した方が親切と思います。誰かが意図的に添付したのか事故で入ったのかどうなのか分かりませんが一般的なアンチウィルスソフト（Norton AntiVirus、McAfeeなど）で検出&修復できるようです。iPod nano and iPod shuffle には影響ないようです。

we are upset at Windows for not being more hardy against such viruses

一応ウィルスを検出できなかった自分たちにも腹が立つがこのようなウィルスに簡単に感染するようなWindowsに腹が立っているのだそうです。この一文は余計なお世話なような.. Apple製のソフトウェアにも脆弱性はありますから。しかも、自動感染するのは瑞星殺毒の脆弱性のようにも読み取れるのですがどうなんでしょう?

http://www.wagang.jp/blog/logdata/eid64.html には

当該リムバディスクを繋いだ他のパソコンにも連鎖的にコピーされていく

とあるのでやはり一旦感染するとどんどん感染していくのでしょうか?だとすると「瑞星殺毒の自動監視をON」しているかどうか関係なく「Windowsの脆弱性」が問題となると思います。未修正のWindowsの脆弱性が原因なら、同じ脆弱性を利用した未知のマルウェアが無いとも限りません。他人のUSBメモリをさすのは非常に危険ということになります。実際のところはどうなのか気になるところです。
# 中国語が読めればもう少し情報が得られそうですが読めません。

• 「瑞星殺毒の自動監視をON」-> 自動実行設定なしにRavMonE.exeに感染
• RavMonE.exeに感染したPCは接続されたメモリ等に自動実行設定行う -> Windowsの自動実行機能によりRavMonE.exeに感染

となって自動実行機能の問題ということかな?読み込み専用メディアでさえ自動実行機能のリスクは高く自分が使うPCはこの機能をOFFにしています。もしかして書き換え可能なメディアでもautorun.infを使うと自動実行できると言う事?（時間もないので試してません。もしそうだとしたらかなり悪い仕様ですね..「we are upset at Windows」と言うのも理解できる.. 時間ができたら試してみよう）

F-SECUREのブログでこの問題に気が付いたのですがここで検索してみてもRavMonE.exeでは情報は見つかりませんでした。他のサイトによると7月くらいには見つかったマルウェアらしいのでメジャーなアンチウィルスソフトには入っているようです。探し方が悪かったのかSymantecのサイトでも何も見つかりませんでした。

追記：USB接続したメディア内の“autorun.inf”を自動実行できる「APO Usb autorun」の様なユーティリティがあるのですね。やはりデフォルトでUSBメモリ内のautorun.infを実行するような馬鹿な事はしていなかったようです。であれば別の方法で感染するということなのか、単純にEXEファイルだけをコピーするのかどちらなんでしょう。
http://prism-project.sakura.ne.jp/usb_memory/usbmmain2.html によると

上の表の通りUSBメモリでは自動実行ファイルであるautorun.infを入れた場合アイコンの変更はできてもファイルの実行はできないという事です。従ってUSBメモリにランチャー等を入れてautorun.infで実行ファイルに指定してもランチャーは自動起動せず動作の選択画面が出るという事です。

とあります。当然の仕様だと思います。USBメモリをさすと勝手にプログラムが実行されるようでは昔のFDDのブートセクタウィルス状態になります。iPodの件はPCがRavMonE.exeに感染しiPodを検査した際に勝手にコピーされたということだったと思われます。Windowsの脆弱性ではなくアンチウィルスソフトの脆弱性で自動感染するようなので「we are upset at Windows」の意味がよく分からない.. MacOS Xの場合はソフトをインストール場合に管理者パスワードが要求されることがありますが、Windowsでは普通は「管理者権限」を持つアカウントでないと「使えない」情況にあることを指して「we are upset at Windows」ということなのかも知れません。ネットにはUSBの場合でも自動実行できてしまう（USBでも自動再生機能で再生するアプリケーションは選択できますが自動でプログラムは実行できない模様。自動実行と自動再生には大きな違いがあります）と勘違いして記載されているページもあるようです。これが「we are upset at Windows」の理由なのかも?!

ちなみに自動再生機能を無効にするにはSHIFTキーを押しながらドライブを開きます。Tweak UIにも自動再生の設定項目があります。

サポート期限切れの製品 – Webサイトで警告を出すのが良いかも?

今月のWindows UpdateでWindows XP SP1用の最後のアップデートだったそうです。SP2にしないとパッチ無しになります。Windows XP SP2以上でないとインターネットに接続してはならないPCということになります。(Windows 95/98/ME等は問題外）大多数のユーザはSP2にしているとは思います。しかし、古いOSやアプリケーションをそのまま使い続けている方も多くいるはずでそういったPCがボット化していくのだと思うと困ったものです。

このブログの場合、

• Windows利用者の中でWindows 95/98/Meを利用されている方は約1%
• IEでアクセスされている方の約1%がIE5.x以下ブラウザを利用(IE5.x以下は全てサポート期限が切れています)
• Firefoxでもセキュリティホールがある古いバージョンを利用されている方が5%程

といった感じです。(Google Analyticsの統計情報より）
# ブラウザ全体の内訳はおおよそIE64%、FF28%、その他ブラウザ8%です。
# 一般的サイトに比べるとかなりFF、その他ブラウザが多いです。

そこで「このサイトを見るにはIE5.5以上、Firefox1.0以上で快適にご覧いただけます」と記述しているページを設けているサイトは多いです。少なくともこのページに「20XX年X月XX日時点の情報によると、あなたのOS（ユーザのOSとバージョン）、ブラウザ（ユーザのブラウザとバージョン）には既知の脆弱性があります。早急にアップグレードお勧めします」と記載してはどうでしょうか?メーカーの問い合わせ先URLなどを記載していてもサイトに問い合わせするユーザがいて困るかも知れないので尻込みしそうですが、こうすれば少しはアップグレードのモチベーションが上がるかもしれません。

以下のページにWindows関連のサポート期限がまとめられています。
http://www.st.ryukoku.ac.jp/~kjm/ms-windows/support.html

エンドユーザは意外にこういった情報を知りません。本来はメーカーのホームページの簡単にアクセスできるところにこういった情報が載っているべきと思います。

RSSリーダへのインジェクション

少し前にセキュリティ系のMLに「RSSにインジェクション」と言う話題があったのですが実際に調べるとインジェクション出来てしまう物が結構あるようですね。全て使った事が無いものばかりですが

– Ykoon RssReader CVE-2006-4762
– SharpReader CVE-2006-4761
– RSSOwl CVE-2006-4760

等があるようです…

RSSOwlはJavaアプリケーションのようですね。リンクをクリックしてブラウザを立ち上げるとJavaScriptが実行されて… と言った攻撃方法なので信頼できるサイトのフィードなら大丈夫ですが、MLやブログコメント等のフィードは危険性が高くなります。

ところで、Firefox, Thunderbirdのアップグレードでてますね。

MFSA 2006-64 Crashes with evidence of memory corruption (rv:1.8.0.7)
MFSA 2006-62 Popup-blocker cross-site scripting (XSS)
MFSA 2006-61 Frame spoofing using document.open()
MFSA 2006-60 RSA Signature Forgery
MFSA 2006-59 Concurrency-related vulnerability
MFSA 2006-58 Auto-Update compromise through DNS and SSL spoofing
MFSA 2006-57 JavaScript Regular Expression Heap Corruption

ブラウザ関係ではFlashplayerのクリティカルなアップデートも出ています。私はこれを機会にWindowsはFlash Player9にしました。
# Linux、Solaris用のFlash Player 7はアップグレード版があるようですね。
# Zero3 esのFlash Player 7などはどうしろと言うこと…

Flash Player 8 update (8.0.33.0), and Flash Player 7 update (7.0.66.0 or 7.0.68.0) address security vulnerabilities in previous versions of Flash Player. Updated versions of Flash Player 7 for Linux and Solaris, which contain fixes for these vulnerabilities, are also available from the Adobe Player Download Center.

http://www.adobe.com/support/security/bulletins/apsb06-11.html

PEAR DBのPostgreSQLドライバにセキュリティホール

この脆弱性は本家にはレポートしてあるのですが簡単な1行パッチなのにまだCVSにさえ適用されていません。詳しく解説したつもりなのですがシングルバイト圏の開発者には理解が難しい(?)か私の説明が悪かった(?)のかも知れません。とりあえず「作業中」との旨のメールが帰って来ていますが遅すぎなので特に影響が大きいと思われる日本のサイト向けとして問題の概要と対処方法を書いておきます。

文字エンコーディングを利用したSQLインジェクションに詳しい方ならどのような条件でSQLインジェクションが可能になるか簡単に分かります。addslashesやstr_replaceによるエスケープが危険であることは広く知られている既知の問題といえると思います。英語で記述されたブログ等にもエンコーディングとエスケープの問題を取り扱ってるページもあります。あまり長期間放置していると近い将来悪用される危険性があります。

このパッチを有効に利用するには使用しているPostgreSQLサーバのバージョンに関わらず、PostgreSQL 8.1.4以降のlibpqを利用してPHPのPostgreSQLモジュールをビルドする必要があります。
# これはPostgreSQL 8.1.4以降のlibpqを利用しなければならいない
# 点はPEAR DB/PHPに限らず、PostgreSQLアプリケーション全般として
# いえます。

[yohgaki@dev pear]$ cat DB/DB/DB_pgsql.php.patch
Index: pgsql.php
===================================================================
RCS file: /repository/pear/DB/DB/pgsql.php,v
retrieving revision 1.129
diff -u -r1.129 pgsql.php
— pgsql.php 10 Jun 2005 14:31:45 -0000 1.129
+++ pgsql.php 17 Aug 2006 09:34:16 -0000
@@ -531,7 +531,7 @@
*/
function escapeSimple($str)
{
– return str_replace(“‘”, “””, str_replace(‘\\’, ‘\\\\’, $str));
+ return pg_escape_string($str);
}

// }}}

他のDBアクセス抽象化ライブラリにも同じ脆弱性がある可能性が高いと思われます。パッチ自体は簡単なのでDBアクセスアクセスの抽象化ライブラリを利用されている方は一度調べた方が良いと思います。

IEEEのセキュリティサイト

A Process for Performing Security Code Reviewsのような記事が公開されています。The State of Web Security等は何かプレゼンテーションを作る場合に役立ちそうです。

基本的にはブログのようになっているようです。しかし、ここの記事は時間が経つと買わないとならない(?)ようです。画面上部の”Contents”リンクをクリックすると有料コンテンツのリストが表示されます。Process for Performing Security Code Reviewsは$19だそうです。Adsenseでも何でも良いので広告を付けて無料にしてくれればありがたいのですが。# 日本語で書いていても何の効果もないでしょうけど。

リモートファイルの読み込みが可能なPHPアプリ多数

PHPには

require(‘http://example.com/script.php’);

と外部のURLからデータを読み取りローカルのスクリプトとして実行する機能があります。以下のようなスクリプトが致命的であることは以前にも書きました。

require($_REQUEST[‘type’].’.php’);

allow_url_fopen設定で読み取りの可否を変更できるようになっているのですが、ストリームのphp://inputは制限できないので、allow_url_fopenの設定に関わらずリモートスクリプトが実行できてしまう仕組みになっています。(「php://inputによりPHPスクリプトインジェクションが可能になる」とした方がより正しいですね）

最近、この不正なリモートスクリプトの読み取り・実行が行える脆弱性を調べている方がいるらしくCVEに何十ものリモートスクリプト実行脆弱性のエントリが作られています。見かけた事があるアプリケーション名にはmanbo、horde等があります。当たり前ですが利用中しているアプリのリリース情報はこまめに調べないと危ないです。

# しかし、こんなにたくさんリモートファイル実行
# に脆弱なアプリが在るとは….
# shopなんとかとか、cartなんとか、と明らか(?)に
# EC系のアプリにも問題が多く在るようです….

とは言っても

Successful exploitation requires that “register_globals” is enabled.

となっている物も多いようです。共有サーバなどではregister_globals=onのサイトもまだまだ多いでのしょう。スクリプトを公開する場合、

if (ini_get('register_globals')) {
  die('Turn off register_globals for security reasons');
} 

などを必ず入れておいた方が良いようです。

安全と思われていて実は危険なソフトウェア15種 – 宣伝のためのホワイトペーパー

ホワイトペーパーというものは基本的に宣伝の為に作成するものであって「危険なソフトオウェア15種」というホワイトペーパーも宣伝の為のホワイトペーパーでしょうね。PDFのダウンロードには登録が必要らしい（？）のでPDF自体は読んでいません。「危険なソフトがインストールされていないかチェックするにはこちらを見てね」といった旨の記述がPDFにはあるらしいです。

マーケティングではパブリシティーを有効活用するのは重要な事です。このPDFはマーケティング的には、少なくとも日本では、成功していると思います。自社製品の宣伝目的だったとしても有用な注意喚起も記載されているようなので「宣伝だからダメ」と言うことは無いと思います。

このPDFによると1位はFirefox 1.0.7だそうです。Firefoxは1.0系はメンテナンスされてませんよね。Google AnalyticsのログによればこのブログにFirefoxでアクセスしているユーザのうち約13%は修正済みの脆弱性があるFirefoxでアクセスしていると思われます。賛否両論あるようですが自分が使っているソフトウェアがメンテナンスされているか知っておく事は重要だと思います。多くのユーザは自分が使っているソフトウェアがメンテナンスされているものなのか、されていないものなのか気していないです。時にはこういった注意喚起も必要と思いますが、これらを目にするのは普通のユーザではなくコンピュータを生業とする人達がほとんどでしょうね…

アンチウィルスソフトは普通に使われるようになりましたが、インストールされているがメンテナンスされている物か、脆弱性を含まないかチェックするソフトウェアがあると非常に便利だと思います。アンチウィルスソフトのメーカにがんばってもらって追加機能として付けてほしいですね。ウィルスのシグニチャ更新に比べればかなり簡単(?)にデータベースの維持はできそうに思えます。

とろろで、このホワイトペーパーにMS製品が無いのは選択基準のせいらしいですが、IEが載っていないのは危険なことは周知の事実だからとか?IEが危険と書いても話題にならないからとか?（実際「IEが危険です」と書いても話題にならないでしょうね）しかし、ユーザ数なども含めて選択するなら最も危険なアプリはダントツでIEだと思います。

セキュリティ対策は全体的な整合性が重要ですから、バージョンが古くて危険なソフトウェアなってしまっているソフトがインストールされている場合に警告するアプリは必要ですね。何故今までメジャーになるような製品が無かったのでしょうね?

ところで自分で「よくあるバージョンが古くて危険ソフトウェアのトップ5リスト」を作るならこんな感じでしょうね。

– Webブラウザ
– Webブラウザのプラグイン（Flash、音声、映像再生のプラグイン）
– インスタントメッセンジャー（Skypeもこれに含む）
– メールクライアント
– PDFリーダ（Acrobat Readerだけでなく、Linux等で利用されているフリーPDFリーダにも脆弱性がある）

なんだかここに取り上げているホワイトペーパーと同じようなリストになりますね。

また別の文字エンコーディング問題

HTTPヘッダでASCIIを文字エンコーディングに設定していてもISO-8859として解釈してしまうブラウザ（Firefox、Operaなど）とASCIIとして解釈するブラウザ（IE）とが在るためIPSなどのフィルタをすり抜けられるかも知れない、という話。珍しくIEの方が標準に厳格(?)に対処しています。

リンク先のページをIE 6で表示すると7bit ACSIIでは無視されるべき8ビット目が無視され読める文字列が表示されますが、Firefox 1.5では8ビット目を無視せずISO-8859として解釈してしまい文字化けしているように表示されます。IEの動作の方が仕様的には正しいように思えますが、Firefox、Operaの動作の方が安全ですね。

どちらかと言うとWeb開発者が注意すべき問題ではなく、JavaScriptの脆弱性を利用した攻撃などエンドユーザ側で問題になる可能性がある問題です。しかし、<, >等がどうなるのかは書いてないですね。IE6ではHTMLの特殊文字も普通に8ビット目を無視して処理するのかな?文字エンコーディングの取り扱いが関連ではいろいろありすぎで本当に困ります…

このブログには書いていませんがBOM（バイトオーダーマーク）でフィルタをすり抜けられる問題もありました。文字エンコーディング関連の問題はまだ出尽くしたとは思えないのでこれからも色々出てくるのでしょうね。

プログラム等、内部の文字エンコーディングは決めておくべき

あるMLでプログラム内部の文字エンコーディングは決めない事にしている、と言う意見を目にしました。プログラムを利用するシステムにより複数の文字エンコーディングがあるのでプログラム内部の文字エンコーディングを指定しない方が便利であることが理由だそうです。このような方針でも安全なプログラムは書けますが、セキュリティ上お勧めできない設計方針と思います。

2000年2月に公開されたCERTのXSS脆弱性問題の中でダイナミックページの文字エンコーディングは必ず指定する、と言う対策が書かれていますが、これと同様の理由でセキュリティ上の問題になってしまう場合があります。XSS問題としては文字エンコーディングを指定しない場合、ブラウザが文字エンコーディングを自動的に検出して表示する事になります。ブラウザが文字エンコーディングを自動検出すると、検出した文字エンコーディングによってはXSSが可能になる場合があります。

確か、昨年くらいに「文字化けしたページの文字エンコーディングを変えるとXSSが可能になる」と言うことでページの文字エンコーディングを変えると意図しないJavaScriptが実行される危険性が指摘されていました。こちらは文字エンコーディングの自動認識ではなく、ユーザが明示的に文字エンコーディングを切り替える事により発生する問題ですが、文字エンコーディングの妥当性を確認していれば防げる問題の一つです。

プログラム等の文字エンコーディングを指定しない場合、複数の文字エンコーディングを含むおかしな文字列を作ってしまうリスクがかなり高くなります。おかしな文字列がプログラム内部にもありえる事を前提にコードを書くとなると、必要以上に文字エンコーディングの妥当性をチェックしないと、コードの安全性を担保できなくなります。

同様にデータベースの場合にも文字エンコーディングを指定せずに複数の文字エンコーディングを含むデータを保存している場合があります。このような運用も文字エンコーディングに関連する脆弱性を発生させやすくなる原因になります。

互換性がある文字エンコーディングでも表現できる文字が異なるので困る場合があります。例えば、UTF-8とUTF-16ではUTF-8で表現できる文字はUTF-16よりかなり多いです。（注：実際にはUTF-16でも確か200万ほどのコードポイントを表現できるので、現状で困ることはほとんどないです。実際にはSJISを使っていて困る、などの場合が多いと思います。）

セキュリティ的にはシステム内部で利用する文字エンコーディングを指定しない場合と指定する場合を比べると、文字エンコーディングが指定されている方がはるかにコードが分かりやすく安全性も高くなると思います。プログラム等、内部の文字エンコーディングは指定できるシステムの場合、必ず文字エンコーディングは決定しておくべきと考えています。システムによっては内部で使用する文字エンコーディングは決め打ちでUnicodeを採用しています。

PHPはプログラム内部の文字エンコーディングを指定できます。デフォルトはISO-8859-1になっていてHTTP入力、スクリプトの文字エンコーディングを内部エンコーディングに自動的に変換する場合に利用されます。PHP6に備える意味からもUTF-8を内部エンコーディングに設定するのが良いかと思います。

French Microsoft Web site hacked

The attackers were likely able to penetrate the server running the Web site due to faulty configuration, Microsoft said in a statement Monday.

設定ミスだそうです。いわゆるページの改ざんだったようです。

http://experts.microsoft.fr/default.aspx

が

http://www.zone-h.org/index2.php?option=com_mirrorwrp&Itemid=44&id=4181592

の様な画面に改ざんされていたそうです。
トップページを改ざんされていたのですね。これは痛い…

Excel 0 Day攻撃のFAQ

メモ。Excel 0 Day攻撃のFAQ。

6/14にポストされ、6/16にマイクロソフトも脆弱性を確認とあります。XP上のExcel 2003/2002では確認されているそうです。Excel 2000は幾つかのベンダが影響あり、としているそうです。

最近MS Officeアプリの0 Dayが流行っているので注意が必要と思います。次はOOoとか?

PayPalのIDが盗まれているらしい

Netcraftによると、PayPalのIDが盗まれているらしい。

Webサイトの開発者にはセキュリティ対策としてHTTPSだけでは意味が無いことは100も承知だと思いますが、普通のユーザは「HTTPS＝安全」と刷り込まれていると思います。HTTPSを使っていてもXSSに脆弱だと意味が無い良い例になりそうです…

HTTPSなのに接続先サイトを偽証できる理由は簡単です。XSSに脆弱であるため、ページの中身をJavaScriptで書き換えて別のサイトのユーザ名とパスワードを送信できてしまっているようです。当たり前の事なのですが一般ユーザはこのようなことができる事を知らないので、ブラウザの接続先とSSL/TLSの証明書が正しければ「目的のサイトにアクセスしている」と思います。今回の本当のサイトに不正なページが表示され別サイトに誘導されるケースでは用心深いWeb開発者でも普通にだまされる可能性が高いと思います。
# アクセス先のURLがおかしい、と気が付く可能性も高いですが。

WebアプリからXSSが無くなる日があるとしても当分来ないでしょうね…