第19回 文字エンコーディングとセキュリティ（1） | gihyo.jp
文字エンコーディングを正しく、厳格に取り扱わないと、システムのセキュリティに大きく影響します。しかし、広く利用されているアプリケーションでも、大手サイトでも文字エンコーディングを不適切に取り扱っているケースは少なくありません。 今回から4回に分けて、セキュリティと文字エンコーディングをテーマに、Webアプリケーションがどのようなセキュリティ対策を取るべきか解説します。攻撃方法の解説ではないので具体的な攻撃方法は解説しませんが、どのように攻撃されるのかは簡単に解説します。 文字エンコーディングは厳格に扱わなければならない 問題の解説を始める前ですが、いきなり結論から入ります。それは、非常に簡単な原則であるにも関わらず、あまり多くのサイトやアプリケーションで守られていないからです。 文字エンコーディング取り扱いの原則文字エンコーディングは厳格に取り扱い、不正な文字エンコーディングを検出した場合
IEにおけるEUC-JPの処理方法でShift_JISがからんでくる件 - hoshikuzu | star_dust の書斎
http://d.hatena.ne.jp/hoshikuzu/20071018#p1 の続編。（私の中ではこちらを先に気がついたのですけれど。） Fileを読めるADODB.Streamを使って検証してみようというオハナシです。 16進の[0x8FD9EA59]というデータをもったテキストファイルを作成し、ローカルに保存します。これをADODB.streamで読ませます。読ませるにあたって、バイナリではなくテキストモードとし、エンコードを、EUC-JPとして指定したり、Shift_JISとして指定したりして、読みこんだ結果、ADODB.streamがそれを、どんなUnicodeとして解釈しているかを見ようというわけです。 Shift_JISとして読ませますと次のようになります。 [0x8FD9EA59]を、[0x8FD9]+[0xEA59]として２バイトずつに区切って理解し、Shift_
火星に到着したスピリッツの探索機が密かに仕組まれたバックドアのおかげで息を吹き返したオハナシ
素敵だ・・・ 火星着陸時の衝撃で地上探索機搭載のコンピュータのフラッシュメモリのファイルシステムが壊れたのでOS再起動の永遠の繰り返しになってしまった。起動するとフラッシュメモリのエラー検知をして再起動・・・。地球からのコマンド送信しての通常の初期化起動も無効になるし万が一のための最低限モードによる起動指示もきかない。対策のために何日も全スタッフは24時間苦しんだんだって。ところで起動ってエネルギー食べちゃうんだよね。起動直後にそれまでの活動履歴を地球に送信する仕組みなんだけど電波出し始めて履歴がはいっているフラッシュメモリの中身を検索すると落ちる。これの繰り返し。クソデータにみちた電波のたれながしが繰り返されてエネルギーが減っていく・・・そうこうしているうちに太陽光による発電とバッテリーとのつりあいがとれなくなってエネルギーの完全な不足になり瀕死状態に。極寒の夜がくれば耐えられないかもし
CERT/CC Vulnerability Note VU#739224
HTTP content scanning systems full-width/half-width Unicode encoding bypass Vulnerability Note VU#739224 Original Release Date: 2007-05-14 | Last Revised: 2009-04-22 Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded traffic. This may allow malicious HTTP traffic to bypass content scanning systems. Full-width and half-width encoding is a technique for
未知のぜい弱性を発見した。どーすんの！？オレ（その1）
いきなり質問です。未知のぜい弱性を発見したら皆さんはどうしますか？ 自分が未知のぜい弱性を発見することは無いと思われているかもしれませんが，じつは身近に存在しているのに今は気付いていないだけかもしれません。皆さんがぜい弱性を発見して報告する日は近いかもしれませんので，今回は私の経験を基にぜい弱性を発見したらどうするかについて書きたいと思います。 私は今までに何件かぜい弱性を発見して，ソフトウエアの開発元に報告したことがあります。最近では「MS06-053」（http://www.microsoft.com/japan/technet/security/bulletin/ms06-053.mspx）で修正されたぜい弱性を報告しました。まずは，このぜい弱性の発見から報告までの流れを説明しましょう。 2005年12月に「www.google.comにクロスサイト・スクリプティングのぜい弱性，米W
Winnyネットワークはやっぱり真っ黒，NTTコミュニケーションズの小山氏に聞く：ITpro
ボットネット研究で知られるNTTコミュニケーションズの小山覚氏。小山氏の新しい研究対象は「Winnyネットワークの実態」だ。小山氏は「悪意のある人物がワームを撒き散らしているWinnyネットワークは『真っ黒』としか言いようがない」と指摘する。小山氏にWinnyネットワークに関する最新事情を聞いた（聞き手は中田 敦＝ITpro）。 小山さんは最近，Winnyネットワークの調査を始められているそうですね。 これは，4月25日の「RSA Conference 2007」で話そうと思っていた内容なのですが，私が出るセッションは，ラックの新井悠さん，JPCERTの伊藤友里恵さん，マイクロソフトの奥天陽司さんというセキュリティ界の論客が揃ったパネル・ディスカッションなので（モデレータは日経パソコン副編集長の勝村幸博），私だけが長い時間発表するのは無理そうです（笑）。そこで，今回のインタビューで全部お話
まだまだあるクロスサイト・スクリプティング攻撃法
前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
US-ASCIIの最上位ビットを無視するOutlookの仕様により、ウイルスゲートウエイをすり抜けて侵入してしまう問題（はせがわさん指摘）にTrendmicroが対応してくれました（was InterScan Messaging Security Suite 5.11 Linux版 Patch 6(Build_1215)の概要および適用方法 - ripjyr's blog
(セキュメモ経由) id:hasegawayosukeさん、kjm先生ここですよ！！！注目点は！！！ InterScan(TM) Messaging Security Suite 5.11 Linux版 Patch 6 Readme (ビルド12150) 19. 添付ファイルをUUENCODE化した文字列の最上位ビットをオンに設定した場合、 InterScan MSSがこのファイルをデコードできない問題 Outlook Expressは添付ファイルをUUENCODE化した文字列の最上位ビットを無視 するため、このような場合でも添付ファイルをデコードできます。 本Patchの適用後は、InterScan MSSが最上位ビットを正しくデコードして、 このような添付ファイルを正常に処理できるようになります。 経緯 この件は、http://matcha139.hiemalis.org/hiki/?
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TinyURL.com - shorten that long URL into a tiny URL
http://edocs.beasys.co.jp/e-docs/wls/docs92/ja/relnotes_ja.html