インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;
インフラエンジニアの方向けに、SSL/TLSとは何か、また証明書入手のポイント、HTTPS設定のポイントについて、最新の動向を踏まえて紹介します。また、最後の方で勉強会主催者のリクエストでおまけがあります(^^;
もはや恒例になっているような気もしますが、BIND9の脆弱性情報が出ましたね。各ディストリビューションではすでに修正済みパッケージが提供されていると思いますが、どうやって知るの?って聞かれたので、購読しているメーリングリストをまとめておくことにしました。RSSフィードでも良いんだけど、RSSフィード読み飛ばしがちなのでメーリングリストの方がおすすめです。 JPCERT/CCメーリングリスト https://www.jpcert.or.jp/announce.html (RSSフィードも提供) 毎週1回セキュリティ関連のトピックをまとめておくってくれる。 緊急性が高い場合は都度注意喚起が行われる。 貴重な日本語情報でしかも読みやすくまとまってて便利。 Ruby on Rails: Security Ruby on Railsのセキュリティ情報が流れてくる。 Railsを使っているなら入ってお
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング(XSS) HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
右の運転免許証の写真のように、一部の文字を読むことができないように(判別できないように)モザイク処理をして、(公開できない情報が一部含まれている)機密文章や個人情報が含まれた写真などを公開することがあります。今回はそんな「モザイクで隠された読めない文字」を復元し、解読する方法について考えてみることにします。 モザイク処理にも色々ありますが、今回対象にするのは「文字サイズより大きいモザイク」です。たとえば、実例を作ってみたのが、たとえば下のような画像です。こんな秘密メッセージ、モザイクが掛かっていて肝心な部分を読み取れない秘密文章の内容を、解き明かすことができるでしょうか? まず、一見して、このモザイク部分には全部で5文字が隠されているということが明らかです。そして、その前に書かれた「一番最初は」という部分を見ると、ヒラギノ ゴシックの(画面解像度上で)18ポイントの大きさで書かれている、と
av-comparatives On-Demand 2011年8月 ウイルス206,043個の性能調査 ※XP SP3上で実施 http://www.av-comparatives.org/images/stories/test/ondret/avc_od_aug2011.pdf 検出率 誤検出数 スキャン速度 ソフト名 ADVANCED+ ★★★ 99.7% 14個 10.1 GDATA 99.5% 11個 12.3 Avira Personal [無料] 99.3% *1個 *9.6 Panda Cloud [無料] 98.5% *6個 10.3 F-Secure 98.4% *8個 10.5 BitDefender 98.3% *1個 *9.9 Kaspersky 97.3% *3個 *9.8 ESET 97.3% 10個 16.4 avast! Free [無
■ スパイウェア「app.tv」に係るミログ社の大嘘 株式会社ミログが9月27日に提供開始した「AppLog」がスパイウェアまがいであるとして、朝日新聞10月5日朝刊に以下の記事が掲載された。 アプリ利用時間や回数丸わかり「アップログ」に批判, 朝日新聞2011年10月5日朝刊 AppLog: insidious spyware rolled out in Japan by Milog, Inc. *1, The Asahi Shimbun, 2011年10月5日 スマートフォンの利用者がどんなアプリ(ソフト)をいつ、何回使ったかを記録して好みを分析し、興味を引きそうな広告を配信する。そんなプログラムが現れ、インターネット上で批判を集めている。プログラムは電話帳など無関係に見えるアプリに組み込まれ、アプリ利用者への説明が十分ではないからだ。(略) 問題視されているのは、利用者に存在が見えに
@hamatzさんがapplog検出ツール[通報君Z]をリリース、あと、いろんな人が解析してくれた結果とか: はまっつさんが、applogやその、類似のモジュールが入ったアプリを検出するアプリ「通報君Z]作ってくださいました。ありがとうございました!同じような情報収集系アプリの人達を一網打尽にするためのブラックリスト形式アプリらしいです。 あのあと、色々な方々が解析していただきました。 app.tvなど、ごく一部の無料の電子書籍や動画アプリにミログ社製のapplog類似のモジュールが入っています。 これらのバージョンはapplogのような、[許諾]ダイアログ無しで、端末内から収集した情報を送信するワイルドな仕様です。(一応、利用規約で記述はある。) 端末情報どころか、インスコアプリ一覧まで抜いて送るようです。 クラス名が全く違うので今まで検出できてませんでした。 電子書籍部分のエンジンはセ
■ MacユーザはIPv6を切るかnet.inet6.ip6.use_tempaddr=1の設定を Mac OS Xの初期設定の危険性 私の周囲に物理的に近づくことのできる人は、私が使っているノート型コンピュータの無線LANインターフェイスのMACアドレス*1を知ることができる。たとえば、セミナー等で私が講演している会場に来れば、講演中に私が無線LANのスイッチを切り忘れていたなら、無線LANのパケットを傍受することで私のMACアドレスを知るだろう*2。それだけでは他の人のアドレスと混じって区別できないだろうが、別の場所で再び同じことをすれば、両方に存在したものが私のMACアドレスだ。 これはもう隠しようがないので、先に自ら暴露してしまおう。「00:1f:5b:d1:ec:bd」は私のMACアドレスだ(図1)。 これを暴露するのはリスクのある行為であり、お薦め出来ない。また、仮に他人のMA
IPv4 アドレスの枯渇が間近に迫ったというニュースが流れました。Mac OS X も Windows も IPv6 に対応していますので、いよいよ本格的に IPv6 への移行が進むのかもしれません。 Mac OS X の場合、デフォルトの設定では、IPv6 の構成が「自動」になっています。 システム環境設定 > ネットワーク > AirMac > 詳細... > TCP/IP システム環境設定 > ネットワーク > Ethernet > 詳細... > TCP/IP で確認できます。(画面のイメージをクリックすると拡大表示されます。) 特に問題がなさそうに見えるのですが、Mac OS X の場合、気をつけなければならないことがあります。フレッツ光を使っているところ等、IPv6 が使えるネットワークに繋がると、「IPv6 アドレス」が割り当てられるのですが、このアドレスの中に、マシン固
Rails 3.1 からパスワードの暗号化用のモジュールができたようです。ActiveModel::SecurePassword で定義されていて、ActiveRecord や Mondoid などの ActiveModel を利用しているモデルで使えるそうな。 User モデルに password_digest カラムが設定されている前提で class User < ActiveRecord::Base has_secure_password end とすると、下記のような効能が得られます。 attr_reader :password validates_confrmation_of :password validates_ppresence_of :password_digest password に何か代入すると自動で bcrypt-ruby でハッシュにされて password_d
■au IS03 CEATEC版レビュー 【11/10追記】IS03の最新レビューはこちら au IS03 更新ビルド2種 レビュー http://blog.isnext.net/issy/archives/482 CEATECで昨日発表されたauのAndroidスマートフォン「IS03」の展示機をじっくり触ってきたのでレビューしておこうと思います。auのIS03コーナーは比較的落ち着いた黒メインの装飾で、展示機もSHARPのコーナー合わせてざっと30台以上はあったため、余裕を持ったお試し環境になっていたと思います。説明員の方もあまり積極的に声をかけることなく、来場者にじっくりと見極めてもらう戦略をとっていたように感じました。 ■ハードウェア 手に持った感覚は厚みのある樹脂カバーのためか、割としっくり馴染む感じ。樹脂ケース安っぽいかと思ったけど、そんなこともなく交換が容易そうで好感触です。
先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い(テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え)ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り
昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文(プレインテキスト)ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう? まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか? それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか? それだと、@ を含む URL があった場合に
はい、Ruby 1.9.2がリリースされましたね。このバージョンではWEBrick にゼロデイ攻撃可能な脆弱性 - スラッシュドット・ジャパンで紹介されている脆弱性が僕が書いたパッチで修正されているわけなのですけど、そもそもなんで僕が修正しているのか、って顛末がわりと面白いので紹介します。 Apple、upstreamに報告してくれないまま脆弱性をCVEに届け出る upstreamに連絡が来ないまま脆弱性が公開される ruby-devにAppleが書いたと思われるパッチが貼られる(Appleでない人間によって) パッチのライセンスが不明なので取り込めない ライセンスを問い合わせるAppleの窓口が不明なので問い合わせもできない ruby-devを読んだ人はライセンス上安全なパッチを書けない 脆弱性だから話は非公開に進めたい yuguiさんがruby-devを読んでない僕に書かせることにする
bit.lyにログインしているとメールアドレスを抜かれる ※修正されたようで今は抜けなくなっています (2010/08/10 10:00) account name: - mail: - api key: - » このページをツイッターで紹介する » はてなブックマークでのコメント » ぼくはまちちゃん! » はまちや2(Blog) » はまちや2(twitter) Powered by BEARS SERVER PROJECT: ついったーとHamachiya2はまちや2のtumblr [hmcy]ドリームメーカー:簡単・無料・フリーのノベルゲームが作成できるWebサイトソーシャルゲーム速報簡単!節約!おいしい!お料理レシピのもぐもぐ予告.out - 予告ができる掲示板ぼく専用mxximixiシークレットバトンはまちやブックマークオナホールピンクローター私立恵比寿中学(エビ中)ファンクラ
■ 今こそケータイID問題の解決に向けて 目次 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 Web開発技術者向けの講演でお話ししたこと 研究者向けの講演、消費者団体向けの講演でお話ししたこと 総務省がパブリックコメント募集中 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 6月初めのこと、ソフトバンクモバイルが「電波チェッカー」というiPhoneアプリを直々に開発して、iTunesストアで配布を始めたというニュースがあったのだが、それを伝えるITmediaの記事で、「取得された電波状況情報はiPhoneのUDIDとともにソフトバンクモバイルに報告される」と書かれているのが気になった。*1 「電波チェッカー」で検索して世間の反応を探ったところ、ソフトバンクモバイル社のCTO(最高技術責任者)の方が、Twitterで直々に市民と対話な
Webアプリのセキュリティを検討する「Webアプリケーションセキュリティフォーラム(WASForum)」が5月22日、認証と認可に関するイベントを開催した。その中で携帯電話の「かんたんログイン」のセキュリティに関して講演が行われた。 WASFは、もともとPCの一般的なインターネットのセキュリティを対象にしていたが、昨今のスマートフォンの流行などで携帯電話からも通常のインターネットが頻繁に利用されるようになったことから、今回のような考察が行われたという。 かんたんログインに関して講演をしたのは、HASHコンサルティングの徳丸浩氏と、産業技術総合研究所(産総研)の高木浩光氏。 パンドラの箱を開いたキャリア 携帯電話のWebサイト(携帯Web)で一般的に利用される「かんたんログイン」は、iモード(NTTドコモ)やEZweb(au)、Yahoo!ケータイ(ソフトバンクモバイル)で利用されているログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く