カテゴリーアーカイブ 情報セキュリティ

著者:杉浦

【PHP】ホモグラフ攻撃と踏み台にされないための対策

 ホモグラフ攻撃とは直訳で人間的図形攻撃です。具体的に何をするかというと、視覚的に似た別の文字を用いてユーザの想定と異なる動作を誘発させます。特に重要で代表的な例はURLにおける攻撃で次例です。

https://www.аррӏе.com/
https://www.apple.com/

 上の二つのURLは異なるURLです。上の側だけ英語小文字に似た文字でドメイン名を記述してあります。これでユーザを誤ったURLへ飛ばし、飛び先のページで実行されるコードに悪意あるコードを仕込むことによって本格的な攻撃をします。
 この攻撃はユーザの運用によって完璧に防ぐことは困難です。いちいち文字コードや言語情報をチェックしていたらとても耐えられない不便をこうむります。この点、ブラウザがいくらか対策してくれています。例えばGoogle Chromeはο(オミクロン)を使ったgoogle.comへのアクセスを次の様に止めてくれます。

 PHPはホモグラフ攻撃の対策(主に踏み台にされないため)としてホモグラフ攻撃用文字列を検出するためのクラスSpoofcheckerを持っています。これを使えば怪しげな投稿やメールアドレスの多くを弾けます。
PHP:Spoofchecker-マニュアル
 簡単な使い方は次です。

public function isSafe($value){
    $checker = new Spoofchecker();
    $checker->setRestrictionLevel(Spoofchecker::制限レベル);// PHPリファレンスに記述はない(!?)が実装されている
    $checker->setChecks(Spoofchecker::チェックルール);

    return !$checker->isSuspicious($value);// isSuspicious関数は疑わしい時にtrueを返す
}

 制限レベルはPHP:Spoofchecker-マニュアルの定義済み定数の内のASCIIからSINGLE_SCRIPT_RESTRICTIVEまで、チェックルールはSINGLE_SCRIPT_CONFUSABLE以下です。デフォルトレベルはHIGHLY_RESTRICTIVE、デフォルトルールはSINGLE_SCRIPTです。詳しい各ルールの説明ドキュメントはPHPリファレンス内に存在しません。
 雑に使ってもそれなりに役に立つのですが、せっかくなのでルールの詳細が知りたいです。C言語で構築されたPHPのSpoofcheckerの実装は次です。これを読めば多少わかります。
php-src/ext/intl/spoofchecker at 49a4e695845bf55e059e7f88e54b1111fe284223 · php/php-src
 このディレクトリの内部を読むとC言語のuspoof機能を使っていることがわかります。C言語のuspoof機能のリファレンスは次です。
ICU 64.2: uspoof.h File Reference
 両方を参照すると制限レベル、チェックルールの二段階設定であることがわかります。
 制限レベルはICU 64.2: uspoof.h File Reference#URestrictionLevelで説明されています。日本で使うサービスとしてはデフォルト制限レベルであるHIGHLY_RESTRICTIVEがふさわしいでしょう。HIGHLY_RESTRICTIVEは日本語セット、中国語セット、韓国語セットのいずれのセットの中に納まらない文字列を怪しい文字列として疑うレベルです。
 チェックルールはICU 64.2: uspoof.h File Reference#USpoofChecksで説明されています。制限レベルをそのまま適用するRESTRICTION_LEVELが扱いやすそうです。PHPのデフォルト設定はSINGLE_SCRIPTですが、SINGLE_SCRIPTは既に非推奨でRESTRICTION_LEVELに置き換えられます。
 リファレンスが不親切で実装まで調査しましたが単に次のように使えばよさそうです。

public function isSafe($value){
    $checker = new Spoofchecker();

    return !$checker->isSuspicious($value);// isSuspicious関数は疑わしい時にtrueを返す
}

ちなみに各制限、各ルールで最上部の例のapple.comが安全ならtrue,違うならfalseにする関数でテストしたところ次結果になりました。読みづらいのは申し訳ないですがコピペとか見ている画面のデザイン変更で対応していただきたいです。

SINGLE_SCRIPT_CONFUSABLE MIXED_SCRIPT_CONFUSABLE WHOLE_SCRIPT_CONFUSABLE ANY_CASE SINGLE_SCRIPT INVISIBLE CHAR_LIMIT
HIGHLY_RESTRICTIVE true true true true false true true
MODERATELY_RESTRICTIVE true true true true false true true
MINIMALLY_RESTRICTIVE true true true true true true true
UNRESTRICTIVE true true true true true true true
SINGLE_SCRIPT_RESTRICTIVE true true true true false true true
  • この記事いいね! (2)
