不正な文字列をどこでチェックすべきか - 岩本隆史の日記帳（アーカイブ）
大垣さんの書かれた： 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 何故かあたり前にならない文字エンコーディングバリデーション – yohgaki's blog という警告には同意なのですが、対策の一番手に「全ての入力文字列の文字エンコーディングをバリデーションする」が挙げられているのに違和感を覚えます。入力時のバリデーションは、あくまで保険的な対策でしかないのではないでしょうか。 この文脈において、XSSが起きるのは、不正なバイト列や冗長なUTF-8表現がHTML中に出力されるためでしょう。そうならば、不正な文字列がHTMLに出力されそうになった段
RESTクライアントが知っているべきこと - 岩本隆史の日記帳（アーカイブ）
クライアントとサーバの密結合を避けられるのが、RESTスタイルに従って得られるメリットのひとつです。クライアントが、アプリケーションの挙動に関する知識をほとんど持たなくてよいわけです。 とはいっても、まったく何も知らないではクライアントたりえません。では、何を知っていればよいのでしょうか。 知っているべき4点 その答えは、Roy T. Fielding による記事「REST APIs must be hypertext-driven」で、すでに示されています。下記の4つです。 通信プロトコル（communication protocol） 初期URI（initial URI） メディアタイプ（media types） リンク関係（link relations） AtomPubを例にとると分かりやすいでしょう。 通信プロトコル＝HTTP 初期URI＝サービス文書のURI メディアタイプ＝「a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
