文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
岡崎市中央図書館に1秒間に1回アクセスしたら逮捕されたけど不起訴になった件について
岡崎市中央図書館に1秒間に1回アクセスしたら逮捕されたけど不起訴になった件について。 当事者からの報告とそれに関連した高木先生などのつぶやきをまとめています。不完全かつ進行中です。
JavaアプレットのDNSリバインディングはJRE側で対策済みだった - 徳丸浩の日記
Black Hat Japan 2007における金床氏のプレゼンテーションや金床本で、Javaアプレットに対するDNSリバインディングの手法が説明されている。ここしばらく、その追試を行っていた。結論としては、金床氏の方法にはJRE側で対策がとられていたので報告する。 金床氏が報告しているDNSリバインディングの手法とは以下のようなものだ（金床本に説明されている方法）。 被害者のユーザにワナのページをPROXY経由で閲覧させる ワナのドメイン(FQDN)に対するIPアドレスを変更する ワナページ上で数秒～数十秒のちにJavaScriptによりJavaアプレット用のHTMLをレンダリングする JREがアプレットをPROXY経由で*1ダウンロードする アプレットのダウンロード時点で既にDNSレコードは書き換わっているが、PROXYがDNSキャッシュしているため、アプレットは正常にダウンロードされ
情報処理推進機構：情報セキュリティ：脆弱性対策 : 「Web Application Firewall 読本」を公開
IPA（独立行政法人情報処理推進機構、理事長：西垣 浩司）は、ウェブサイトの脆弱性の修正作業が長期化している事例が少なくないことから、ウェブサイト運営者がWeb Application Firewall（ウェブ・アプリケーション・ファイアウォール、WAF）を導入する際の参考となる解説資料「Web Application Firewall 読本」を2010年2月16日（火）からIPAのウェブサイトで公開しました。 URL： http://www.ipa.go.jp/security/vuln/waf.html Web Application Firewall（WAF）は、ウェブアプリケーション(*1)の脆弱性(*2)を悪用した攻撃などからウェブアプリケーションを保護するソフトウェア、またはハードウェアです。WAFは脆弱性を修正するといったウェブアプリケーションの実装面での根本的な対策ではなく
セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 20091124.html
iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 HASHコンサルティング株式会社 公開日:2009年11月24日 追記日:2010年1月21日 概要 iモードブラウザ2.0のJavaScriptとDNS Rebinding問題の組み合わせにより、iモードIDを利用した認証機能（以下かんたんログイン）に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザ（たとえばiモードブラウザ）に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固
CSRF対策は基本? | 水無月ばけらのえび日記
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや
SSL/TLSに男らしい脆弱性が発覚 - .mjtの日記復帰計画
next : http://d.hatena.ne.jp/mjt/20091110/p1 追記 : 問題は対策されつつあり、近い将来には重要な問題で無くなる可能性が高い。 http://journal.mycom.co.jp/news/2009/11/09/006/index.html サマリ : クライアント証明書を持って無い人は関係ない。Web上で本人証明を伴うサービスを使ってる人は関係有る。 TLSとSSLは同じものと考えて良い。どちらにもこの問題は有る。以下TLSに統一。 前提 ここでのTLS+HTTPでは、２種類のセキュアなコミュニケーションが存在すると仮定する。 (A) 匿名でおこなわれる通信 (B) 身分証明(クライアント証明)を伴う通信 Bは、例えば電子申請とかに使われる。税金の申告とかをICカードとPCの組み合わせで行うようなアレ。 今回の問題は、このBが危なくなったとい
他人のドメインのGoogleAppsが取得できてしまうんだが（汗 - y-kawazの日記
前エントリ（中古ドメインでGoogleAppsを使ったら）でGoogleAppsネタを書いている最中に更に思いついてしまったネタがあって、試してみたら出来ちゃったので追加でネタにしてみます。 なんとGoogleAppsで、自分所有でないドメインで「ドメインの所有権の確認」もクリアした上での取得が出来てしまいました(^^; これは脆弱性の発見だと思います。ただし、後述するように厳密にはGoogleAppsの脆弱性ではなく、ドメインのWEBサイトの問題だと思います。もしくは「htmlアップロードに寄るサイト所有者の確認という手法」に関する脆弱性かもしれません。 取得が成功する条件は「http://example.jp/googlehostedservice.htmlのページを編集できること」だけです。 なんだ普通は出来ないから平気でしょ？と思いましたよね。僕もそう思いました。ですが偶にあります
Twitter, OAuth and Passwords - Oh My!
Twitter has a gaping security hole. Changing your password won't stop malicious users logging in as you! I received a rather worrying email from Twitter. Apparently they thought my password had been compromised and needed to be reset. After checking to see if it was valid, I went and changed my password. Any site which relied on a cookie to post to Twitter would have been blocked out. Ha! Gotch
WPA の脆弱性の報告に関する分析 (技術編)
文献 [1] や [6] による攻撃に対し、WPA (TKIP), WPA2 (TKIP) の組合せはどちらも脆弱であると考えられます。 一方、現時点で WPA (AES) および WPA2 (AES) に対して、これらの攻撃は適用できず、有効な改良手法もまだ報告されていません (表1)。 攻撃の現実性については、文献 [1] の攻撃のうちの1つ については、ネットワーク機器が特定の機能（QoS＝通信ごとの優先度設定）を有する場合、 単純なネットワーク盗聴で攻撃が可能なため、現実の脅威があるものと考えられます。 この攻撃については、既に攻撃ツールが公開されています。 一方、文献 [1] のもう1つの攻撃と、文献 [6] の攻撃については、 実際の攻撃として成立するためには、無線LANの通信を能動的に妨害する必要があり、 たとえ攻撃に必要なツールを入手した場合でも、現実の多くの無線LAN導入
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
Ivan Ristić: SSL Threat Model
SSL is easy to use but also very easy to use incorrectly. The ecosystem, which is built of the specifications, the implementations, the CAs and the PKI, is full of traps, each of which is very easy to fall into. Once I started to spend significant time thinking about SSL I set out to build a model of the ecosystem, for my own education and to ensure that I understand it all. That's how I arrived t
apache.org incident report for 8282009 - Apache Infrastructure Website
Posted on: 2009-09-02 08:56:09+00:00 Last week we posted about the security breach that caused us to temporarily suspend some services. All services have now been restored. We have analyzed the events that led to the breach, and continued to work on improving the security of our systems. NOTE: At no time were any Apache Software Foundation code repositories, downloads, or users put at risk by thi
yebo blog: DNSSECの勉強 (1)
2007/01/04 DNSSECの勉強 (1) DNSSECは公開鍵暗号技術を使って、自ゾーンの(資源レコードではなく)RRセットに署名を施すことで第三者による改ざんや偽造を検証できるようにする技術である。ネームサーバの管理者が秘密鍵・公開鍵を作成して秘密鍵で署名を施し、「公開鍵はこうですから皆さん検証して下さい」では信頼性という点で何の意味も持たない。そこで、DNSSECは信用の連鎖(chain of trust)を形成することで鍵の信頼性を保証している。 DNSSECの歴史 DNSSECの歴史は結構古く、1990年にはSteven Bellovin氏がDNSのセキュリティ上の問題を発見した。しかし、その内容は5年間秘密にすることにして、その間にセキュアなDNSに置き換える研究が開始された。そして、1995年にBellovin氏の論文「Using the Domain Name Sys
BIND Dynamic Update DoS
BIND denial of service (server crash) caused by receipt of a specific remote dynamic update message. Urgent: this exploit is public. Please upgrade immediately. Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a m
The method to update your application from OAuth Core 1.0 to 1.0a - r-weblife
米Yahoo!がOAuth Core 1.0 Revision Aに対応しました。 http://developer.yahoo.net/blog/archives/2009/05/oauth_update_3.html http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/3/oauth-core-1_0a.html OAuth Security Advisory 2009.1 — OAuth 説明は省略して、結局今までOAuthのConsumerを実装してた人はどうすればいいのかをざっくりまとめておきます。 以下の4つの対応が必要です。 Request Token取得要求時にoauth_callbackパラメータを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://mail-archives.apache.org/mod_mbox/couchdb-dev/201003.mbox/%3C2731D210-DFD4-41C4-B50E-4D309FAA6184@apache.org%3E
Q&A: Researcher Karsten Nohl on mobile eavesdropping - CNET
<4D6963726F736F667420506F776572506F696E74202D2081798E9197BF8253817C8253817A4950763689BB82C994BA82A4835A834C8385838A836583428AC28BAB95CF89BB82C682BB82CC89658BBF82C982C282A282C481694E49435497CD95908E81816A2E707074>
http://twitter.com/skubota/status/2900962927