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

takahashi 著者:takahashi

Webサイトを公開する前に消しておくべきヘッダー情報

最近の有名どころのLinuxディストリビュージョンでは、インストールしてすぐに使用できるような状態でApacheやnginxなどのWebサーバーアプリケーションなどのパッケージを公開しています。

そのため、自分で動作のカスタマイズをしたい場合以外は、ほとんどパッケージをインストールして、ファイルを指定の場所に置くだけで、Webサーバーとして機能させることができます。

ところが、これらのパッケージに含まれるサーバーの設定では、デバッグなどでも利用できるように、少し緩めの設定になっている場合が多いです。

ネット上には公開していないテスト環境としてであれば問題はありませんが、本番環境であったりテスト環境であってもネット上に公開されている場合は、デフォルトのままで使用してしまうと危険な設定が含まれている場合があります。

たとえば、CentOS版のApacheパッケージのデフォルト設定では、HTTPヘッダに

“Server”
“X-Powered-By”

といった内容がつきます。

ServerヘッダにはWebサーバーの種類・バージョンが記載されます。

また、X-Powered-Byにはサーバー側でプログラムを使って処理を行った場合に、どの言語・バージョンを使用しているのか、といった情報が載ってきます。

インターネット上にサーバーを公開する際、使用中のソフトウェアのバージョン情報などがわかってしまうと、悪意ある利用者がどういった脆弱性を用いれば攻撃が可能となるかのヒントを与えてしまうことになり、自分のサーバーが攻撃を受ける危険性を高めてしまいます。

したがって、こういった内部の情報は、可能な限り公開しないようにした方がよいとされています。

これらのヘッダ情報は設定を変更するだけで簡単に非表示にすることができます。

Serverヘッダについては、Apacheでは、

/etc/httpd/conf/httpd.conf

内の

ServerTokens OS

などとなっている部分を

ServerTokens Prod

とするとどのバージョンのApacheを使用しているかを非表示にすることができます。

nginxの場合は”http”ディレクティブ内の”server_tokens”のオプションを”off”に書き換えることで同様の設定ができます。

http {
    ...省略...
    server_tokens off;
    ...省略...
}

また、PHPを使用していて、X-Powered-Byがヘッダに含まれている場合は、php.iniの

expose_php = On

expose_php = Off

に変更することで X-Powered-By の記述そのものを削除することができます。

実際に今動作させているサイトが、どのようなヘッダーを吐き出しているのかを確認することも大事です。

Chrome・Firefoxなどの主要ブラウザでは、F12キーを押すと開発者ツールが開きますが、その中の”Network”タブを確認すると、どんなヘッダが各コンテンツにくっついているのかを確認することができます。

Chromeの開発者ツールでexample.comを見たときのヘッダ

ネット上に公開する際は、どういった情報をサーバーが公開しているのかを調べておくのがおすすめです。

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

パスワードは全部ランダムで

最近またパスワードの使い回しによる被害のニュースが増えている気がします。

対策としては SMS やメール、ワンタイムトークン等、多要素認証も重要があげられていますが、今の被害状況を見る限り、 人間には覚えられない様に毎回パスワードをランダム発行し、クラウド上に残らない、紙やメモ、ファイル等で保管することでほぼ防げると思います。

もしパスワードを保管するクラウドサービスを使う場合は、そのサービスに対しては多要素認証は必須。最悪、パスワードを保管するサービスが漏洩したときの対策も重要。

皆さんも、頭で覚えられるパスワードは設定しないでください。ながければ良いということでは無いが16桁位の英数大小記号入なランダムパスワードがおすすめです。

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

首里城火災

首里城が焼けてしまいました。
首里城へは一度だけ近くへ見に行ったことがあります。中は入らなかったのですが、なんで入場しなかったかは覚えていません・・・・。

那覇・首里城で火災、正殿など7棟焼失 31日午後鎮火

https://www.nikkei.com/article/DGXMZO51617010R31C19A0CE0000/

まだ原因はわかっていませんが、工事の電源熱による火災なのでしょうか。

クラウド化やアウトソースであまり直に触ることは少なくなりましたが、24時間365日稼働するサーバやネットワーク機器を扱っているので、電源から発生する熱についてはかなり注意しています。ホコリもそうです。

自宅でも、ホットプレートや、ドライヤー、溶接機なども使うとケーブルが熱くなるのですぐわかると思います。

使用容量の大きそうな機器を接続したときは、電源ケーブル握って熱くないか、溶けてないか、確認必要ですね。

また乾燥する季節なので、改めて電源廻り、要確認です。

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

Cookieを規制する法案が浮上 Webサービスへの今後の影響が心配…

先日、気になるニュースを見かけました。

CookieはステートレスであるWebの仕組み上ユーザーを識別する数少ない手段となっています。

例えば、会員制サイトでアクセスしてきたユーザーがログイン済みなのか、まったく関係のない(会員ではない)部外者なのか、の判別にはCookieの存在が不可欠です。

Cookieがなければ、ログインを前提とした会員制サイトを作ることは事実上難しくなるでしょう。

正確にはCookieのURLにセッションIDを乗せることで、Cookieを使用しない状態の管理行うことはできますが、URLはCookieよりも漏れやすい情報(ユーザーがURLを意図的に保存しなくても、ブラウザの履歴に残ったり、リファラーという仕組みで分かってしまったりする)ため、URLを盗まれてしまうと第三者が正規のユーザーに成り代わって会員サイトを操作できてしまう”セッションハイジャック”が発生しやすくなってしまいます。

