パスワードを忘れた? アカウント作成
13905385 story
バグ

ゆうちょPayアプリで「々」が含まれる氏名の登録が行えない不具合 94

ストーリー by hylom
「々」は漢字ではない罠 部門より
あるAnonymous Coward曰く、

ゆうちょ銀行が5月8日よりサービスを開始したスマートフォン決済サービス「ゆうちょペイ」だが(CNET Japan)、アプリでのアカウント作成時に名字として「佐々木」を入力するとアカウントを作成できないというトラブルが発生していたとのこと(ITmedia)。

「ひらがな、カタカナ、漢字、アルファベットのみ入力してください」というエラーメッセージが出るとのことで、どうやら「々」を「ひらがな、カタカナ、漢字、アルファベット」として認識していなかったのが問題のようだ。すでにアプリのアップデートで改修されているという。

  • by Ponta2 (47202) on 2019年05月10日 15時00分 (#3612315)
    「々」だけは受け付けるように改修して、「みすゞ」なんかはまだ弾いているかも。
    ここに返信
  • by headless (41064) on 2019年05月10日 23時52分 (#3612720)
    スラドではページ上部の検索ボックスで「々」を検索 [srad.jp]すると何もヒットしません。「佐々木」を検索 [srad.jp]した場合、「佐 木」の検索 [srad.jp]と(たぶん)同じ結果が返ります。「佐+木」を検索 [srad.jp]すると「佐々木」と「佐佐木」(など)にヒットします。ストーリー検索機能 [srad.jp]では「々」も認識される [srad.jp]ようです。
    ここに返信
  • 確かに踊り字は「ひらがな、カタカナ、漢字、アルファベット」ではないけど・・・。

    ここに返信
    • by Anonymous Coward

      ルールからすれば「佐佐木」としておけばよかった、とは言えなくもないですね。
      この場合情報処理的にはともかく、法的にどう扱われるのかはちょっと気になる。

    • by Anonymous Coward

      踊る人形

    • by Anonymous Coward

      Twitterが日本語ハッシュタグを導入した時も長音符が使えない仕様だったな

  • by Anonymous Coward on 2019年05月10日 14時50分 (#3612303)
    絵文字でも何でも受けつければいいのに😛
    ここに返信
    • by Anonymous Coward on 2019年05月10日 14時54分 (#3612309)

      実際にシステム組めばなんでかわかるよ。

      • by Anonymous Coward

        わいはいくつものシステムを組んで来た自営業だが
        外部システムとの連携や、フォントが乏しい環境での印字が絡む分は分かるんだが
        そうでないのに文字を制限したがるのは未だによく分からぬ。

        • フィールドに何を受け付けるのかは、外注業者が理由をアレコレしても仕方ないでしょ
          それはお客の都合で決まるもの。これはマスターデータだろうし、どう使うかわからんから
          綺麗にしておきたいという心理は理解できる。

          でもたぶん、この場合はUnicodeの漢字の範囲コードポイント表に「々」が入ってないからでは。
          正規表現でコード指定で漢字ひっかけるときのあるあるでしょ。

    • ก็็็็็็็็็็็็็ʕ•͡ᴥ•ʔ ก้้้้้้้้้้้  とか使われてもいいの?

      アカウント名が送金相手などにも表示される場合、欄から文字がはみ出て表示されて相手に不快感を与えたり、
      表示がバグったと勘違いさせたり、場合によっては重要な表示を上書きしてしまうことができるんですが。

      Unicodeの特殊文字を使わせることはある意味脆弱性のようなものなので使用可能文字を制限するのは妥当な設計です。

    • by Anonymous Coward

      文字のコードやそのエンコードって知ってるかい?
      「なんで制限するのか」「絵文字でも受け付ければいい」って発想は「この世にはスマホしか無い、かつアイフォンしかしらない」みたいな人の発想に見えちゃうよ。

      • by Anonymous Coward on 2019年05月10日 15時07分 (#3612323)

        このサービスは実際にゆうちょ口座がある人向けなので、既に登録されている名前と不一致なら、サービスは受けられず、先には進まない(と思う、試してないけど、常識的にそうなっていると信じる)。
        なので、入力画面でコード制限してもあまり意味はない(サーバ負荷とかは関係あるかも)。するなら、「ゆうちょシステムで登録できる文字コード」と完全に同じ条件にしないとエラー条件が増えて、こういう余計なバグの要因になる、と思います。

        • by Anonymous Coward on 2019年05月10日 15時36分 (#3612359)

          > 既に登録されている名前と不一致なら、サービスは受けられず
          ・同じ文字に見えても、実は文字コードが違う(令和の時に話題になったように)
          ・普段は省略形の文字だけど、実はゆうちょ側は難しい字で登録されていて、合わない
          とか罠はいっぱいありそうだけど。

      • そういう話はWindowsとInternet Explorerに限定されたサービスが完全に消滅してからするのだ!!!

      • by Anonymous Coward
        ゆうちょペイってスマフォ専用のアプリちゃうん?
      • by Anonymous Coward

        馬鹿な開発者はまともなバリデーションを知らないからね、仕方ないね

        実際のところ絵文字を使えたっていいんだが、脆弱性を作り込むよりはホワイトリスト方式で安全に行こうという下請けのレベルに合わせた設計をすることになる。

        • by Anonymous Coward

          あんた、典型的な実装を知らない自称設計者でしょ。

          「技術を知らなくても設計はできる。
          オレの設計を実装できないのは、絶対に下請けの奴らの技術力のせい!オレは悪くない!」

          いったいどんだけのそういう糞設計者を見た事か。

    • by Anonymous Coward

      やってみろ
      SQLインジェクション等されまくって
      個人情報ダダ漏れになって
      簡単に死ねるから

      • by Anonymous Coward on 2019年05月10日 15時17分 (#3612338)
        やっぱりそれか
        SQLとして意味のある記号をエスケープすればいいだけなのに、SQLとして意味がある記号が何か分からない(ドキュメント見れば全部書いてあるのに!)から手当たり次第に制限してんだよね。
        そんなカーゴカルトプログラミング手法で本当に危険な記号を排除できてるとどうして信じられるんだろう・・・
        • by Anonymous Coward on 2019年05月10日 15時33分 (#3612355)

          「佐々木」の入力すら想定できない開発者が、SQLのドキュメントに基づいて適切にエスケープできるわけないじゃん

        • by Anonymous Coward

          全部を監督できる環境ならいいけど、他システムからの入力だのがあって文字コード変換や予期しないサロゲートペアだのが放り込まれて、エスケープしたつもりがU+00A5を通しちゃいましたとかなるからだろ

          • by Anonymous Coward on 2019年05月10日 15時42分 (#3612370)

            他システムからの入力をエスケープできない段階でアプリ関係なくアウトなのでは

            • by Anonymous Coward

              クライアント側に緩和策入れて「直叩き対策は?」って聞くと「アプリの改変は規約違反だから起こらない」とか意味不明の言い訳するやついるよね

          • by Anonymous Coward

            サーバで落とせや!!!!!!!1

        • by Anonymous Coward

          > 意味のある記号をエスケープすればいいだけ
          いやぁ、『々』を見落としちゃう現場ですよ?
          「すればいいだけ」なんて言ってると絶対にまた見落としが出ます。

          というか、意味のある記号だけエスケープって、文字列のデータしか考慮してないですか?
          数値を埋め込むべきところにandとか通常の英字をぶち込まれるのは考慮しないつもりなんですか?
          全部文字列データとして渡せば解決と思ってますか?暗黙の型変換でもっと色々死ねますよ?

          • by Anonymous Coward on 2019年05月10日 16時00分 (#3612401)

            SQLインジェクション対策に入力文字制限とか普通しないって。
            かな英数字ならともかく、漢字の範囲なんか簡単にはできないでしょ。
            これアプリのレビュー見ると散々だよ?
            この問題だけじゃなく至る所でやらかしてる感じだよ。
            どんな開発会社に頼んだんだよ。

        • by Anonymous Coward

          そういうSQLエスケープ処理は、データベース製品についてくるライブラリの仕事じゃないの。
          暗号処理と一緒。

          え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。

      • by Anonymous Coward

        今どきweb設計するときにHTMLタグエスケープしないだの、SQL place holder使わないだのなんてありえないでしょ。
        だからこそ文字種制限に意味あるのかと感じるんだけど。

      • by Anonymous Coward

        会社で10年以上運用してるシステムも絵文字でもなんでも受け付ける仕様なんだけどダメなかな?
        プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…

        • by Anonymous Coward on 2019年05月10日 16時28分 (#3612433)

          > プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…

          それで正しいですよ。
          むしろ「文字種制限しないと SQL Injection や XSS の危険があるようなシステム」の方がはるかに危ないです。
          プレースホルダーとか適切なフレームワークを使ってないっていう意味ですからね。

    • by Anonymous Coward

      アラビア語とか文字方向が違う文字入力されてレイアウトが崩れたり、変な装飾文字を入力されて脆弱性をつかれたりとか、ほんといろいろある。

      入力できる文字をホワイトリストで限定したいというのはわからんでもない。

  • by Anonymous Coward on 2019年05月10日 14時56分 (#3612312)

    RFC5322は人類には早すぎたんだ……

    ここに返信
  • by Anonymous Coward on 2019年05月10日 15時13分 (#3612332)

    漢字の定義が何かはともかく。
    なんでも受け付ければいいとか最初にやらかしちゃって、
    後で取り返しのつかない文字が登録されちゃったりするよりよほどいい(ポジティブ思考)。

    ここに返信
    • by Anonymous Coward

      J-Phone のメールアドレスの話を思い出した

  • by Anonymous Coward on 2019年05月10日 15時23分 (#3612344)

    とかしないの?
    関係者に佐々木さんいなかったの?

    ここに返信
  • by Anonymous Coward on 2019年05月10日 15時38分 (#3612362)

    すべてバイト列として評価しよう

    ここに返信
    • by Anonymous Coward

      夏の夕暮れに海鳥たちだけが迎えてくれるのですね

      #それはバイド

typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者

読み込み中...