高木浩光＠自宅の日記 - ID番号は秘密ではない。秘密でないが隠すのが望ましい。なぜか。
■ ID番号は秘密ではない。秘密でないが隠すのが望ましい。なぜか。 俺、実は今日が誕生日なんだ……。 僕らはいったいいつから誕生日を隠さなくちゃいけなくなったんだろう。はてなにもmixiにもGREE*1にもニセの生年月日で登録した*2自分がいる。Facebookの友達にも生年月日を明かさない設定にしている。プライバシーやセキュリティを啓発する立場の者が生年月日を明かすだなんて、匿名主義者達の嘲笑の的にされかねない。そして気付いてみれば、誕生日を祝ってくれるのは、両親とほんの数人の身近な友人だけになっていた。 先月、スマホアプリのプライバシー騒動の件で立て続けてにいくつもの取材を受けた*3が、決まって聞かれるのは、「利用者が気をつけるべきことは何でしょうか」という問いであった。 これに対して私が答えたのはこうだ。「利用者が何か気をつけなくてはならないようではいけない」と。つまり、事業者が解決
もっとも危ないプログラミングエラー25、+16 | エンタープライズ | マイコミジャーナル
CWE is a Software Assurance strategic initiative sponsored by the National Cyber Security Division of the U.S. Department of Homeland Security. CWE - 2010 CWE/SANS Top 25 Most Dangerous Programming Errorsにおいて脆弱性の原因となる危険なプログラミングエラー25が発表された。開発者にセキュリティ問題の原因となるプログラミングに関する注意を促し、実際にソフトウェアが動作する前の段階で問題を発見し対処できるようにすることを目指したもの。2009年に発表されたリストの更新版にあたり、内容の多くが更新されている。2009年版を使っていた場合には、今回発表された2010年版を再度検討する価値がある。
徳丸本のあれこれを実践してみて気付いたこと | 水無月ばけらのえび日記
更新: 2011年7月9日23時0分頃 とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。 基本的には徳丸本 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。 ※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。 ストレッチ回数をどう決めるのか徳丸本327ページにあるコード例を参考にして実装。アプリケーションごと
実は厄介、ケータイWebのセッション管理
実は厄介、ケータイWebのセッション管理：再考・ケータイWebのセキュリティ（3）（1/3 ページ） “特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 「Cookieを使えない端末」でセッションを管理する方法は？ 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション（ケータイWeb）のセッション管理は、かんたんログインよりも対策が難しく、厄介な問
Webアプリケーション作った後のチェック表
愛宕山太郎坊 アニメーション制作進行支援ソフト 愛宕山太郎坊 ログイン 会社id ユーザー名 パスワード ユーザー名またはパスワードが正しくありません。 閉じる ログイン
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
evernoteのテキストをevernote社の管理者にも見えないように暗号化する - ockeghem's blog
このエントリでは、evernoteクライアントを使って、evernote社にも復号できない状態でテキストを暗号化する方法について紹介します。 昨日、EvernoteのXSS問題に関連して、「Evernoteの開発者も徳丸本読んでいたらよかったのにね」などとつぶやいていたら、「EvernoteのCEOが徳丸さんに会いたがっている」という連絡をもらいました。こういうのは異例のことでちょっと悩みましたが、行くっきゃないだろうということで、Evernote社の日本法人でmalaさんと一緒にCEOにお会いしました。 XSSやポリシーについては非常に誠実な対応をお約束いただいたのでよいミーティングだったと思います。僕が指摘した脆弱性についても、当日の夜のうちに直っていたようです。米国時間では深夜から早朝という時間帯で、迅速な対応だったと思いますが、本題はこれからです。 その場で、malaさんが「Eve
高木浩光＠自宅の日記 - 今こそケータイID問題の解決に向けて
■ 今こそケータイID問題の解決に向けて 目次 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 Web開発技術者向けの講演でお話ししたこと 研究者向けの講演、消費者団体向けの講演でお話ししたこと 総務省がパブリックコメント募集中 ソフトバンクモバイル製のiPhoneアプリがUDIDを認証に使用していた件 6月初めのこと、ソフトバンクモバイルが「電波チェッカー」というiPhoneアプリを直々に開発して、iTunesストアで配布を始めたというニュースがあったのだが、それを伝えるITmediaの記事で、「取得された電波状況情報はiPhoneのUDIDとともにソフトバンクモバイルに報告される」と書かれているのが気になった。*1 「電波チェッカー」で検索して世間の反応を探ったところ、ソフトバンクモバイル社のCTO（最高技術責任者）の方が、Twitterで直々に市民と対話な
【レポート】"かんたんログイン"のセキュリティ問題とは何なのか? - WASForum 2010 (2) 「かんたんログイン」の代替案 | ネット | マイコミジャーナル
かんたんログインがはらむプライバシー問題 高木浩光氏は、これまで自身のブログなどでかんたんログインに関する問題を報告している。今回はイー・モバイルの携帯WebであるEMnetを使ってインターネットに接続した結果を話した。EMnetのプロキシ経由で固有IDを書き換えて他社キャリアのIDを送信すると、IPアドレス制限はクリアでき、プロキシサーバでの書き換えも行われなかったという。 固有IDを使ったログイン認証の問題は、PCからアクセスできるとなりすましが可能になる点 EMnetのプロキシは、X-EM-UID:のヘッダで固有IDを付与する仕組みで、あらかじめUIDがあった場合、それを削除して正しいIDに書き換えて送信するが、他社のヘッダがあったとしても、それは書き換えない。他社の固有IDを削除しないこと自体は問題のある動作ではない、と高木氏。固有IDの送信に関する仕様が各社で統一されておらず、キ
高木浩光＠自宅の日記 - ユニークIDがあれば認証ができるという幻想
■ ユニークIDがあれば認証ができるという幻想 2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。 各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない（不正アクセス禁止法違反になる）ので、自分用のアカウントを作成して（会員登録して）、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は
WEBプログラマー必見！WEB脆弱性基礎知識最速マスター - 燈明日記
以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。 WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。 また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。 WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。 そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。 今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。 このまとめがWEBアプリケーション開発の参考になれば幸いです。 インジェクション クロスサイト・スクリプティング セッション・ハイジャック アクセス制御や認可制御の欠落 ディレクトリ・トラバーサル(Directory Traversal) CSRF（
セキュリティ過敏症 - ぼくはまちちゃん！(Hatena)
初心者はPHPで脆弱なウェブアプリをどんどん量産すべし ↑のブックマーク うん。増田くんはいつもいいこと書くね！ ブックマークの方には 危険だとか迷惑だとか踏み台だとか色々かいてあるけれど(というか踏み台ってなんだろ？) そんなに大切な個人情報をたくさん扱ってるサイトなんてどれだけあるかな。 みんなそういうサービスつくってるの？ なんかすごいね。 ぼくの使っている範囲だと、(提供側が気をつけていないと) 本当にまずいのは銀行と証券とカード会社のような、お金のからむサービスくらいだよ。 もちろん、他にメール内容だとか、購読しているフィードだとか、知られたくない個人情報なんてのは、人によってたくさんあるよね。 だけど、例えばぼくがメールサービス作りましたなんて言ったら誰か使う？ それか無名の団体だったらどうかな。それで大切なメールやりとりしちゃうの？ そう。そもそも、利用者もそれほどバカじゃな
CSRFの評価とCVSS現状値 | 水無月ばけらのえび日記
公開: 2009年12月19日14時10分頃 Amebaスタッフブログに「Amebaのセキュリティ対策について (ameblo.jp)」という文章が出ていますね。 弊社では新規サービスの開発時はリリース前に、既存サービスは定期的に、外部セキュリティ監査会社による調査を必ず実施しております。 調査報告は深刻度別に分類され、これまでユーザーの皆様のデータ漏洩や破壊につながる可能性がある部分については即時の対応を、それ以外の部分については一定期間内での対応実施を徹底して参りました。 現在、昨今の事情を鑑み、影響の大きな部分については優先度を最上級にし、緊急対応を行っております。 はっきりとは書かれていませんが、AmebaなうのCSRFの問題の話であるように思えます。たぶんこういうことですね。 セキュリティ監査会社による調査を実施している。報告された脆弱性は深刻度によって分類し、即時対応するもの、
CSRF対策は基本? | 水無月ばけらのえび日記
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや
知らなかったらNGなWEBアプリケーション脆弱性一覧 : mwSoft blog
先日、AmebaなうがCSRFという非常にポピュラーな脆弱性を披露したかと思ったら、ここ数日はセブンネットショッピングでXSSの脆弱性と、ID推測による他ユーザの個人情報閲覧の問題が発生しているという噂が流れています。 ユーザの情報を預かっておきながら、基本的なセキュリティの対策もできていないというのは、銀行に例えるなら、お金を預けようとした時に「お金は預かります。ちゃんと保管します。でも警備はあまりしないので盗まれたらスイマセン」と言われるようなものだと思う。 警備に穴があったというのではなく、まともに警備してませんでした、というのはさすがにありえないことです。 そこで、野良WEBプログラマである私が知っている脆弱性を列挙してみた。 私はプログラマであってセキュリティの専門家ではないです。しかも今年の春辺りからずっと外向けのWEBプログラムは組んでません。 その人間が知っているものを並べ
スラッシュドット ジャパン | 正しいCSRF対策、してますか？
あるAnonymous Coward曰く、"最近WebアプリのCSRF脆弱性への対策が注目されていますが、30日に金床氏が「開発者のための正しいCSRF対策」という秀逸なテキストを発表してくれました。 Googleで「CSRF 対策」で検索すると高木浩光氏の「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」がトップに出てきますが、金床氏によると、この方法は誤った対策であり「CSSXSS脆弱性が知られている現在では、絶対に実施すべきでないもの」とのことです。この対策は、IPAの「情報セキュリティ白書2006年版」や「用語「CSRF」@鳩丸ぐろっさり (用語集)」ほか書籍などにも書かれており、金床氏は「記事の内容を訂正していただきたい」としています。スラドの開発者のみなさんはきちんと正しいCSRF対策をしていますか？"
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
x.com
パスワード保存の常識(?)
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
Togetter - まとめ IPAの「安全なウェブサイトの作り方 改訂第4版」におけるCSRF対策の「擬似乱数の生成」について高木先生に聞いてみた