著者:杉浦

【Vue】改行とv-htmlとXSS対策

 Vue.js上で文字列を展開したい時があります。例えばそれは誰かが投稿したコメントをコンポーネント上に表示する時です。こういった時コメントの改行が反映されていない場合、見栄えが悪くなります。改行を行う必要があります。
 HTML上の改行と言えばbrタグです。PHPにはnl2brという改行コードを改行タグに変換する組み込み関数があるぐらいです。
PHP: nl2br – Manual
 改行の実現でありがちで危険なアンチパターンはこのnl2br関数を用いたコメントをそのまま表示しようと考えるものです。Vue.jsにはv-htmlというディレクティブがあり、これを用いると普段かかっている安全装置のHTMLエスケープを外し、HTMLとしてパース、実行します。brタグとv-htmlを用いることで改行コードを改行タグに変換して表示できます。
 v-htmlはXSSをまあまあ容易に招く危険性を持ちます。まあまあ危険というのは単純な

<script>alert('XSS')</script>

ぐらいならVueの仕組み上実行されず済むからです。とはいえ

<EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED>

の様な多少の変化球(scriptタグをbase64形式でエンコード、埋め込んだコード中でデコードして実行)であっさり破られるのでやはり危険です。

XSS 脆弱性を容易に引き起こすので、ウェブサイトで動的に任意のHTMLを描画することは、非常に危険です。信頼できるコンテンツにだけ HTML 展開を利用してください。ユーザーから提供されたコンテンツに対しては決して使用してはいけません。

テンプレート構文 — Vue.js

 これの対策は実現したい機能に関しての実装を生のHTMLに頼るのでなく個々の別手法を用いるのが一番でしょう。
 例えば改行に関してはCSSのwhite-space実現できます。white-spaceは要素内のホワイトスペースをどう扱うか決定するスタイルであり、ホワイトスペースの一種(少なくとも正規表現の\sグループでまとめられる)である改行文字の制御もこれでできます
white-space – CSS: カスケーディングスタイルシート | MDN
 上記リンクから引用した次の表の’改行を残す’スタイルを用いれば
と生のHTML実行を用いるまでもありません。

  改行 空白とタブ文字 テキストの折り返し 行末の空白
normal まとめる まとめる 折り返す 除去
nowrap まとめる まとめる 折り返さない 除去
pre 残す 残す 折り返さない 残す
pre-wrap 残す 残す 折り返す ぶら下げ
pre-line 残す まとめる 折り返す 除去
break-spaces 残す まとめる 折り返す 折り返す
  • この記事いいね! (0)
著者:ym

FirefoxでサードパーティCookieブロック

Firefox の新しいバージョン 67.0.2 付近から、表示しているページ URL 以外の場所のコンテンツから Cookie を書き込まれる場合に、拒否される様になりました。

URL欄に、盾マークが表示されている場合はブロックされています。

実際にブロック状態にあるトラッキングを見てみると。

すべてブロック中ですね。クッキーのスコープを同じドメイン名内で書き込んでいれば、サブドメイン名は大丈夫っぽいですが、別ドメイン名はことごとくブロックされてますね。

サービス提供側は大変ですが、インタレストマッチできなくなって嬉しい限り。

  • この記事いいね! (0)
takahashi 著者:takahashi

ついにHUAWEIがGoogleにAndroid関連のサポート停止を言い渡される

今朝、衝撃のニュースが飛び込んできました。

Google、Huawei端末へのサービス提供を一部停止 既存端末には影響なし – ITMedia

アメリカでHuaweiの締め出しが決まってから様々な動きがありましたが、とうとう今後発売されるHuawei製端末へのGoogleによるAndroid向けの基本サービス群(Google Playや開発者サービス、GmailなどのGoogle謹製サービス)の提供が停止されることになったようです。

よくよく考えてみれば、Googleはアメリカに本社のある企業なのでこういった規制もあり得る話ではあったのですが、プラットフォームの提供元による名指しでの提供停止というのはなかなか聞いたことがなかったので、とても驚きました。

ちなみにMicrosoftもアメリカに本社を置く企業ですが、万が一Microsoftもこの流れに追従することになった場合、Huaweiに対するWindows OSの提供が停止することも考えられるため、もしそうなった場合は事実上Huaweiが自社製のPCを製造できなくなることになります。(Linuxディストリや独自のOSを積むのであれば別ですが…)

もっともHuaweiは”自給自足”をして対抗するとのことで、今後どのような対策を打ってくるのかは非常に興味深いです。

