ゼロ幅文字にエンコードした隠し情報で、文書をリークしたメンバーを特定 | 秋元@サイボウズラボ・プログラマー・ブログ
とある会員制掲示板からの文書の流出に困った運営者が、ユニコードの見えない文字「ゼロ幅文字(Zero-Width characters)」を使って流出させたユーザーを特定した、という話が出ていました。 数年前の話、Tom さんが所属していた競技ビデオゲームのチームでは、ログインが必要なプライベートの掲示板を使って連絡していました。その掲示板に書かれた秘密情報や戦術に関する重大アナウンスなどがしばしば掲示板外のウェブにコピペされ、チームにとって大きな問題となっていたそうです。 外部ユーザーの攻撃で中身が漏れたというよりは、メンバーの誰かがコピーしているのでは、と考えた Tom さんは、当時気になっていたユニコードのゼロ幅文字を使ったトリックを仕掛けたそうです。 ユーザーを特定する情報を、見えない文字に変換して埋め込む ログイン中のログインユーザーのユーザーIDを、一定のルールによってゼロ幅文字
OWASPのSQLインジェクション対策方針を読んで「おまえは俺か」と思った
つい最近まで、グローバル・スタンダードのセキュリティ施策ではバリデーションが極めて重視されている、いささか過剰ではないかと思っていたのですが、OWASPの文書を読みなおしたところ、これは僕の思い過ごしだったかと思い始めました。あくまでOWASPに限った話ではありますが… OWASP Top 10 2004については、以下のようなプレゼンをしたことがあります（2012年3月27日）。 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ OWASP Top 10 2004をはじめとして、バリデーションが過剰に重視されているのではないかという指摘でした。 しかし、最近OWASPの文書を読みなおしてみると、OWASP Top 10 2004当時にあった「バリデーション至上主義」のようなものはすっかり影を潜め、私が（そして日本の専門家の多くが）言っていることとほとんど変わらないことに
乱数の性質とセッショントークンの作成 - $shibayu36->blog;
ユーザアカウントのログイン機能とか作ってると、何らかの形でセッション用のトークンを作成する機会がある。今まではこれは適当にランダムな値を利用していればいいんでしょと思っていたのだけど、ちょっと違ったのでメモ。 乱数の性質 http://akademeia.info/index.php?%CD%F0%BF%F4によると、乱数には三つの性質がある。 無作為性：統計的な偏りがなく、でたらめな数列になっているという性質。 予測不可能性：過去の数列から次の数を予測できないという性質。 再現不可能性：同じ数列を再現できないという性質。再現するためには、数列そのものを保存しておくしかない。 この時、少なくとも無作為性のみ満たされていると弱い擬似乱数、無作為性と予測不可能性が満たされていると強い擬似乱数、全てが満たされていれば真の乱数と呼ばれる。ソフトウェアだけでは、真の乱数を作ることができず、真の乱数に
scryptがGPUに破られる時 | びりあるの研究ノート
一般的によく知られている SHA-256 や MD5 などのハッシュ関数は非常に単純な設計となっており、非力なパソコンや組み込み機器、スマフォなどでも高速に計算できます。 しかしながらその一方で、ハッシュ関数を手当たり次第に計算し、もとの入力値を復元するいわゆる「ブルートフォース攻撃」が容易であるというデメリットがあります。 特にこのような SHA-256 や MD5 といったハッシュ関数は、GPU を用いるか、もしくは専用のハードウェア (FPGA もしくは ASIC) を製作することで非常に高い効率で計算（攻撃）ができてしまうことが知られています。 そのため、GPU ないし専用ハードウェアを用いたとしても、攻撃効率の改善が難しくなるような新たなハッシュ関数がいくつか提案されています。 その中で比較的古く (2012年ごろ) に開発され、他のハッシュ関数にも影響を与えている「scrypt
第53回プログラミング・シンポジウムでx86 JITコンパイラの脆弱性について発表します | TAKESAKO @ Yet another Cybozu Labs
今回思い切って情報処理学会の第53回プログラミング・シンポジウムにて「x86 JITコンパイラ上で任意コードを実行する方法」という題目の発表をすることになりました。 発表の背景 2011年2011年3月31日に設立したサイボウズ・ラボユースの新屋さんと鈴木さんの作っているプログラムの成果が結構形になってきたため、そのお披露目と学生引率も兼ねて、今回自分もサーベイ論文を書いて応募してみました。特に新しい未知の脆弱性というわけでもなく、JIT-Sprayという現在のドキュメントフォーマット攻撃でよく使われている既知の手法をDEPとASLRの攻略という観点から8ページで日本語で解説したものです。英語の解説記事はBlackHatのような国際セキュリティカンファレンスの発表資料などでいっぱいあるのですが、日本語でJIT-Sprayに関してまとまった記事を見かけなかったので自分で書いてみることにしまし
GPGPU時代のハッシュアルゴリズム
Coding Horror: Speed Hashing xkcd: Password Strength GPGPUが一般的になった現代では、従来のハッシュアルゴリズムは十分な強度ではないというお話。一般人が五百ドル程度で購入できるハイエンドグラフィックカードは、現在のハイエンドCPUより150倍も高速にハッシュ計算ができる。しかも、GPGPUで高速に計算できるということは、並列性が高いということを意味する。つまり、GPUを増やせば容易にスケールするので、さらに危ない。 もはや、MD5やSHA-1、SHA-2の時代は終わった。これからの開発者は、GPGPUに対しても十分な強度を持つ、容易に並列化できないハッシュアルゴリズムを採用しなければならない。 ユーザーは、長いパスワードを使わなければならない。現時点でのJeff Atwoodのおすすめは、12文字以上である。1(xY%08などという、
「安全なアプリケーションを作成するために」の資料アップしました。
先日のブログでご紹介したとおり、Androidの会１２月の定例イベントに登壇させて頂きました。 その時に使用しました資料をアップしました。下記リンクよりダウンロード可能です。 2011年12月５日 日本アンドロイドの会定例 安全なアプリケーションを作成するために資料(PDF) ソフトウェアを作成する観点から、アンドロイドのセキュリティってどのような機能があるのか、注意点等を説明しています。ただ、私は、基本的にパワポにあまり詳しく書かずに、キーワードを書いておきその場で話す内容を決めていくタイプなので、あまり詳しく資料には書いてないので、これだけではあまりわからないかなぁと思ったりもしています。（今回の資料は書いてあるほうなのですが…) 実は昨日は、持ち時間が３０分だったのですが、少しぐらいオーバしても大丈夫だろうと、思っていたのですが、みんな仲良くそんな感じだったらしく、全体としてかなり時
「最も危険なプログラミングエラー」25種類のリスト発表
サイバースパイやサイバー犯罪につながる「危険なプログラミングエラー」の上位25種類をSANSが発表した。 SANS Instituteは1月12日、ソフトウェアの脆弱性発生の原因となる「最も危険なプログラミングエラー」上位25種類のリストを発表した。 リスト作成には、米SymantecやMicrosoftなどの民間企業、カリフォルニア大学などの学術機関、米国土安全保障省の国家サイバーセキュリティ部門（NCSD）、日本の情報処理推進機構（IPA）などが協力した。「コンポーネント間のセキュアでない相互作用」「危険なリソースマネジメント」「防御の不備」の3分野にわたる計25項目を「最も危険なプログラミングエラー」として挙げた。 2008年は、このうち2項目だけで150万件のWebサイトセキュリティの問題が発生。問題のあるWebサイトを訪れたユーザーのコンピュータが、攻撃者によって「ゾンビPC」に
初心者はPHPで脆弱なウェブアプリをどんどん量産すべし
http://www.rubyist.net/~matz/20080126.html#p04 趣味でやってるプログラミング初心者の立場で言わせてもらう。だいたいな、あんたらプロのプログラマが小難しい顔してセキュリティセキュリティ言うもんだから初心者プログラマのセキュリティ意識がまったく向上しないばかりか、よけいに低下するんだよ。ごちゃごちゃ言われたり叩かれるのはイヤだけど、眼前の問題はプログラムで解決したいってヤツは耳塞いで黙ってPHPでやりたいようにやるんだよ。何が「楽しいRuby」だよ。「Webアプリケーションをなめるな」ってその時点でもう全然楽しくねーだろが。 それでこれだよ。 http://d.hatena.ne.jp/essa/20080130/p1 もう萎縮萎縮！初心者超萎縮ですよ。「あーセンコーうぜー。隠れてタバコ吸おう」って高校生の心境だよ。難しい顔して訳知り顔でかっこつけ
Matzにっき(2008-01-29): PHP使いの反論
<< 2008/01/ 1 1. 年賀状 2. ゴビウス 3. [Ruby] ZSFA -- Rails Is A Ghetto 2 1. 新年会 3 4 1. The Mythical 5% 5 6 7 8 1. [言語] Substroke Design Dump 2. [言語] A programming language cannot be better without being unintuitive 3. [OSS] McAfee throws some FUD at the GPL - The INQUIRER 9 1. [言語] Well, I'm Back: String Theory 2. [言語] StringRepresentations - The Larceny Project - Trac 10 1. [Ruby] マルチVMでRubyを並列化、サンと東大が
試訳 - コードをセキュアにする10の作法 : 404 Blog Not Found
2008年01月05日02:45 カテゴリ翻訳/紹介Code 試訳 - コードをセキュアにする10の作法 全コーダー必読。プログラマーだけではなく法を作る人も全員。 Top 10 Secure Coding Practices - CERT Secure Coding Standards 突っ込み希望なので、いつもの「惰訳」ではなく「試訳」としました。 Enjoy -- with Care! Dan the Coder to Err -- and Fix コードをセキュアにする10の作法 (Top 10 Secure Coding Practices) 入力を検証せよ(Validate input) - 信頼なきデータソースからの入力は、全て検証するようにしましょう。適切な入力検証は、大部分のソフトウェア脆弱性を取り除きます。外部データは疑って掛かりましょう。これらにはコマンドライン引数、
Mozilla、セキュア・コーディング分析ツールを外部開発者に公開へ――ソフト開発コミュニティ全体の脆弱性削減の取り組みに貢献？ | OSDN Magazine
米国Mozilla Corporationの幹部は、先週ラスベガスで開催された「Black Hat 2007」（7月28日～8月2日）で講演し、Webブラウザに存在する脆弱性を減らすための取り組みとして、同社が社内で開発した広範なセキュア・コーディング分析ツールを、社外の開発者と共有していく方針を明らかにした。 サンフランシスコに拠点を置くMozillaでセキュリティ責任者を務めるウィンドウ・スナイダー氏によると、MozillaはJavaScriptコードのセキュリティ・ホールを発見するツールを手始めに、多数のファジング・プログラムを開発者に公開することを計画しているという。 Mozillaの共同設立者であるマイク・シェーバー氏とスナイダー氏は、同社が社内開発した技術が、MicrosoftやOpera、Appleなどの競合ベンダーの製品も含む、Webブラウザ全体のJavaScriptエラー
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
動的メモリ管理に関する脆弱性
CodeZine：Rubyを使ってWebアプリケーションの脆弱性を早期に検出する（Web, テスト, Ruby）
Wizard Bible