[ruby-dev:41104] Rails3 M17N
Subject: [ruby-dev:41104] Rails3 M17N From: Yukihiro Matsumoto <matz@ b l g r Date: Fri, 30 Apr 2010 11:42:50 +0900 まつもと ゆきひろです Yehuda KatzからRails2を1.9で動かした場合、エンコーディング関 係の例外が大量に発生するので、一般ユーザのRail3への移行に障 害になる可能性があると連絡をもらいました。 彼らだけで1.9を用いた適切なM17N化を自分で考えるのは大変困難な ことだと思いますから、助けてあげたいところです。いぜんとして RailsはRubyにとって重要なアプリケーションなので、Rails3に対し て親切にしておくのは有意義だろうと考えます。 とはいえ、私自身がRailsやWebアプリについて無知なのは認めざる をえません。また、自分が基
htmlspecialchars()/htmlentities()について - 2009-10-19 - T.Teradaの日記
id:t_komuraさんの、最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容についてを読みました。 見ていて気になったことが１つあります。 2. EUC-JP …（省略）… (2) \x80 - \x8d, \x90 - \xa0, \xff については、そのまま出力される <?php var_dump( bin2hex( htmlspecialchars( "\x80", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x8d", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x90", ENT_QUOTES, "EUC-JP" ) ) ); va
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
[PDF] Apache-Tomcatと冗長なUTF-8表現 (CVE-2008-2938検証レポート) - NTTコミュニケーションズ株式会社 ITマネジメントサービス事業部 セキュリティオペレーションセンタ
Apache-Tomcat と冗長な UTF-8 表現 (CVE-2008-2938 検証レポート) N T T コ ミ ュ ニ ケ ー シ ョ ン ズ株式会社 IT マネジメントサービス事業部 セキュリティオペレーションセンタ 2008 年 9 月 25 日 Ver. 1.0 SR-20080110 1. 2. 3. 調査概要 .............................................................................................................................. 3 UTF-8 とは ..........................................................................................
htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月30日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の第三パラメータ（文字エンコーディング指定）により、どこまで文字エンコーディングの妥当性チェックをしているかを報告します。 2007年4月に、寺田氏(id:teracc)の素晴らしいエントリ「htmlspecialcharsと不正な文字の話」により、htmlspecialcharsは、第三パラメータの文字コードを実質的に無視しており、不正な文字エンコーディングが指定された場合、その文字はチェックされずにすり抜けてしまうという結果が報告されています。
出力文字エンコーディングのバリデーション
(Last Updated On: 2013年11月29日)前のエントリで「書かない日記」の名前通り、出力文字エンコーディングのバリデーションについてあまりに書かなさすぎで何の事やら分からない方も居たと思います。もう少し詳しく書きます。出力バッファとエラーハンドラで出力文字エンコーディングを簡単にバリデーションできます。 PHPで出力文字エンコーディングをバリデーション ステップ1: エラーハンドラを登録 function myErrorHandler($errno, $errstr, $errfile, $errline) { // 出力バッファをクリア - header()で送信したヘッダもクリア ob_end_clean(); // エラーメッセージ - もちろんエラーの種類に合わせたHTMLでも良い echo "Some thing goes wrong."; // 本来はエラーロ
Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由
(Last Updated On: 2018年8月8日)Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリをまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは？と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 なぜRuby 1.9でエラーが起きるのか ActionController::Response#etag= メソッドの定義は下記のとおりです。 def etag=(etag) if etag.blank? headers.delete('ETag') else headers['ETag'] = %("#{Digest::MD5.hexdigest(ActiveSupport
ライブラリのM17Nについての自分向けメモ - [サ]ロンパスの日記
自分向けに要点だけメモっとく。 1.9対応かつM17Nでちゃんと動くように作る場合に あとでこのメモを参照しよう。 基本的に入力も出力もUnicode(UTF-8)を想定する。 Encoding#default_internal が設定されている場合はそのエンコーディングで返す 入力については、String#encodingを見る DummyEncodingは文字列として扱えない。 ユーザがString#force_encodingしないとならないようでは、M17N対応できたライブラリとは言えない。 ほとんどのライブラリは入出力はUTF-8だけを想定していていいんだけど、 ライブラリの性質上、どうしてもUTF-8以外のエンコーディングを入出力で取り扱わなければならない場合は、入力されたStringのString#encodingを確認したり、Encoding#defualt_interna
![ライブラリのM17Nについての自分向けメモ - [サ]ロンパスの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f453e75d4933fe21d21409862cf3ed586989a0a/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127121195678%2F17680117127121196381%2F1557252015)
[ruby-dev:36523] Re: Encoding.default_internal のためのパッチ
Subject: [ruby-dev:36523] Re: Encoding.default_internal のためのパッチ From: Yukihiro Matsumoto <matz@ b l g r Date: Thu, 25 Sep 2008 00:49:10 +0900 In-reply-to: 36517 まつもと ゆきひろです In message "Re: [ruby-dev:36517] Re: Encoding.default_internal のためのパッチ" on Wed, 24 Sep 2008 21:23:48 +0900, "NARUSE, Yui" <naruse / airemix.jp> writes: |Martin Duerst wrote: |> [ruby-core:18774] に Michael Selig から Encoding::def
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
mb_check_encoding() の代替関数 - t_komuraの日記
これまでに挙げた文字コードについて、正規表現を使用して mb_check_encoding() の代替用の関数を書いてみました。ある程度、妥当なものになっているとは思いますが、間違い等に気付いた方がおられましたら、ご指摘ください。 UTF-8 については、RFC3629 を参考にしました。各文字は4バイト以下、冗長な表現、サロゲートペアの領域を FALSE と判定します。 <?php function is_valid_encoding( $str, $encoding ) { switch ( $encoding ) { case 'ASCII' : $regex = '/(?:' . '[\x00-\x7f]' // ASCII (mb_check_encoding) // . '[\x00\x09\x0a\x0d\x20-\x7f]' // ASCII (mb_detect_enco
2009-09-10 - 問題はエンコーディングではないのだ
http://itpro.nikkeibp.co.jp/article/COLUMN/20090208/324377/?ST=security&P=1からhttp://d.hatena.ne.jp/tohokuaiki/20090910/encodingの話。 ベースライン。 Webアプリケーション、ここでは一般的な用法として次の条件を満たすもの、の話に限定して進めよう。 サーバ・クライアント型のアプリケーションである。 http経由で通信する。 サーバ・クライアント型。 間に通信層が挟まっている以上、通信層の信頼性を考慮しなくてはならない。 限定少数の利用者しかいない有線LANならば、パケット化けは起こるとしても、意図的な攻撃を想定する必要はないかもしれない。利用者が増えるにしたがってワームに感染したPCが混じっている可能性も高まるだろう。無線LANならば管理者の気付かぬうちに利用端末が
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Masayoshi Takahashi on Twitter: "後輩の文字コード本原稿がたいへん面白い。来年本になるからみんな読むように"
PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence
[ruby] Contents of /trunk/lib/cgi/util.rb
#48 Rack::Utils.unescape problems in Ruby 1.9.1 - rack
QUERY_STRINGとかエンティティのcharsetってリクエスト単位、もっ... by ちば - Wassr [お気軽メッセージングハブ・ワッサー]
Blogger