Google公式サービスへのアクセスがブロックされたとはいえ、Android自体はオープンソースのOSであり、今回の規制に影響されることなく引き続きソースの入手は可能なので、Amazon KindleのようにAndroidベースの独自のエコシステムを構築する可能性も十分考えられます。

とりあえず、現在販売されている端末までは今まで通りGoogleの公式サービスを受けることができるようなので、既にHuawei製スマホを購入したユーザーは、心配する必要はなさそうです。

  • この記事いいね! (0)
著者:ym

ECサイトの障害

某ECサイトでシステム障害が発生している最中の様です。

私たちのようにサーバの運用保守を行う技術側として、身につまされる思いです。弊社のサーバサービスも、更に安定稼働、トラブルが無い様にしなければなりません。気を引き締めて取り組まなければ。

まずはできるところから、今一度、再確認しよう。

  • この記事いいね! (0)
著者:ym

暗号化 WPA3と Wi-Fi

結構まえに WEP や WPA2 に脆弱性があり漏れるとなり WPA3 が出ていましたが、とうとう WPA3 も破られた様です。

その頃から、では無いですが結構前から会社 PC は 有線 LAN を使ってケーブルで LAN を使っていて超快適です。

みなさんも LTE と 有線LAN を使いましょう!

今の LTE の 100 倍でしたっけ、早く 5G になるといいですね。そうすれば Wi-Fi の脆弱性に悩まされずにすみます。

  • この記事いいね! (1)
著者:ym

ラブライブと連休

ラブライブというドメイン名が乗っ取られてしまった様です。

「ラブライブ!」公式サイト、乗っ取られる

https://it.srad.jp/story/19/04/05/0819238/

ラブライブ自体はなんだかよくわかりませんが、JPドメイン名の乗っ取りは簡単にできてしまうので注意が必要です。

昔は、gTLD も同じく認証コードなどはなくて同じ状況だでしたが、gTLD などは認証コード (AUTH、ESP) がなければ移管申請を出すことはできません。しかし、JP ドメイン名については、欲しければ申請が行なえます。

移管申請を行った後、 10 日経過した時点で自動承認となります。JPRS 側もその点は考慮していて 1 日猶予をくれました。たった一日ですけどね。

  • この記事いいね! (1)
著者:ym

人間には聞こえない音コマンド

Ok Google や、Alexa に対して音声で命令をしていると思いますが、音に別のコマンドを潜ませることで、音声アシスタントが聞き取ってしまうらしいです。

人間には聞き取れない音を聞き取る音声アシスタント

カリフォルニア大学バークレー校のエキスパート(英語記事)は、別の原理を利用しました。他の音声の断片に音声コマンドを潜ませて、Mozillaの音声認識システムであるDeep Speechを欺くことにしたのです。人間の耳では、加工された音とオリジナルとの違いはほとんどわかりませんが、Deep Speechは隠しコマンドを認識できるのです。
調査チームのWebサイトでこれらの音を聞いてみてください(英語記事)。最初の例では、「Without the data set the article is useless(データセットがなければこの論説は役に立たない)」というフレーズに、「Okay Google, browse to evil.com.(OK、グーグル。evil.comを開いて)」という、Webサイトを開くためのコマンドが隠されています。2つ目の例では、バッハのチェロ組曲に、「Speech can be embedded in music(音声を音楽に埋め込みできる)」というフレーズが追加されています。

https://blog.kaspersky.co.jp/ultrasound-attacks/22339/

超音波だけでなく、他の音声の断片に音声コマンドを潜ませることもできる様です。

  • この記事いいね! (0)
著者:ym

SNIフィールドと遮断

https で暗号化通信をすることで、遮断を逃れられていたのですが、便利な SNI のおかげで逆に遮断できる状況になってしまった形。

韓国でSNIフィールドを使った特定サイトの接続遮断が始まる

https://it.srad.jp/story/19/02/13/0735240/

韓国でSNIフィールドを使った遮断が始まっている様です。

DNS over HTTPS は、SNI 部分とは関係が無いので、もっと前段階ですが、SNIフィールド遮断に対しては Encrypted SNI 。

  • この記事いいね! (0)
著者:ym

サイバーセキュリティの安全性ランキングで日本が首位

日本がサイバーセキュリティの安全性ランキングで首位、英比較サイトが算出

最も安全な国は日本で、以下、フランス、カナダ、デンマーク、米国が続く。最も危険な上位5カ国はアルジェリア、インドネシア、ベトナム、タンザニア、ウズベキスタンだった。

https://www.atmarkit.co.jp/ait/articles/1902/08/news062.html

算出の仕方が日本に良かったのだとは思いますが、結構ITに強い国が危険と判断されているところもあって、気になります。

  • この記事いいね! (0)