・「美乳」で文字化けが直るって本当？ オンラインＤＶＤ＆ＣＤレンタルなら月々1980円で借り放題のＤＭＭがお得！ えっ？ って聞きなおしたくなるようなタイトルですが、「この『美乳』という文字をヘッダー部分にコメントとして挿入しておくと、文字化けが直る」という話は確かに存在します。ただし、これは大前提としてEUC-JPのページを作成するならば、という話になります。 <HTML> <HEAD> <meta http-equiv=Content-Type content="text/html; charset=EUC-JP"> <!-- 美乳 --> <TITLE>テスト1</TITLE> </HEAD> <BODY bgcolor="#FFFFFF"> このページはアダルトサイトとは無縁です。ヌード画像などは一切ありません。 </BODY> </HTML> では、なぜ、この「美乳」がおまじない
charsetに関するTAKESAKOのブックマーク (62)
-
TAKESAKO 2009/12/22
-
ウェブリブログ：サービスは終了しました。
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
-
何故かあたり前にならない文字エンコーディングバリデーション - ikepyonのだめ人間日記
http://blog.ohgaki.net/char_encoding_must_be_validated まあ、当たり前にはならないでしょう。どう考えても不正な文字エンコーディングを受け付ける言語やらフレームワーク、DB、ブラウザが悪いと思う。不正な文字エンコーディングをチェックするというのはバッドノウハウだと思うし。そんなことに対応するのは大変すぎるからねぇ。 アプリ開発者を啓蒙するより、PHPとか直したほうが早いと思うんだけど。 XSSやSQLインジェクションが発生しないようにエスケープ処理やバインド機能を使うというのは、プログラムの基本に立ち返って、どんなデータが渡されても正確に処理を実行するために必要なことなので、当たり前といえると思う。 でも、不正な文字エンコーディングのチェックはプログラミング手法ではなく、それを受け取って変に解釈してしまうDBやらブラウザなどが直せないから
-
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: )私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けにもう少し解りやすい
-
第7回 Unicodeからの多対一の変換［前編］ | gihyo.jp
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
-
UTF-8の動的コンテンツをShift_JISと誤認させることで成立するXSS - masa141421356’s blog
文字コード指定の無いUTF-8のコンテンツでは、ブラウザ側の文字コード自動認識でシフトJISと誤認させることで、HTMLの特殊文字を一切使わずにXSSが成立する場合があります。 原理 UTF-8 では１文字が３バイトマッピングされる場合があります。 そこで、これをShift_JISと誤認させると、３バイト目と次の１バイトをセットで１文字と誤認させることができます。これにより、HTMLの区切り文字の効力を失わせてスクリプトを注入することが可能です。 例："あ" = E3 81 82 なので、シフトJISと誤認すると "縺" (E381) +余分な先行バイトの 0x82 具体例 例えば、動的なコンテンツ（UTF-8で応答を生成） <html> <head> <title>abcde</title> </head> <body> <form> <input type=text value="ユー
-
第6回 先行バイトの埋め込み | gihyo.jp
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
-
エンコーディング検出ライブラリ「encdet」をリリース - spiritlooseのはてなダイアリー
さて、久しぶりなわけですが。 タイトルの通りリリースしました。 http://wiki.github.com/spiritloose/encdet http://github.com/spiritloose/encdet/tree/master Mozillaの「Mozilla Universal Charset Detector」というやつのCバインディングです。 MozillaのMercurialリポジトリからコピってきて、Cのインターフェースをつけてautotools化してみました。 http://www.void.in/wiki/Universalchardet っていうのもあったんですが、本家の方が結構変わってたり、 autotools化したかったり、もろもろあったので作りました。 今のところ LinuxとFreeBSDで動作確認してます。 #include <encdet.h>
-
文字コード polyglot - 葉っぱ日記
IE限定。外から指定されるcharsetに応じて挙動を変えるJavaScriptの関数の実装例。以下のコードを Shift_JIS として例えば charset.js のような名前で保存する。 function detectCharSet() { try{ var ADE = 'ｱｱ'; // 0xB1 x2 if(+ADE-0 == 10 ){ return 'UTF-7'; } if( ADE == 11 ){ return 'US-ASCII'; // 0xB1 means 0x31 } if( ADE.charCodeAt(0) == 0xFF71 ){ return 'Shift_JIS'; // Halfwidth Katakana Letter A x2 } if( ADE.charCodeAt(0) == 0x81FC ){ return 'EUC-JP'; // 0xB1
-
-
第2回 UTF-7によるクロスサイトスクリプティング攻撃［後編］ | gihyo.jp
前回に引き続き、UTF-7によるクロスサイトスクリプティング（XSS）について説明していきます。 UTF-7によるXSSは、攻撃対象のコンテンツの文字エンコーディングが不明瞭な場合に、そのコンテンツを被害者のブラウザ（Internet Explorer）で開いたときに、そのコンテンツの文字エンコーディングがUTF-7であるとIEに誤認させ、「+ADw-script+AD4-」のようなUTF-7の文字列が有効なHTML要素として認識されるために発生します。 そして、「文字エンコーディングが不明瞭」な具体的な状況として、以下のような条件のいずれかに該当するということを前回説明しました。 レスポンスヘッダ、meta要素のどちらでもcharsetが指定されていない charsetにIEが解釈できないエンコーディング名が指定されている meta要素でcharsetを指定しているときに、meta要
-
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
-
絵文字が開いてしまった「パンドラの箱」第1回--日本の携帯電話キャリアが選んだ道
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに？そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな！ 8割の女性は「恋人以外にも使う」』（RBB NAVI）なんていうニュースもありました。携帯電話の個人普及率が9割を上回る（平成20年内閣府消費動向調査）この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
-
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
-
文字化けクイズ(問題編) - 西尾泰和のはてなダイアリー
みんな安易に「文字化けした！」って言うけど、いろいろ雰囲気の違う文字化けがあるじゃないの、というわけで5問ほどクイズにしてみた Q1(初級): 「こんにちは、世界」と表示されるはずなのになぜか「縺薙」などの難しい漢字が表示された。何が起きたか。 Q2(初級): 「こんにちは、世界」と表示されるはずなのになぜか「ã」(aの上に~)などが表示された。何が起きたか。 Q3(中級): ブラウザであるリンクをクリックしたところ「臼NG」で始まる謎の文字列が表示された。何が起きたか。 Q4(上級): 「こんにちは」と表示されるはずなのになぜか「S?kao」と表示された。何が起きたか。 Q5(上級): 「ファイルが見つかりません」と表示されるはずなのになぜか斜め四角に囲まれた疑問符などが表示された。何が起きたか。なお参考までに表示された文字列は20文字であり、表示されたウェブページのエンコーディングはu
-
第5回■注目される文字コードのセキュリティ問題
今回から5回にわたって，アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか，疑問に思うかもしれないが，Webアプリケーションで文字コードを指定可能な個所は非常に多く，しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている（図1）。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では，ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して，文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは，セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう
-
cmd.exeとchcp.comだけで、文字コード(Unicode、UTF-8、UTF-7、JIS、EUC-JP、SJIS)を変換する！ - Windows Script Programming
cmd.exeとchcp.comだけで、文字コード(Unicode、UTF-8、UTF-7、JIS、EUC-JP、SJIS)を変換する！ Unicode、UTF-8、UTF-7、JIS、EUC-JP、SJISなどの文字コードがcmd.exeとchcp.comだけで変換できます。 Unicode → 各種文字コード UTF-7.cmd Unicodeファイル UTF-7ファイル start /min /wait cmd /c chcp.com 65000 ^& cmd /c type %1 ^>%2 UTF-8.cmd Unicodeファイル UTF-8ファイル start /min /wait cmd /c chcp.com 65001 ^& cmd /c type %1 ^>%2 JIS.cmd Unicodeファイル JISファイル start /min /wait cmd /c ch
-
出力をホワイトリストで処理することを真剣に考えてみる | 水無月ばけらのえび日記
第02回まっちゃ445の懇親会の帰りに考えていた事なのですが、メモし忘れていたのであらためて。 HTMLの中に変数を出力する際、何も考えずに文字列をそのまま出力すると、HTMLのマークとみなされる文字が含まれていた場合にまずいことが起こります。たとえば#PCDATAの中に出力する場合、「<」や「&」がそれぞれSTAGOやEROとして解釈されますので、これらをそのまま出力しないようにする必要があります。以下のように文字実体参照に置き換えるのが一般的です。 < → <& → &同様に、二重引用符で括られた属性値リテラルに出力する場合は「"」と「&」がマークとして解釈されます。XHTMLの場合は「<」も書けないことになっていますので、これも置き換える必要があります。 " → "< → <& → &※#PCDATAの中で「"」を変換しても問題は起きないので、多
-
UTF-8小話 - Plan9日記
UTF-8はWikipediaに書かれている通り、 当初は、Plan 9で用いるエンコードとしてベル研究所で考案された。 ものだけど、最近古本屋で見つけた「インターネットヒストリー」の村井純先生のあとがきに気になる記述があった。 ちょっと長くなるけど引用する。 かなり昔の話だが、ベル研のUNIXを作ったオペレーティングシステムを担当していたグループにオペレーティングシステムについての講演を頼まれたときに「日本語」の話をしたことがある。正直にいうと、ケン・トンプソンやデニスリッチなど、コンピュータ界のノーベル賞といわれるチューリング賞をとった錚々たるメンバーを前にして、当時「ただの研究者」であった自分がオペレーティングシステムについて何を話したらよいのだろうと悩んでしまった。結局開き直って話すことにしたのが漢字の問題だったわけだ。しかし、このときの講演の内容が、彼らにとっては1バイト1文字と
-
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました