総務省がスマホプライバシー基準を公開
総務省は、スマートフォンアプリが順守すべきプライバシー保護の基準などを示した提言「スマートフォン プライバシー イニシアティブ」を公開する。提言案を2012年6月29日に公表し、7月20日までの意見募集を経て正式公開へ進める。「企業がスマホのプライバシー保護へ自主的に取り組む上で参考になる基準ととらえてほしい」（総務省）。 提言を見たセキュリティ専門家は「これまでの指針とは異なり、基準が極めて詳細かつ具体的」と口をそろえる（図）。消費者向けにアプリを提供している企業は、アプリの仕様やプライバシーポリシーなどを見直す必要が出てきそうだ。 これまで総務省は、スマートフォンを含むITサービスのプライバシー保護について二つの指針を公開していた。一つは、個人情報保護法などに基づいて事業者が順守すべき基本事項を定めたガイドライン。もう一つは、ガイドラインほどの拘束力はないものの、プライバシー情報を扱う
なぜb-casは失敗してインターネットはうまくいくのか？ - アンカテ
前のエントリで書いたように、b-casは用途を広げた時に前提条件が変わってしまったために、小さな「あってはならないこと」が起きただけで、手当ての方法が無くなってしまいました。 では、これと同じような見方で、インターネットそのものに「あってはならないこと」が起きた時どうなるか、について書いてみたいと思います。「インターネットそのもの」と言っても、一般の人が目にする「インターネット」の中でセキュリティをしっかり守らなければいけないのは、オンラインショッピングの時に使われる「SSL」という通信方式です。 アドレスが「https://」で始まるサイトにアクセスすると、そのアドレスの横に鍵の形の「安心マーク」が表示されます。オンラインショッピングで決済の画面やクレジットカード番号を入れる画面では必ずそうなっていると思いますが、これが今「SSL」を使っているよ、「SSL」がうまく動いているよというお知
『UDIDとUUID』
たまには技術的な話を。 服LIVEもver3.0での新機能の一つでは、入力時のデータ（個人の不快指数と実際の天気情報から計算された不快指数）を利用したものがあり、それを分析したりしたいので、個人を特定するためのIDを利用しなければいけなくなりました。 そこでまず候補として上がったのが UDID: Unique Device Identifier 簡単に言えば、端末情報。その携帯それぞれが持ってる固有のIDですね。 iPhoneに関しては以下の2行書けば取得できる UIDevice *device = [UIDevice currentDevice]; NSString *udid = [device uniqueIdentifier]; しかし、このUDIDはセキュリティのことを考えたら、まず使ってはいけないID。 みんなが普通に使ってれば何も危険なことはないのだが、一人でも危険な人がいれ
固有IDのシンプル・シナリオ
結城浩 RFIDなどの、固有IDの問題を考えるためのシンプル・シナリオを提示します。 シンプルなシナリオと具体例を通して、固有IDの注意点がどこにあるかを明確にしましょう。 目次 はじめに このページについて このページの構成 わたしについて 「固有IDのシンプル・シナリオ」 時刻(A): 場所(A)にて 時刻(B): 場所(B)にて ボブが知りえたこと シンプル・シナリオ適用例 適用例1: メンバーズカード 適用例2: IDの自動読み取り 適用例3: 読取機を持ち歩く人 適用例4: ダイヤの密輸 適用例5: 徘徊老人の命を救う 適用例6: 遊園地の迷子探し 適用例7: 携帯電話 固有IDに関連するQ＆A 固有IDのシンプル・シナリオで、何を言いたいのか？ メンバーズカードの例は問題なのか IDには個人情報が盛り込めないのではないか？ 暗号化すれば大丈夫？ 強固なセキュリティでデータベース
構築済みの Rails 2.x 系アプリに脆弱性パッチを適用する - akishin999の日記
Rails 2系すべてのブランチに脆弱性、Ruby 1.9ユーザはアップグレード注意 http://journal.mycom.co.jp/news/2009/09/07/048/index.html 先日のこの脆弱性のパッチを適用しました。 Windows だと以下の方法でパッチをあてる事ができます。 まずは Git をインストール。 今回は Windows なので msysgit を使用しました。 msysgit - Project Hosting on Google Code http://code.google.com/p/msysgit/ 次に以下の URL からパッチをダウンロードし、RAILS_ROOT の一つ上のディレクトリに保存します。 使用している Rails のバージョンに一致するものをダウンロードして下さい。 Riding Rails: XSS Vulnerabil
iモードブラウザ2.0の死角
docomo夏モデルN-06Aが不具合で発売中止になったり、アップデートがもう配信されつつあったりとなにかとdocomoの周りが騒々しいですが、2chでiモードブラウザ2.0のちょっと怖い話を見かけました。考えすぎとの声もあったようですが、個人的にはなるほどと思ったので紹介させていただきます。 iモードブラウザ2.0の特徴として、Referer（サイトの遷移元をサーバーに通知する）とCookie（個別の情報を端末側に保持する。セッション管理によく使われる）に対応したというのがありますが、今までのiモードサイトはこれらがない状態を想定して、セッションを開始する際に、本来Cookieによって保持されるセッションIDをURLの一部に埋め込む処理を行います。 例を挙げると、ログイン後のURLが http://hogehoge.com?jsessionid=zxealkwq0123 のようになり、「
産総研 RCIS: Fail-Safe C: 安全なC言語コンパイラ
Fail-Safe C とは Fail-Safe C は、完全な ANSI-C に対するメモリの安全性を保証する実装です。Fail-Safe C は、完全な ANSI-C 規格への準拠 (キャストや共用体を含む) を実現しながら、実行状態の破壊や乗っ取りに繋がる全ての危険な操作を検出し防止します。また、Fail-Safe C は、様々な「dirty trick」――必ずしも ANSI-C で厳密な意味では認められないが、広く一般のプログラマが利用している様々な記述手法――を、安全性を壊さない範囲でサポートしています。 Fail-Safe C では、コンパイル時や実行時の様々な最適化手法を組み合わせることで、実行時検査のオーバーヘッドの削減を行っています。このコンパイラを用いることでプログラマは、既存のプログラムを大幅に書き換えたり別の言語に移植したりすることなく、そのままプログラムを安全に
「ウェブサイト運営者のための脆弱性対応ガイド」などを公開：IPA 独立行政法人 情報処理推進機構
独立行政法人 情報処理推進機構（略称：IPA、理事長：藤原武平太）は、ソフトウェア製品やウェブサイトのセキュリティ対策などを推進するため、「ウェブサイト運営者のための脆弱性対応ガイド」を含む報告書をとりまとめ、2008年2月28日（木）より、IPAのウェブサイトで公開しました。 本ガイドは、「情報システム等の脆弱性情報の取扱いに関する研究会」（座長：土居範久 中央大学教授）において、昨年7月から行われた検討の成果です。 IPAでは、IPAから脆弱性に関して通知を行ったウェブサイト運営者や、情報システムの構築事業者、セキュリティに関する有識者など16組織に対して、昨年9月から本年1月までにヒアリングを行い、ウェブサイトの脆弱性対策を促進する上での課題を抽出しました。 このヒアリングにおいて、一部のウェブサイト運営者は情報システムの脆弱性対策について、ウイルス・不正アクセス対策などの他の情報セ
利用率7割のWEPは「1分」で破られる：ITpro
職場，自宅を問わず根付きつつある無線LAN。ただ，そのセキュリティに関しては，ユーザーの意識は意外に高くない。今回では，最も広くユーザーに利用されている無線LANの暗号化技術がどの程度弱いものかを確認しつつ，より安全な無線LANの使い方を改めて解説しよう。 IEEE 802.11a/b/gの無線LANには3種類のセキュリティ規格がある。WEP（wired equivalent privacy），WPA（Wi-Fi protected access），WPA2である。データを暗号化することで盗聴から保護し，有線メディアと同等のセキュリティを確保することが目的である。 ただ，2007年末に都内某所で調べたところ，受信できる無線LANの電波のうち，暗号化されていないものが16%，WEPでの暗号化が69%存在し，いまだにWEPが広く使われていることを再認識することになった。WPA/WPA2という最
思想の数だけセキュアOSは生まれる－ ＠IT
第1回 思想の数だけセキュアOSは生まれる 才所 秀明 Linuxコンソーシアム 理事 兼 セキュリティ部会リーダー 2007/6/1 なぜセキュリティを確保するためのOSが必要とされたのでしょうか。そしてセキュリティを高めるということが唯一のゴールであるにもかかわらず、いくつもの種類のセキュアOSが生まれたのでしょうか。本連載ではその答えを探るべく、セキュアOSを支える人たちの「思想」に注目します（編集部） ＠ITを含め、多くのメディアでセキュアOSが紹介されています。恐らく、SELinuxやLIDS、TOMOYO Linuxなどの紹介記事をご覧になった方も多いでしょう。 セキュアOSといってもさまざまなものがあります。筆者がリーダーを務めるLinuxコンソーシアム セキュリティ部会Wikiでは、数々のセキュアOSを紹介し、セキュアOSを選択するための評価項目を公開しています。これは、実
Webアプリケーションセキュリティフォーラム - Journal InTime(2007-07-05)
_ Webアプリケーションセキュリティフォーラム というわけで、発表して来た。 スライド(PDF) スライド原稿(RD) 自分の発表はともかく興味深い話を色々聞けてよかった。 とくに奥さんと高木先生のバトルが面白かった。 追記: リクエストがあったのでバトルの内容について少し。 (曖昧な記憶に基づく再現で言い回しは違うと思うし、内容にも私の勘違いがあるかもしれません。念のため) 高木先生 Greasemonkeyの説明の部分がよく聞こえなかったんですが。 奥さん (内容を説明) 高木先生 ええと、「クッキーが漏洩する程度なので問題ない」と聞こえたような気がしたんですが。 私の心の声 (最初から聞こえてたんじゃ…) 奥さん ローカルファイルにアクセスできたり、任意のコマンドを実行されたりするのに比べれば、ということですね。 高木先生 いや、それは違うと思うんですよ。銀行サイトのクッキーが漏洩
すべてはここから始まった〜SHA-1の脆弱化 ― ＠IT
米国は、現在利用されているすべての米国政府標準の暗号技術を2010年までにより安全な暗号技術へ交代させていく方針を明確に打ち出している。現在、世界中で使われているデファクトスタンダードの暗号技術は、そのほとんどすべてが米国政府標準の暗号技術に準じているため影響は極めて大きい。2010年に向けて現在使われている暗号技術はどのように変わっていくのだろうか（編集部） 2005年2月15日、世界的な暗号の権威であるBruce Schneier氏のBlog「Schneier on Security」で公表された「SHA-1 Broken」という情報は、驚きをもって世界中を駆け回った。現在、ハッシュ関数のデファクトスタンダードとして最も広く利用されているSHA-1に対して、中国・山東大学のXiaoyun Wang氏とHongbo Yu氏、セキュリティコンサルタントのYiqun Lisa Yin氏のチー
OWASP The Open Web Application Security Project
The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
なぜCSSXSSに抜本的に対策をとることが難しいか - いしなお! (2006-03-31)
_ なぜCSSXSSに抜本的に対策をとることが難しいか CSSXSSの説明について、その脅威を過剰に表現している部分がありました。その部分について加筆訂正しています。 @ 2006/4/3 tociyukiさんによる「[web]MSIE の CSSXSS 脆弱性とは何か」および「[web]開発者サイドでの CSSXSS 脆弱性対策」には、より正確なCSSXSS脆弱性の内容およびそれに対するサーバーサイド開発者で可能な対策について紹介されていますので、是非そちらもご覧ください。 @ 2006/4/4 今までも何度かこの辺の話はあまり具体的ではなく書いてきたけど、そろそろCSSXSSを悪用したい人には十分情報が行き渡っただろうし、具体的な話を書いてもこれ以上危険が増すということはないだろうから、ちょっと具体的に書いてみる。 ちなみに私自身は、CSSXSSの攻撃コードなどを実際に試したりといった
えび日記: CSRFの説明に追記 - こめんと (2006-03-30)
■ [Security] えび日記: CSRFの説明に追記 (4/2、この項に別記事で追記。) ええと、この議論はずっと続いていますね。こういう時間かかる話はできれば年度明けてからやろうよ（笑）。 ※ちなみに「CSSXSS」と呼ばれている問題の本質は「クロスドメインで任意の HTML の内容が読み取れてしまう」という点です。これは XSS とはあまり関係ありませんし、ある意味 XSS よりも危険です。その呼称は誤解を招くと個人的には思っています。 (「えび日記」より引用) この脆弱性の存在を根拠に「いわゆる高木方式は良くない、安全な他の方式にすべきである」という議論がよくあります。 いつも反論してるのですが、割と議論が噛み合わないのは、ひょっとしたら僕が「いや、高木方式で安全なんだ」と 主張しているように思われているのかなぁ、とふと感じました。 実はそうじゃないんですよね。僕の主張は、「い
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.
http://rails.office.drecom.jp/takiuchi/archive/83
ぼくはまちちゃん！(Hatena) - 日記を自動的に書いてくれる日記
