不適切な脆弱性情報ハンドリングが生んだ WordPress プラグイン cforms II のゼロデイ脆弱性 - co3k.org
2012/02/15、 JVN から JVN#35256978: cforms II におけるクロスサイトスクリプティングの脆弱性 が公開されました。これはクレジットされているとおり、海老原と、同僚の渡辺優也君が勤務中に発見した脆弱性です。 脆弱性自体はどこにでもあるような普通の XSS ですが、実はこの脆弱性、 2010 年 10 月に exploit コードが公開され、それから 1 年 4 ヶ月後の 2012 年 2 月まで修正版が提供されていなかったものです。 このような危険な状態が長期間続いていたのには、様々な理由があります。ここでは、その説明と、どうすれば事態が防げたかということについて検討したいと思います。 脆弱性の概要 本題に入る前に、主に cforms II のユーザ向けに脆弱性自体の概要についてざっくり説明します。前述のとおり、未修正の状態で exploit コードが公開
SE・プログラマが知ってると便利な脆弱性チェックツール 5 つ | バシャログ。
東京ラーメンショー2011 いきてーーー！みなさんこんにちは、nakamura です。 今日はプログラマだったりサーバ管理者だったり（もしくはその両方だったり）する方にお勧めしたいサイトとツールをいくつかご紹介します。細かい脆弱性のチェック等どうしても手間が掛かるものが多いですが、今回ご紹介するツールをうまく使うとその辺りだいぶ効率よくできると思いますよ！ WEB アプリケーション関連 XSS Me XSS Me :: Add-ons for Firefox XSS のテストをある程度自動化してくれる Firefox のアドオンです。残念ながら Firefox3.0.* 系の頃に開発が止まってしまっているようですが、僕の環境では install.rdf の書き換えで問題なく動作しています。（Windows7 64bit + Firefox7.0.1） SQL Inject Me SQL I
スマホアプリとプライバシーの「越えてはいけない一線」 － ＠IT
スマートフォンアプリは果たしてどこまで、端末に関する情報を取得してもいいのだろうか。 位置情報と連動してお勧め店舗情報を表示したり、過去の検索履歴を基に商品を提案したりと、端末の情報やユーザーの行動履歴を活用するスマートフォンアプリが登場している。中には便利なものも多いが、一歩間違えれば、ユーザーのプライベートな情報が筒抜けになりかねない。結果として、スマートフォンを活用したビジネスやそれを支える広告市場までもが、否定的な目で見られ、発展を阻害される恐れもある。 この議論が起こったきっかけの1つは、ミログが公開していた「AppLog」と「app.tv」というアプリだ。AppLogはSDKの形で提供され、これを自前のアプリに組み込むと、Android端末にインストールされているアプリの情報やその起動回数を収集し、同社のアプリケーション分析サービスに送信するようになっていた。開発者にはインスト
今日こそわかる、安全なWebアプリの作り方2010
Internet Week 2010 S3 今日こそわかる、安全なWebアプリの作り方2010 http://www.nic.ad.jp/iw2010/program/s3/ Read less
Webアプリでパスワード保護はどこまでやればいいか
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
エンコードマニアックス
SHA-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 SHA-384 38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b SHA-512 cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
最近発覚したパスワードに関する重大な脆弱性4選 - ockeghem's blog
最近、パスワードにまつわる重大な脆弱性を見かけることが多いように思いますので、その中から4つを選んで紹介します。既に私のブログで紹介したものや、少し古い問題も含まれます。 PHP5.3.7のcrypt関数がハッシュ値を返さない脆弱性 crypt関数は、様々なハッシュアルゴリズムによるソルト化ハッシュを返す関数ですが、PHP5.3.7（2011年8月18日リリース）において、crypt関数にMD5を指定した場合、ハッシュ値を返さない（ソルトは返す）バグがありました。私のブログエントリにて説明したように、最悪ケースでは任意のパスワードで認証できてしまう状況があり得ました。 PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439) | 徳丸浩の日記 PHP :: Bug #55439 :: crypt() returns only the salt for MD5 このバグが混入
Apache killerは危険～Apache killerを評価する上での注意～
Apacheの脆弱性(CVE-2011-3192)いわゆるApache killerが話題になっていますが、その脅威については一部誤解があるようです。 以下は、非常に脅威とする報告の例です。 一方今回のはプロセスの肥大化を伴うので、実メモリ消費して更にスワップも使い尽くしてOS毎激重になったあげくLinuxとかの場合はOOM Killer発動と、他のプロセスや場合によってはOSを巻き込んで逝ってしまいます。 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.xより引用 以下は、それほど脅威でなかったとする報告の例です。 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 Apache Killer (CVE-2011-3192) 対策 for CentOS 5
iOSのUDID問題 | 水無月ばけらのえび日記
公開: 2011年8月27日16時25分頃 iOS5以降ではUDIDが段階的に廃止されるらしい、という話に対して、それでは困るという話が出てきて盛り上がっているようですね。 UDIDに依存する人々とたしなめる人々 (togetter.com)iOS 5で、開発者がUDIDにアクセスすることを禁止 (yebo-blog.blogspot.com)UDIDは端末ごとに固有で不変のIDなので、つまりはケータイIDと同じようなものです。ケータイIDの場合には以下のような性質があり、 全てのサイトに同一のIDが送出される (IDは秘密情報ではない)送出するIDを改竄することが難しい (キャリアのゲートウェイを通るため)後者の条件があるため、危険だと言われつつも辛うじて成立しています (それでも、キャリアのゲートウェイを通ってきたことを確認する必要があったり、さまざまな条件があります)。しかしiPho
PHP5.3.7のcrypt関数のバグはこうして生まれた
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal
前回のまとめ 前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り３つあった。 1. サーバとのセッションを管理するための認証に使われてしまっている 2. アプリケーションをまたがっての行動トラッキングに使われてしまっている 3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。 このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。 2. に関しては、実はデバイス固有IDであることについてはそれほどこの時点では問題ではなく、単にトラッキングされることに対してユーザの同意も拒否も介在する余地が無い、というところを問題にし
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境
なぜiOSでUDIDが必要とされていたのか、メモ - snippets from shinichitomita’s journal
iOSやその開発事情に詳しいと言える状態にはないので、調査を兼ねて書く。 Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID – TechCrunch http://wirelesswire.jp/Watching_World/201108221335.html 上記の「iOSでUDIDの利用が禁止」というニュースを聞いた時、正直TL上にこんなにいっぱい反応が貼り出されるとは思っていなかった。さすがにUDIDをいじるのはまずいよね、っていうコンセンサスは開発者の間では常識的部類に入ってくるのだろうと楽観的に捉えていたのかもしれない。 以下、なぜUDIDがそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。 アプリケーションのサーバとのセッション保持 い
UDIDが使えなくなりそうなので、UIIDを使えるようにしました
■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c
“日本は特殊な国”か、通信を可視化してみたら意外な事実が分かった
例えばFacebookやTwitterなどのソーシャルサービスは、実際にどれくらい国内企業ネットで使われているのか---。大手ファイアウォールベンダーの米パロアルトネットワークスは、半年に一度、世界中のユーザー企業を対象に大規模なトラフィック調査を実施し、様々なデータを収集および分析している。来日した調査担当者に、日本の国内企業におけるトラフィック傾向などについて話を聞いた。 まずは調査の概要について教えてほしい。 2008年から約半年に1回の割合で、世界中のユーザー企業を対象にトラフィック調査を実施している。最新のデータは2011年5月に実施した調査で得たもので、調査対象となった企業の数は全世界で合計1253社、そのうち日本の企業は87社入っている。調査対象企業の数は回を重ねるごとに大きく増えており、前回（2010年10月）は723社、前々回（2010年3月）は347社だった。具体的な企
mixi足あと廃止に寄せて - 最速転職研究会 | コメント mixiって今ほとんどがモバイルでアクセスされてたはずだけど、スマホ以外のガラケーでもこの問題が起きるの？
mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後) アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。 過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。 http://internet.kil
ケータイWebの今後を安全に保つには
“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 前回では、URLにセッションIDを埋め込むことの問題点を指摘した上で、今後はできるだけケータイでもCookieを使うことを提案しました。それを受けて今回は、前半で、ケータイWebでCookieを使う際の注意点について説明します。 そして後半では、連載の終わりに当たり、スマートフォンが普及しつつある状況下でのケータイWebの今後について説明します。 ケータイWebにおけるCookieは「取り扱い注意」 これまで説明したように、KDDIとソフトバンクのケータイでは従来からCookieが利用でき、NTTドコモの端末でも2009年夏モ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ひろみちゅ先生による「カレログ」の違法性検証
