UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
本当は怖い文字コードの話 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
［PostgreSQLウォッチ］第27回 SQLインジェクション脆弱性を修正，日本語ユーザーに大きな影響
［PostgreSQLウォッチ］第27回 SQLインジェクション脆弱性を修正，日本語ユーザーに大きな影響 SQLインジェクションに関する脆弱性の修正などを行ったPostgreSQL 8.1.4,8.0.8，7.4.13，7.3.15の各バージョンが，5月23日一斉にリリースされた（関連記事）。いずれも同じメジャーバージョン系列であれば，dump/restoreによるデータ移行なしでアップグレードできる(ただし，8.1，8.1.1から8.1.4への移行については注意が必要。詳細は付属のリリースノートを参照されたい)。 修正が提供されないPostgreSQL 7.2以前のバージョン 今回対策された脆弱性はPostgreSQL 7.2以前にも存在するが，開発者のポリシーにより，7.2以前はサポートの対象になっていない。いまだに7.2 以前のバージョンを使っているユーザーは，7.3以降にアップグレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