ただし、クッキーレス・セッションにはセキュリティ上の問題がある。というのも、クッキーレス・セッションを利用した場合、(当たり前の話であるが)セッションIDが一般ユーザーの目に直接さらされることになる。つまり、URLさえ分かってしまえば、第三者による「なりすまし」も可能であるということだ。
 ただし、このクッキーレス・セッションの脆弱性の問題は、クッキー経由でセッションIDの受け渡しを行った場合でもさほど事情は変わらない。ネットワークをモニタすることで、クッキーの内容などは簡単に盗聴できてしまうからだ。ただ、URLの方が「なりすまし」も「盗聴」も簡単であるという意味で、より危険であるといえる。しょせんは相対的なものといってしまえばそれまでだが、安全性がより重視される局面で、無用にクッキーレス・セッションを採用するべきではない

[ASP.NET]クッキーをサポートしないクライアントでセッション機能を利用するには? – @IT

もちろんURLによるクッキーレス・セッションもシステムによっては適用できる場合もありますが、セキュリティに気を使いたいサイトの場合は当然 Cookieという選択肢が存在しなければなりません。

Cookieという選択肢が取れなくなってしまった場合は、非常に大きな問題です。

そのような技術的な裏側を知ってか知らずかわかりませんが、昨今”個人情報保護”という観点だけを重視してしまい、Cookieを規制しようとする政治的な動きが出てきていますが、正直言って理解に苦しみます。

もっとも、現在多くのサイトで行われている”Cookieを使用することに同意を求める”だけであれば(めんどくさいですが)画面を追加するだけなので問題ありません。

しかし、Cookieの使い方そのものを規制するような動きが万が一出てきた場合、ITインフラそのものを崩壊に追い込んでしまうことも考えられます。

現状”Cookieを規制するようだ”という動きだけニュースになっていて、具体的にどのような規制が行われるのかを説明しているところはまだないようですが、いくらITに詳しくないとはいえ、”知らないから”という言い逃れは許されない問題です。

関係者の方には是非Webの技術やCookieをなぜ使用するのかをきちんと勉強していただいた上で議論していただきたいと思います。

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

BIND 脆弱性対応

最近、格安で購入できるバッタモンでも満足できる品質に追いついていて、非常に助かります。真似して技量をアップして、より良い製品を作る。原点に戻って腕を磨かなくては。

脆弱性が出たので更新しました。ついでに clamav も出ているので更新準備に入ります。

twitter で見かけましたが、ubound が設定楽なんだとか。bind でも DNSSEC とかしなければ、そう面倒なことは無いと思いますが、powerdns や ubound こういった対応が少なくなるのであれば、手を出してみたい。

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

UNIX系OSのsudoコマンドにsudoersファイルの制限を無視してroot権限でコマンドが実行できる脆弱性が発覚

最近のUNIX系のOSにおいて、直接rootユーザーとしてログインする代わりに、1コマンド単位でroot権限に昇格できるコマンドとしてsudoが用意されています。

現在では、rootユーザーとしてログインするよりも一般ユーザーでsudoを使用した方が安全といわれていますが、そんなsudoに先日、ちょっとマズい脆弱性が発覚しました。

Linuxの「sudo」コマンドにroot権限奪取の脆弱性。ユーザーID処理のバグで制限無効化 – engadget 日本版

sudoには特定のコマンドのみroot権限で実行可能とするような、各ユーザーに対するコマンド単位での制限を設定することができます。

例えば、設定ファイルやサービスの起動・停止はできるようにしたいが、サーバー自体の再起動・停止はさせないようにしたい…などどいった場合は、対象のユーザーに対してのみshutdownコマンドなどをroot権限で実行することを制限することができます。

ところが今回、sudoコマンドでrootユーザーではなく特定のユーザーとして実行すると、sudoersで指定された制限を無視して、すべてのコマンドをroot権限として実行できてしまう現象が発見されました。

sudo で UID に「-1」または「4294967295」を指定すると root 権限でコマンド実行出来る脆弱性 – らくがきちょう

詳細は上記のリンクを参照いただきたいのですが、一部のコマンドのみsudo経由で実行できるように許可されたユーザーにおいて、ユーザーidが”-1″、もしくは” 4294967295″のユーザーを指定した場合にsudo のバグで制限なくroot権限が発動できてしまう、というのが今回判明した現象です。

なお、もともとsudoを使用する権限が一切ないユーザーについては上記のユーザーidのユーザーとして実行しようとしてもはじかれる為、管理者でない一般ユーザーが管理者権限を行使できてしまう、といったことはないようです。

自分でも更新前のsudoで試してみましたが、昇格はできませんでした。

 sudo -u#-1 service nginx reload
[sudo] password for testuser: 
testuser is not in the sudoers file.  This incident will be reported.

基本的にsudoは完全な管理者として昇格する以外の使い方はあまりされていない印象なので、おそらく影響を受けたユーザーはさほど多くないかと思いますが、もしコマンド単位での制限をかけている場合は、早急にsudoのアップデートを適用すべきでしょう。

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

Windows7 の有償延長サポート

来年2020年1月14日で Windows7 のサポートが終了しますが、有料でサポートを購入する事もできる様な情報が出てきました。

米マイクロソフトはこの方針を転換。ボリュームライセンス契約を結んでいるかどうかにかかわらず、あらゆる企業がWindows 7の延長サポートを購入できるようにすると発表しました

今回の発表で新たにWindows 7 ProfessionalとWindows 7 EnterpriseのESUが、マイクロソフトのクラウドソリューションパートナー経由で12月1日より購入可能になります。
Windows 7 ESUはデバイスごとに販売され、1年ごとに料金が値上がりしていく予定。

https://www.publickey1.jp/blog/19/windows_72023.html

どうしても Windows7 を安全に使い続ける必要がある場合は、ボリュームライセンスでなくてもこの有償サポートを購入する事で維持ができそうです。

ただし年々料金が上がっていく仕組みらしい。

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

【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)