パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

iOSベータ版に「肌の色を指定できる」絵文字が登場」記事へのコメント

  • ด้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้ (・ω・) ด็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็. ← Unicode 合字 の例 (IE で表示すると、本来のコメント欄の領域を多少はみ出して他の情報に重なります)

    Unicode は複雑化されすぎて、普通のプログラマーが理解できる

    • by Anonymous Coward on 2015年02月25日 23時17分 (#2767735)

      >普通のプログラマーが理解できる範疇を超えているように思えます。

      普通のプログラマーが変換以外でコード体系を意識しなきゃいけないことって、現代ではそうそう無くね? 文字が表示できず画面が崩れるのはOSや処理系の問題であって、プログラマーがいちいち意識しなければいけないというのはおかしいでしょう。

      親コメント
      • 普通のプログラマーが変換以外でコード体系を意識しなきゃいけないことって、現代ではそうそう無くね? 文字が表示できず画面が崩れるのはOSや処理系の問題であって、プログラマーがいちいち意識しなければいけないというのはおかしいでしょう。

        確かにおっしゃる通り、文字エンコーディングの validation をしなくても脆弱性にならないのが本来の姿ですが、現状はそうではありません。文字コードの脆弱性はこの3年間でどの程度対策されたか? [slideshare.net] をお読みいただければ分かるように、昔に比べるとプラットフォーム側での整備が進み安全性が強化されつつありますが、完璧とは言えない現状があります。

        所謂マルチバイトXSSに対してはプラットフォーム側での対策がだいぶ進みましたが、Unicode の特殊文字や制御コードによるサービス拒否攻撃防止のための対策は全く進んでいません。特定のUnicode特殊文字・制御文字を送ると受信した側のLINEがフリーズ・起動不能になる現象については、そもそも iOS の Unicode の実装に問題があることが根本的な問題(Android については特殊な文字はそもそも対応していないので問題は発生していない)です。しかし、Apple は iOS の既存の Unicode の問題の修正もまともにせず、更に Unicode を複雑化させ問題を深刻化させたいようですから、アプリ側での validation を強化するしかないのではないでしょうか。

        具体的には、ユーザーから送信されるデータを受け付ける際に、コード順ブロック一覧 [wikipedia.org] の中の特定の範囲のコードのみを受け付けて他はエラーにするなど。

        --

        別コメントにするほどではないので、ここについでに書いてしまいますが、 #2767675 の 「PHP の制御コード等を適切に validation」 は 「Unicode の制御コード等を適切に validation」 の誤りでした。

        親コメント

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

処理中...