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

ゆうちょPayアプリで「々」が含まれる氏名の登録が行えない不具合」記事へのコメント

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

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

      親コメント
      • by Anonymous Coward

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

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

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

          親コメント
        • by Anonymous Coward

          そりゃ同じような仕事しかしとらんからだよ
          外部連携も印刷機能もなくても文字制限したい場合なんていくらでも想像できるでしょ
          文字を制限しないということは全言語(文字)の入力(表示)に対応したシステム作るのと同じことよ?

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

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

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

      親コメント
      • by Anonymous Coward

        端末をクラッシュさせることもできる。そうiPhoneならね!

        • by Anonymous Coward

          プレステ「再起動すれば直るんでしょ。大したことないって。」

      • by Anonymous Coward

        もっとこう上手い例えあるだろ、ホモグラフ攻撃とかRTLによる口座番号の偽装とかさぁ……

    • by Anonymous Coward

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

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

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

        親コメント
        • by Anonymous Coward on 2019年05月10日 15時36分 (#3612359)

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

          親コメント
        • by Anonymous Coward

          >入力画面でコード制限してもあまり意味はない
          そしてサニタイズすらされずSQLインジェクションを起こすと。

          • by Anonymous Coward

            SQLインジェクション対策でサニタイズwww
            それ自分で書くの??

          • by Anonymous Coward

            今どきサニタイズ言う人って…

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

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

          入力された名前はサーバ側のデータベースに登録され、スマホ以外の別のシステムで閲覧や印字されたりするかもしれんやろ?

      • by Anonymous Coward

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

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

        • by Anonymous Coward

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

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

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

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

            理論的に反論できないと、すぐそうやって自分の経験を感情的に他人に押し付けるんだから、もう

            親コメント
          • by Anonymous Coward

            建築ならば、設計、施工、検査がそれぞれ独立した第三者なのは当然でしょ。
            だからITの世界は、インダストリーとして遅れているのよ。テスターすら雇おうとしない。

            • いまだに、ITの世界が建築を目指していると思っているの?

              親コメント
              • クリエイティビティなんて関係ない。

                単に、条件が違うので机上の空論だと言っているだけですが。

                建設のように設計通りにできたプログラムなんて見たことがありますか?

                砂上の楼閣をわざわざ大金かけて購入しようとは、
                さすが金融屋さんは剛毅ですねえ。
                冒険心にあふれています。

                親コメント
            • by Anonymous Coward

              フルスタックエンジニア(๑• ̀д•́ )✧+°ドヤッ

              まぁ、ITはデジタルでソフトで、コピー簡単だしお金かからないでしょ、と一般に認知されてるから
              建築のようにまともな予算つけてもらえない、っていうのがあるんじゃ。

            • by Anonymous Coward

              残念、ITは建築ではありません。
              設計図から家が何万コピーも自動生成できるようになったらまた来てください。

              • by Anonymous Coward

                ハウスメーカー住宅の場合、工場において汎用パッケージがすでに作ってあって、現場ではそれを組み立てるのが仕事だよ。
                いわゆるミドルウエア。

                SQLエスケープ処理とかも、まさにミドルウェアの仕事でしょ。
                なんで現場の開発者が、自分でエスケープ処理を書いているの?

    • 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

            ヒント:Prepared Statement

            DBプログラミングやったことないと知らないかもだけど、もはや基本テクニックの一つ。
            #車輪の再発明を避けるってのはこういうことだ。、

        • by Anonymous Coward

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

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

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

            親コメント
            • by Anonymous Coward

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

            • by Anonymous Coward

              社内の端末の専用アプリからしか入力がないエスケープが必要がなかったシステムに、スマホからユーザが入力した文字列が入ってくるようになったとき、エスケープ処理を追加するより、ホワイトリストで許されるものしか通さないようにするほうが楽じゃね?

              • by Anonymous Coward on 2019年05月10日 18時37分 (#3612523)

                って思うじゃん? いや、確かに楽だよ。楽だけどさ、結局今回のような問題が発生するわけで。

                ホワイトリスト制限するのは自由だけど、だからといってエスケープ処理をしなくていいという考えは危険だと思うよ。

                親コメント
          • 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

            上の方でサニタイズ言ってる人たちがそれに当たりそうで怖い・・・w

          • by Anonymous Coward

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

            いや、本当にそう
            でも、自分で書こうとする人が後を絶たない
            知らないだけなんだろうけど

      • by Anonymous Coward

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

        • 実際コードを書いていないシステムエンジニアやセキュリティエンジニアの方は知らないでしょうが、
          複雑なシステムではプレースホルダは非現実的で、バグの温床になりますよ。

          そういう人から、プレースホルダ使えと言われると、現場はいい迷惑です。
          現実的に考えて 価格.com のスペック検索 [kakaku.com] をプレースホルダで作れますか?

          理論上不可能ではありませんが、場合分けでif文等が数十重にもなって、訳がわからないことになり、製作時間も数十倍、バグ発生リスクも数十倍になるでしょうね。

          あと、プレースホルダ使えばSQLインジェクションが理論上絶対に発生しないといった出鱈目をまき散らしているセキュリティの専門家も多くいらっしゃ

          • by Anonymous Coward

            おいおい、ユーザにデータベースやテーブル名を指定させるのかww?
            まず設計を見直そうな。

            そもそも、バリデーションとエスケープは別の概念だぞ。

          • by Anonymous Coward

            > 価格.com のスペック検索

            似たようなもの作ったことあるけどさ、
             conds = []
             conds << [" COLOR = ?" , foo]
             conds << [" SIZE = ?" , bar]
            みたいに投入していって、
             conds.map{ |v| v.first ].join(" AND ")
            と取り出せばいいだけじゃないかな。

      • by Anonymous Coward

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

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

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

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

          親コメント
      • by Anonymous Coward

        特許庁もこのレベルの連中がやってんだろうなあ

    • by Anonymous Coward

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

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

アレゲは一日にしてならず -- アレゲ見習い

処理中...