FORM Encode and Servlet
関連リンク集：/「Javaの哲学」の恥かき/「Javaによるテキスト処理」の恥かき/「モア・サーブレット」の恥かき/恥かきのホームページ/JavaBeginner/javacのエラーメッセージ/UIDefaultsのkeyとデフォルト値/comp.lang.java.guiのFAQ/ ★2006年より、Javaプログラミング関連記事の新規掲載場所を[Javaの手帖]に統一しました。 [ ][HOME][NEXT](シングルトンと同期化) 「コア・サーブレット」（原書）は昨年(2003)８月に第二版が出まして、大幅に改定＆増補されました。私（岩谷）自身の経験も含めて、ここに、有意義なメモを作っていこうと思います。 (1)FORMデータ, GET/POST, multipartの問題 第一版16章には、FORMデータをGETでなくPOSTで送るためにはENCTYPE="mult
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
