アカウント名:
パスワード:
実際にシステム組めばなんでかわかるよ。
わいはいくつものシステムを組んで来た自営業だが外部システムとの連携や、フォントが乏しい環境での印字が絡む分は分かるんだがそうでないのに文字を制限したがるのは未だによく分からぬ。
フィールドに何を受け付けるのかは、外注業者が理由をアレコレしても仕方ないでしょそれはお客の都合で決まるもの。これはマスターデータだろうし、どう使うかわからんから綺麗にしておきたいという心理は理解できる。
でもたぶん、この場合はUnicodeの漢字の範囲コードポイント表に「々」が入ってないからでは。正規表現でコード指定で漢字ひっかけるときのあるあるでしょ。
そりゃ同じような仕事しかしとらんからだよ外部連携も印刷機能もなくても文字制限したい場合なんていくらでも想像できるでしょ文字を制限しないということは全言語(文字)の入力(表示)に対応したシステム作るのと同じことよ?
ก็็็็็็็็็็็็็ʕ•͡ᴥ•ʔ ก้้้้้้้้้้้ とか使われてもいいの?
アカウント名が送金相手などにも表示される場合、欄から文字がはみ出て表示されて相手に不快感を与えたり、表示がバグったと勘違いさせたり、場合によっては重要な表示を上書きしてしまうことができるんですが。
Unicodeの特殊文字を使わせることはある意味脆弱性のようなものなので使用可能文字を制限するのは妥当な設計です。
端末をクラッシュさせることもできる。そうiPhoneならね!
プレステ「再起動すれば直るんでしょ。大したことないって。」
もっとこう上手い例えあるだろ、ホモグラフ攻撃とかRTLによる口座番号の偽装とかさぁ……
文字のコードやそのエンコードって知ってるかい?「なんで制限するのか」「絵文字でも受け付ければいい」って発想は「この世にはスマホしか無い、かつアイフォンしかしらない」みたいな人の発想に見えちゃうよ。
このサービスは実際にゆうちょ口座がある人向けなので、既に登録されている名前と不一致なら、サービスは受けられず、先には進まない(と思う、試してないけど、常識的にそうなっていると信じる)。なので、入力画面でコード制限してもあまり意味はない(サーバ負荷とかは関係あるかも)。するなら、「ゆうちょシステムで登録できる文字コード」と完全に同じ条件にしないとエラー条件が増えて、こういう余計なバグの要因になる、と思います。
> 既に登録されている名前と不一致なら、サービスは受けられず・同じ文字に見えても、実は文字コードが違う(令和の時に話題になったように)・普段は省略形の文字だけど、実はゆうちょ側は難しい字で登録されていて、合わないとか罠はいっぱいありそうだけど。
>入力画面でコード制限してもあまり意味はないそしてサニタイズすらされずSQLインジェクションを起こすと。
SQLインジェクション対策でサニタイズwwwそれ自分で書くの??
今どきサニタイズ言う人って…
そういう話はWindowsとInternet Explorerに限定されたサービスが完全に消滅してからするのだ!!!
入力された名前はサーバ側のデータベースに登録され、スマホ以外の別のシステムで閲覧や印字されたりするかもしれんやろ?
馬鹿な開発者はまともなバリデーションを知らないからね、仕方ないね
実際のところ絵文字を使えたっていいんだが、脆弱性を作り込むよりはホワイトリスト方式で安全に行こうという下請けのレベルに合わせた設計をすることになる。
あんた、典型的な実装を知らない自称設計者でしょ。
「技術を知らなくても設計はできる。オレの設計を実装できないのは、絶対に下請けの奴らの技術力のせい!オレは悪くない!」
いったいどんだけのそういう糞設計者を見た事か。
理論的に反論できないと、すぐそうやって自分の経験を感情的に他人に押し付けるんだから、もう
建築ならば、設計、施工、検査がそれぞれ独立した第三者なのは当然でしょ。だからITの世界は、インダストリーとして遅れているのよ。テスターすら雇おうとしない。
いまだに、ITの世界が建築を目指していると思っているの?
クリエイティビティなんて関係ない。
単に、条件が違うので机上の空論だと言っているだけですが。
建設のように設計通りにできたプログラムなんて見たことがありますか?
砂上の楼閣をわざわざ大金かけて購入しようとは、さすが金融屋さんは剛毅ですねえ。冒険心にあふれています。
フルスタックエンジニア(๑• ̀д•́ )✧+°ドヤッ
まぁ、ITはデジタルでソフトで、コピー簡単だしお金かからないでしょ、と一般に認知されてるから建築のようにまともな予算つけてもらえない、っていうのがあるんじゃ。
残念、ITは建築ではありません。設計図から家が何万コピーも自動生成できるようになったらまた来てください。
ハウスメーカー住宅の場合、工場において汎用パッケージがすでに作ってあって、現場ではそれを組み立てるのが仕事だよ。いわゆるミドルウエア。
SQLエスケープ処理とかも、まさにミドルウェアの仕事でしょ。なんで現場の開発者が、自分でエスケープ処理を書いているの?
やってみろSQLインジェクション等されまくって個人情報ダダ漏れになって簡単に死ねるから
「佐々木」の入力すら想定できない開発者が、SQLのドキュメントに基づいて適切にエスケープできるわけないじゃん
ヒント:Prepared Statement
DBプログラミングやったことないと知らないかもだけど、もはや基本テクニックの一つ。#車輪の再発明を避けるってのはこういうことだ。、
全部を監督できる環境ならいいけど、他システムからの入力だのがあって文字コード変換や予期しないサロゲートペアだのが放り込まれて、エスケープしたつもりがU+00A5を通しちゃいましたとかなるからだろ
他システムからの入力をエスケープできない段階でアプリ関係なくアウトなのでは
クライアント側に緩和策入れて「直叩き対策は?」って聞くと「アプリの改変は規約違反だから起こらない」とか意味不明の言い訳するやついるよね
社内の端末の専用アプリからしか入力がないエスケープが必要がなかったシステムに、スマホからユーザが入力した文字列が入ってくるようになったとき、エスケープ処理を追加するより、ホワイトリストで許されるものしか通さないようにするほうが楽じゃね?
って思うじゃん? いや、確かに楽だよ。楽だけどさ、結局今回のような問題が発生するわけで。
ホワイトリスト制限するのは自由だけど、だからといってエスケープ処理をしなくていいという考えは危険だと思うよ。
サーバで落とせや!!!!!!!1
> 意味のある記号をエスケープすればいいだけいやぁ、『々』を見落としちゃう現場ですよ?「すればいいだけ」なんて言ってると絶対にまた見落としが出ます。
というか、意味のある記号だけエスケープって、文字列のデータしか考慮してないですか?数値を埋め込むべきところにandとか通常の英字をぶち込まれるのは考慮しないつもりなんですか?全部文字列データとして渡せば解決と思ってますか?暗黙の型変換でもっと色々死ねますよ?
SQLインジェクション対策に入力文字制限とか普通しないって。かな英数字ならともかく、漢字の範囲なんか簡単にはできないでしょ。これアプリのレビュー見ると散々だよ?この問題だけじゃなく至る所でやらかしてる感じだよ。どんな開発会社に頼んだんだよ。
そういうSQLエスケープ処理は、データベース製品についてくるライブラリの仕事じゃないの。暗号処理と一緒。
え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。
上の方でサニタイズ言ってる人たちがそれに当たりそうで怖い・・・w
いや、本当にそうでも、自分で書こうとする人が後を絶たない知らないだけなんだろうけど
今どきweb設計するときにHTMLタグエスケープしないだの、SQL place holder使わないだのなんてありえないでしょ。だからこそ文字種制限に意味あるのかと感じるんだけど。
実際コードを書いていないシステムエンジニアやセキュリティエンジニアの方は知らないでしょうが、複雑なシステムではプレースホルダは非現実的で、バグの温床になりますよ。
そういう人から、プレースホルダ使えと言われると、現場はいい迷惑です。現実的に考えて 価格.com のスペック検索 [kakaku.com] をプレースホルダで作れますか?
理論上不可能ではありませんが、場合分けでif文等が数十重にもなって、訳がわからないことになり、製作時間も数十倍、バグ発生リスクも数十倍になるでしょうね。
あと、プレースホルダ使えばSQLインジェクションが理論上絶対に発生しないといった出鱈目をまき散らしているセキュリティの専門家も多くいらっしゃ
おいおい、ユーザにデータベースやテーブル名を指定させるのかww?まず設計を見直そうな。
そもそも、バリデーションとエスケープは別の概念だぞ。
> 価格.com のスペック検索
似たようなもの作ったことあるけどさ、 conds = [] conds << [" COLOR = ?" , foo] conds << [" SIZE = ?" , bar]みたいに投入していって、 conds.map{ |v| v.first ].join(" AND ")と取り出せばいいだけじゃないかな。
会社で10年以上運用してるシステムも絵文字でもなんでも受け付ける仕様なんだけどダメなかな?プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
> プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
それで正しいですよ。むしろ「文字種制限しないと SQL Injection や XSS の危険があるようなシステム」の方がはるかに危ないです。プレースホルダーとか適切なフレームワークを使ってないっていう意味ですからね。
特許庁もこのレベルの連中がやってんだろうなあ
アラビア語とか文字方向が違う文字入力されてレイアウトが崩れたり、変な装飾文字を入力されて脆弱性をつかれたりとか、ほんといろいろある。
入力できる文字をホワイトリストで限定したいというのはわからんでもない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
何で文字種制限しようとするのか (スコア:0)
Re:何で文字種制限しようとするのか (スコア:1)
実際にシステム組めばなんでかわかるよ。
Re: (スコア:0)
わいはいくつものシステムを組んで来た自営業だが
外部システムとの連携や、フォントが乏しい環境での印字が絡む分は分かるんだが
そうでないのに文字を制限したがるのは未だによく分からぬ。
Re:何で文字種制限しようとするのか (スコア:2)
フィールドに何を受け付けるのかは、外注業者が理由をアレコレしても仕方ないでしょ
それはお客の都合で決まるもの。これはマスターデータだろうし、どう使うかわからんから
綺麗にしておきたいという心理は理解できる。
でもたぶん、この場合はUnicodeの漢字の範囲コードポイント表に「々」が入ってないからでは。
正規表現でコード指定で漢字ひっかけるときのあるあるでしょ。
Re: (スコア:0)
そりゃ同じような仕事しかしとらんからだよ
外部連携も印刷機能もなくても文字制限したい場合なんていくらでも想像できるでしょ
文字を制限しないということは全言語(文字)の入力(表示)に対応したシステム作るのと同じことよ?
ก็็็็็็็็็็็็็ʕ•͡ᴥ•ʔ ก้้้้้้้้้้้ とか使われてもいいの (スコア:1)
ก็็็็็็็็็็็็็ʕ•͡ᴥ•ʔ ก้้้้้้้้้้้ とか使われてもいいの?
アカウント名が送金相手などにも表示される場合、欄から文字がはみ出て表示されて相手に不快感を与えたり、
表示がバグったと勘違いさせたり、場合によっては重要な表示を上書きしてしまうことができるんですが。
Unicodeの特殊文字を使わせることはある意味脆弱性のようなものなので使用可能文字を制限するのは妥当な設計です。
Re: (スコア:0)
端末をクラッシュさせることもできる。そうiPhoneならね!
Re: (スコア:0)
プレステ「再起動すれば直るんでしょ。大したことないって。」
別に構わないけど (スコア:0)
もっとこう上手い例えあるだろ、ホモグラフ攻撃とかRTLによる口座番号の偽装とかさぁ……
Re: (スコア:0)
文字のコードやそのエンコードって知ってるかい?
「なんで制限するのか」「絵文字でも受け付ければいい」って発想は「この世にはスマホしか無い、かつアイフォンしかしらない」みたいな人の発想に見えちゃうよ。
Re:何で文字種制限しようとするのか (スコア:1)
このサービスは実際にゆうちょ口座がある人向けなので、既に登録されている名前と不一致なら、サービスは受けられず、先には進まない(と思う、試してないけど、常識的にそうなっていると信じる)。
なので、入力画面でコード制限してもあまり意味はない(サーバ負荷とかは関係あるかも)。するなら、「ゆうちょシステムで登録できる文字コード」と完全に同じ条件にしないとエラー条件が増えて、こういう余計なバグの要因になる、と思います。
Re:何で文字種制限しようとするのか (スコア:1)
> 既に登録されている名前と不一致なら、サービスは受けられず
・同じ文字に見えても、実は文字コードが違う(令和の時に話題になったように)
・普段は省略形の文字だけど、実はゆうちょ側は難しい字で登録されていて、合わない
とか罠はいっぱいありそうだけど。
Re: (スコア:0)
>入力画面でコード制限してもあまり意味はない
そしてサニタイズすらされずSQLインジェクションを起こすと。
Re: (スコア:0)
SQLインジェクション対策でサニタイズwww
それ自分で書くの??
Re: (スコア:0)
今どきサニタイズ言う人って…
Re:何で文字種制限しようとするのか (スコア:1)
そういう話はWindowsとInternet Explorerに限定されたサービスが完全に消滅してからするのだ!!!
Re: (スコア:0)
Re: (スコア:0)
入力された名前はサーバ側のデータベースに登録され、スマホ以外の別のシステムで閲覧や印字されたりするかもしれんやろ?
Re: (スコア:0)
馬鹿な開発者はまともなバリデーションを知らないからね、仕方ないね
実際のところ絵文字を使えたっていいんだが、脆弱性を作り込むよりはホワイトリスト方式で安全に行こうという下請けのレベルに合わせた設計をすることになる。
Re: (スコア:0)
あんた、典型的な実装を知らない自称設計者でしょ。
「技術を知らなくても設計はできる。
オレの設計を実装できないのは、絶対に下請けの奴らの技術力のせい!オレは悪くない!」
いったいどんだけのそういう糞設計者を見た事か。
Re:何で文字種制限しようとするのか (スコア:1, すばらしい洞察)
理論的に反論できないと、すぐそうやって自分の経験を感情的に他人に押し付けるんだから、もう
Re: (スコア:0)
建築ならば、設計、施工、検査がそれぞれ独立した第三者なのは当然でしょ。
だからITの世界は、インダストリーとして遅れているのよ。テスターすら雇おうとしない。
Re:何で文字種制限しようとするのか (スコア:1)
いまだに、ITの世界が建築を目指していると思っているの?
Re:何で文字種制限しようとするのか (スコア:1)
クリエイティビティなんて関係ない。
単に、条件が違うので机上の空論だと言っているだけですが。
建設のように設計通りにできたプログラムなんて見たことがありますか?
砂上の楼閣をわざわざ大金かけて購入しようとは、
さすが金融屋さんは剛毅ですねえ。
冒険心にあふれています。
Re: (スコア:0)
フルスタックエンジニア(๑• ̀д•́ )✧+°ドヤッ
まぁ、ITはデジタルでソフトで、コピー簡単だしお金かからないでしょ、と一般に認知されてるから
建築のようにまともな予算つけてもらえない、っていうのがあるんじゃ。
Re: (スコア:0)
残念、ITは建築ではありません。
設計図から家が何万コピーも自動生成できるようになったらまた来てください。
Re: (スコア:0)
ハウスメーカー住宅の場合、工場において汎用パッケージがすでに作ってあって、現場ではそれを組み立てるのが仕事だよ。
いわゆるミドルウエア。
SQLエスケープ処理とかも、まさにミドルウェアの仕事でしょ。
なんで現場の開発者が、自分でエスケープ処理を書いているの?
Re: (スコア:0)
やってみろ
SQLインジェクション等されまくって
個人情報ダダ漏れになって
簡単に死ねるから
Re:何で文字種制限しようとするのか (スコア:1)
SQLとして意味のある記号をエスケープすればいいだけなのに、SQLとして意味がある記号が何か分からない(ドキュメント見れば全部書いてあるのに!)から手当たり次第に制限してんだよね。
そんなカーゴカルトプログラミング手法で本当に危険な記号を排除できてるとどうして信じられるんだろう・・・
Re:何で文字種制限しようとするのか (スコア:3, すばらしい洞察)
「佐々木」の入力すら想定できない開発者が、SQLのドキュメントに基づいて適切にエスケープできるわけないじゃん
Re: (スコア:0)
ヒント:Prepared Statement
DBプログラミングやったことないと知らないかもだけど、もはや基本テクニックの一つ。
#車輪の再発明を避けるってのはこういうことだ。、
Re: (スコア:0)
全部を監督できる環境ならいいけど、他システムからの入力だのがあって文字コード変換や予期しないサロゲートペアだのが放り込まれて、エスケープしたつもりがU+00A5を通しちゃいましたとかなるからだろ
Re:何で文字種制限しようとするのか (スコア:2, すばらしい洞察)
他システムからの入力をエスケープできない段階でアプリ関係なくアウトなのでは
Re: (スコア:0)
クライアント側に緩和策入れて「直叩き対策は?」って聞くと「アプリの改変は規約違反だから起こらない」とか意味不明の言い訳するやついるよね
Re: (スコア:0)
社内の端末の専用アプリからしか入力がないエスケープが必要がなかったシステムに、スマホからユーザが入力した文字列が入ってくるようになったとき、エスケープ処理を追加するより、ホワイトリストで許されるものしか通さないようにするほうが楽じゃね?
Re:何で文字種制限しようとするのか (スコア:2, すばらしい洞察)
って思うじゃん? いや、確かに楽だよ。楽だけどさ、結局今回のような問題が発生するわけで。
ホワイトリスト制限するのは自由だけど、だからといってエスケープ処理をしなくていいという考えは危険だと思うよ。
Re: (スコア:0)
サーバで落とせや!!!!!!!1
Re: (スコア:0)
> 意味のある記号をエスケープすればいいだけ
いやぁ、『々』を見落としちゃう現場ですよ?
「すればいいだけ」なんて言ってると絶対にまた見落としが出ます。
というか、意味のある記号だけエスケープって、文字列のデータしか考慮してないですか?
数値を埋め込むべきところにandとか通常の英字をぶち込まれるのは考慮しないつもりなんですか?
全部文字列データとして渡せば解決と思ってますか?暗黙の型変換でもっと色々死ねますよ?
Re:何で文字種制限しようとするのか (スコア:1)
SQLインジェクション対策に入力文字制限とか普通しないって。
かな英数字ならともかく、漢字の範囲なんか簡単にはできないでしょ。
これアプリのレビュー見ると散々だよ?
この問題だけじゃなく至る所でやらかしてる感じだよ。
どんな開発会社に頼んだんだよ。
Re: (スコア:0)
そういうSQLエスケープ処理は、データベース製品についてくるライブラリの仕事じゃないの。
暗号処理と一緒。
え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。
Re: (スコア:0)
上の方でサニタイズ言ってる人たちがそれに当たりそうで怖い・・・w
Re: (スコア:0)
え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。
いや、本当にそう
でも、自分で書こうとする人が後を絶たない
知らないだけなんだろうけど
Re: (スコア:0)
今どきweb設計するときにHTMLタグエスケープしないだの、SQL place holder使わないだのなんてありえないでしょ。
だからこそ文字種制限に意味あるのかと感じるんだけど。
複雑なシステムではプレースホルダは非現実的 (スコア:0)
実際コードを書いていないシステムエンジニアやセキュリティエンジニアの方は知らないでしょうが、
複雑なシステムではプレースホルダは非現実的で、バグの温床になりますよ。
そういう人から、プレースホルダ使えと言われると、現場はいい迷惑です。
現実的に考えて 価格.com のスペック検索 [kakaku.com] をプレースホルダで作れますか?
理論上不可能ではありませんが、場合分けでif文等が数十重にもなって、訳がわからないことになり、製作時間も数十倍、バグ発生リスクも数十倍になるでしょうね。
あと、プレースホルダ使えばSQLインジェクションが理論上絶対に発生しないといった出鱈目をまき散らしているセキュリティの専門家も多くいらっしゃ
Re: (スコア:0)
おいおい、ユーザにデータベースやテーブル名を指定させるのかww?
まず設計を見直そうな。
そもそも、バリデーションとエスケープは別の概念だぞ。
Re: (スコア:0)
> 価格.com のスペック検索
似たようなもの作ったことあるけどさ、
conds = []
conds << [" COLOR = ?" , foo]
conds << [" SIZE = ?" , bar]
みたいに投入していって、
conds.map{ |v| v.first ].join(" AND ")
と取り出せばいいだけじゃないかな。
Re: (スコア:0)
会社で10年以上運用してるシステムも絵文字でもなんでも受け付ける仕様なんだけどダメなかな?
プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
Re:何で文字種制限しようとするのか (スコア:3, すばらしい洞察)
> プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
それで正しいですよ。
むしろ「文字種制限しないと SQL Injection や XSS の危険があるようなシステム」の方がはるかに危ないです。
プレースホルダーとか適切なフレームワークを使ってないっていう意味ですからね。
Re: (スコア:0)
特許庁もこのレベルの連中がやってんだろうなあ
Re: (スコア:0)
アラビア語とか文字方向が違う文字入力されてレイアウトが崩れたり、変な装飾文字を入力されて脆弱性をつかれたりとか、ほんといろいろある。
入力できる文字をホワイトリストで限定したいというのはわからんでもない。