どうして JWT をセッションに使っちゃうわけ？ - co3k.org
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
Composer のセキュリティ上の問題が直ったので PHP な方は今すぐ更新を - co3k.org
Composer の以下の問題が 2 月半ばあたりから話題になっていました。 Limit Replace / Provides to packages required by name in root package or any dep · Issue #2690 · composer/composer https://github.com/composer/composer/issues/2690 一言で言うと、 条件によってはユーザの意図しないパッケージがインストールされてしまう という問題です。悪意のあるパッケージをインストールしたことに気づかれなければ、攻撃者の思い通りのコードを実行させることができてしまいます。 ざっくり説明すると、 Composer には fork したパッケージや、リネームしたパッケージ から 、元のパッケージを置き換えることのできる機能が存在する (本エン
PHP 5.3 でネイティブ関数の引数型エラー時の返り値が変更になったけど大丈夫？ - co3k.org
PHP 5.5.0 リリースおめでとうございます。 タイミング的に PHP 5.5 の話だと読み間違えた方 (もしくは「こいつ間違って PHP 5.3 って書いてやがるプギャー」と思った方) におかれましては、このテキーラはサービスだから、まず飲んで落ち着いてほしい。 はい。ということで、驚くべきことに、いまから、真顔で、 PHP 5.3 の変更点の話をします。でも PHP 5.5 が出るにあたってコードを見直す方もいるでしょうし、なんというかついでに気に掛けていただければと。 何の話か PHP 5.3 の「下位互換性のない変更点」として、マニュアルに以下のように示されている件についての話です。 引数を解釈する内部API が、PHP 5.3.x に同梱されている全ての拡張機能に 適用されるようになりました。つまり、互換性のないパラメーターが渡された場合、 この引数を解釈するAPIは NUL
次のプロジェクトで PHP 5.4 の採用を提案するための 3 つのポイント (PHP 5.4 Advent Calendar 2011 19 日目) - co3k.org
PHP 5.4 Advent Calendar 2011 19 日目です。 前回は @cocoitiban さん でした。 htmlspecialchars() のオプション追加については個人的にも気になっていたところ（Symfony2 の https://github.com/symfony/symfony/commit/053b42158e2f887b54a3e87977303d219530082f というコミットで気づいた）で、ふむふむと読ませていただきました。たとえば、文書型を考慮するようになると SGML 的に (あれ、 HTML 的にだっけ？) 違法である NULL 文字とかがさっくり消えて、 IE が NULL 文字を無視したりして XSS に繋がりうる問題 が回避できるようになったりするんですかねえ。 さて、これまでの Advent Calendar で触れられてきたように
Symfony2 の力を借りたセキュア開発 (Symfony Advent Calender 2011 JP - 18日目) - co3k.org
Symfony Advent Calender 2011 JP 18日目です。前回は @hidenorigoto さんでした。リダイレクト・インターセプションは 2.0.0 が出る前のどこかのタイミングでデフォルトでオフになって焦った記憶があります。投稿処理などをしたタイミングでプロファイラを見る機会が多いので、有効にしておくと便利ですよね。 さて、 18 日目となるこのエントリでは、セキュリティの観点から Symfony2 の機能について簡単に観ていくことにします（本当はしっかり見ていくつもりだったのですが、時間的制約から急遽簡単になりました！）。 ここでは Symfony Standard Edition v2.0.7 のインストール直後の構成、依存ライブラリを前提として解説します。また、 Web アプリケーションセキュリティに関する基本的な知識を持っていることを前提として説明します。
攻撃者がセッション ID を入手可能な状態で CSRF 攻撃を仕掛ける可能性について検討した - co3k.org
仕事で「フレームワークで使ってる CSRF 対策用トークンがセッション ID を基にいろいろ組み合わせた文字列のハッシュなんだけれども、なんでセッション ID 直接使わないんだよう」的な話が出たので、なんでだろうなーと考えつつ理由について検討してみたので以下に一部晒してみます（社内向けに書いたものなのでいろいろ雑だったりするのはごめんね）: 推測ですが、セッション ID が GET パラメータとかに含まれたりする可能性を避けたかったんじゃないかなあとか思います（フォームは GET でも使われうることを想定している）。 GET パラメータにセッション ID のような種類の情報は含めるべきではありません。 あと、セッション ID が盗まれた場合でも CSRF 攻撃を受けないようにするという意図もありそうな気がします。攻撃者がセッション ID を知っている状況で CSRF 攻撃を選択する状況につ
au の F001 に存在した EZ 番号詐称の脆弱性について - co3k.org
このエントリでは、海老原が 11/11 に発見した、「F001 の PC サイトビューアを利用して EZ 番号の作業がおこなえる」という脆弱性について説明します。 この脆弱性を利用されると、たとえば、「かんたんログイン」などの機能を提供する勝手サイトにおいて、 au 端末を利用したユーザになりすまされてしまうといった被害が発生しえます。 本問題の解決に向けてご協力いただいた 徳丸さんのブログエントリ にも詳しく触れられていますのでそちらもご一読ください。 おさらい 徳丸浩さんの以下のエントリで説明されているとおり、 au の 2011 年秋冬モデルの端末でおこなわれる（と宣言されている）変更が、「かんたんログイン」等の用途で使われている EZ 番号の詐称を許す可能性があるのではないかと多くの方々の間で懸念されていました。 IPアドレスについてはKDDI au: 技術情報 > IPアドレス帯
『symfony 1.4によるWebアプリケーション開発』（#sf14book）出たよー（書いたよー）という話 - co3k.org
本日、秀和システム様より『symfony 1.4によるWebアプリケーション開発』が発売されました！ 日本 Symfony ユーザー会著ということで、いろいろな方々が本書の執筆に参加されていますが、実は海老原も 12 章の「大規模なソフトウェアへの応用」の執筆を担当させていただきました！ ということで以下軽く紹介させてください。 （本書についての情報はサポートサイト http://books.symfony.gr.jp/14book/ をご覧ください） 震災と重なって流通が安定していないなかの出版ということもあってか、それなりに大きな書店でもまだ並べられていないところがあったりするようですね（Amazon.co.jp でも在庫切れ）。 著者献本いただけるとのことなのですが、早く手に入れたくて、池袋ジュンク堂で見つけたそばから購入してしまいました（笑）。 12 章では、 OpenPNE 3
CakePHP の PHP コード実行の脆弱性を使って CakePHP を焦がす - co3k.org
2010/11/13 に出たらしい http://bakery.cakephp.org/articles/markstory/2010/11/13/cakephp_1_3_6_and_1_2_9_released を読んでびっくりしたんですが、 Twitter を軽く検索した限りだと CakePHP ユーザでない僕が気づいているのに (日本の) CakePHP ユーザさんたちがどうも気づいていないっぽいのでわかりやすくまとめてみることにしました！ CakePHP には任意の PHP コードが実行できる致命的な脆弱性があります！ 影響のあるサイト結構ありそうですが悪用厳禁です！ ※通常リリースの告知のなかにこんな致命的な脆弱性に関する情報を思いっきりわかりにくく書いちゃうのはひどいなあと思うので、ユーザの方は CakePHP に文句を言うといいと思います。僕は CakePHP ユーザじゃない
secure.softbank.ne.jp について SoftBank に質問したら残念な結果になったの巻 - co3k.org
割と個人的には速報なので簡単にまとめます。 高木浩光さんの http://twitter.com/HiromitsuTakagi/status/16057716034 のアドバイスを受けて、 secure.softbank.ne.jp を通さないようにする方法などについて、以下のような質問を投げました。 https://secure.okweb3.jp/mobilecreation/EokpControl?&event=QE0004&tid=24187 HTTP から HTTPS へのリンクについて OpenPNE （http://www.openpne.jp/）というオープンソースのソフトウェアを開発している者です。 SSL 環境でログイン継続に Cookie を使うにあたり、 URL として https://example.com/ のような形式と、 https://secure.so
OpenPNE 3.5.3 での「かんたんログイン」の端末固有IDからの（部分的）脱却で困った点 - co3k.org
（個人ブログなので「携帯電話個体識別番号」ではなく「端末固有 ID」と呼ぶよ） ということで、 OpenPNE 3.5.3 でおこなった「かんたんログイン」の変更について http://www.openpne.jp/archives/5070/ の件です。 ここで説明されているのは（技術者には既知である事項の説明を除くと）、要するに以下のようなことです。 Cookie 内のランダムな ID を見る認証手段を用意したよ Cookie が使える端末では端末固有 ID ではなく Cookie 内の ID を見て「かんたんログイン」するようにしたよ 認証手段を「A: Cookie 内 ID のみ」「C: 端末固有 ID のみ」「B: A と B を併用」できるようにしたよ（see: http://twitter.com/co3k/status/15973375832 ） B の方法を選んだ場合は、
Symfony 2 の sandbox を試してみました (web/check.php だけ) - co3k.org
パリでおこなわれた Symfony Live 2010 にて、 Symfony 2 のプレビューリリース版が 2 月 17 日 19 時頃に GitHub で公開されました（ただし日本時間では 18 日 3 時頃という日本人泣かせな時間。今頃現地の方々は手元で Symfony 2 と戯れているんでしょうね、うらやましいです）。 http://github.com/symfony/symfony/ ということでもう寝たいのですが、 sandbox に web/check.php という動作環境確認用のフロントコントローラがいるので、それだけでも動作させてみました。 以下、取り急ぎ手順です: $ cd /path/to/document-root $ git clone git://github.com/symfony/symfony-sandbox.git $ cd symfony-sand
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
