アカウント名:
パスワード:
二十年ぐらい前からSQLインジェクションやhtmlでのscripインジェクションなどが話題になってて入力文字列をそのままシステムで扱うのは禁止って初歩的な常識ができている。それなのにいまだにたびたびこういう問題が、しかも大企業のシステムで出てくるのは不思議でならない。わざと穴を作っていつでも侵入できるようにしてるとか陰謀論を考えたくなる。
氏名やニックネームなどの固有名詞はテーブルやハッシュに入れておいて、内部ではインデックスで処理するのが良いのかな。#素人考えです
free text inputはbase64にでもエンコードして扱えばいいのにと思う#素人考えです
型指定とか暗黙の型変換とかプログラム言語的な問題でしょ。
'true' という文字列だけを true に変換してしまうならそうかもだけど、暗黙の型変換のある言語でも大抵は、空文字列 => false, 空でない文字列 => trueの変換じゃない? そう考えると原因は違うところにあるような気がする。
Perlだと、空文字列、文字列の「0」、数値の「0」は「偽」と扱われる。なので、入力がなかったらエラーにしようと思ってif (!$param{"Nickname"}) { &error("ニックネームがありません。") }などとやると「0」を入力すると、入力があるのに、無い旨のエラーメッセージが表示されるというバグを作り込むことになる。
ただ、昔から知られたバグだけどね。
そういう誤った処理を防ぐために標準で汚染チェックモードを備えていて外部由来の入力文字列からは正規表現を使って取り出されるべき値を取り出せ!
っていう言語仕様なってるのに
かもだけど、
どこの方言ですか?
そういうのはソースコードに直接文字を書き込むときにしか起きないから、適当なエンコードかけておくだけで起きない問題だし意図しない変換がおきないようにそれをしておくのが普通だよ。
暗黙の型変換は普通変数内の値に対して起こるものだからソースコードに直接文字を書き込むときに起きるわけではないし、文字列変数内部の値をわざわざエンコードかけて保持しておくなんてめったにしないよ。じゃないと文字列操作や検索が面倒になる。
型変換は普通変数内の値に対して起きるのではなく、変数に文字列を代入するときに起きる(どちらも同じようだけどまったく違い)。ソースコードは文字列だから代入される値も文字列で型変換が起きる。jsonへの書き出しなども同じ。エンコードは、文字列を代入するときに起きるから文字列をエンコードかけて代入時に変換されないようにしてしまう。変数内では型変換が起きないから一度読み込んだ後はデコードして扱う(エンコード値を保持するわけではない)。
何故かは分からんが、Appleって昔からソフトウェアでの文字列の扱いがくっっっっっっそ苦手だよね。人は大きく入れ替わってるだろうに同じようなことがたびたび発生するのは一体どういうことなんだか。
文字列だけじゃないだろw全体的に苦手w
文字列のサニタイズ?(サニタイズ警察くるかも)の話よりは、オブジェクトのシリアライザ・デシリアライザの話に見える。
CORBAとかgRPCみたいにIDL書く手法ならともかく、JSONで連携してエンコーダデコーダは各々で書くみたいな手法を大企業のコードなりその中のライブラリなりでやってるとこういうこと起きると思う。
プログラマなら誰でも知ってることだが、SQLインジェクションやバッファオーバーフローが厄介なのは、それがあることは知っていても、完全にバグのないプログラムを作るのは難しいことだぞ。文字化けやメモリリークなんかもそうかな。#だからGCやライブラリやGCに丸投げするのだが、#汎用ライブラリが使えない領域だとそうもいかん。
「入力チェックさえすれば完璧」「注意すればバグは出ない」「ルールを作っておけば必ず守られる」「プログラマは完璧超人」なんて思ってるのは素人だけだぞ。
それ以前に、元の設計の筋が悪いことも多いけどね。むしろ「入力チェックさえすれば~」と思ってる人の方が、そういう設計にしがちなんだろうな。それを筋が悪いと思ってないから。
玄人は6ヶ月代金だけ取って放置を正しいと判断するってことですか?
SQLインジェクションに限っていえば簡単に100%防げるよ。だってSQL実行するときにデータを変数渡しすればいいだけなんだから。
過去にはDBとのコネクタに脆弱性があって、プレースホルダー使ってもSQLインジェクションされるパターンも有ったので要注意ですね。
JVN#59748723MySQL Connector/J における SQL インジェクションの脆弱性https://jvn.jp/jp/JVN59748723/ [jvn.jp]
関係者が最重要視しているのは「納期と費用」のみである。品質や安全のための工数や費用は削られる。(インターネットサービス企業は、客の先取り、囲い込みが勝敗を分けるので、開発スピード最重視。ハードウェアではこの戦略はとれないが、ソフトウェアではこの戦略は効果バツグン。)
原発だって、重大事故が起きなかったから、追加の安全対策は軽視され続けた。
ほかにも、IT製品開発費用に対する素人と実務経験者の認識の違いがあると思われる。例えるなら、自動車免許持っていれば、大型バス、大型トラックも運転できるよね。みたいな。○○(Java)ができるなら△△(JavaScript)もできると素人が考えても、実際はそうではない。
どうしてって、そりゃappleだからだよ
MacBook、USB-Cハブとの接続で破損macOS、パスワードのヒントボタンを押すと、パスワードを表示する脆弱性「キーチェーン」の全パスワード盗まれる恐れ macOSの未解決の脆弱性macOSに新バグ発見。イメージキャプチャで写真を取込むとサイズ膨張最新Macに「誰でもログインできる」バグアップル最新OSに重大バグ パスワードなしで管理者ログインApple史上最悪のセキュリティバグか、iOSとOS Xに危険すぎる脆弱性iPhoneなどの旧モデルに「修正不能」な脆弱性Apple、macOSでメールが解読されてしまう脆弱性iOSのメール機能、受信するだけで悪意あ
人間的なコンピュータだね(鼻くそほじほじ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
どうしてこんな問題が起きるんだろう (スコア:0)
二十年ぐらい前からSQLインジェクションやhtmlでのscripインジェクションなどが話題になってて入力文字列をそのままシステムで扱うのは禁止って初歩的な常識ができている。
それなのにいまだにたびたびこういう問題が、しかも大企業のシステムで出てくるのは不思議でならない。
わざと穴を作っていつでも侵入できるようにしてるとか陰謀論を考えたくなる。
Re:どうしてこんな問題が起きるんだろう (スコア:1)
氏名やニックネームなどの固有名詞はテーブルやハッシュに入れておいて、内部ではインデックスで処理するのが良いのかな。
#素人考えです
Re: (スコア:0)
free text inputはbase64にでもエンコードして扱えばいいのにと思う
#素人考えです
Re: (スコア:0)
型指定とか暗黙の型変換とかプログラム言語的な問題でしょ。
Re: (スコア:0)
'true' という文字列だけを true に変換してしまうならそうかもだけど、
暗黙の型変換のある言語でも大抵は、空文字列 => false, 空でない文字列 => true
の変換じゃない? そう考えると原因は違うところにあるような気がする。
Re: (スコア:0)
Perlだと、空文字列、文字列の「0」、数値の「0」は「偽」と扱われる。
なので、入力がなかったらエラーにしようと思って
if (!$param{"Nickname"}) { &error("ニックネームがありません。") }
などとやると「0」を入力すると、入力があるのに、無い旨のエラーメッセージが表示されるというバグを作り込むことになる。
ただ、昔から知られたバグだけどね。
Re: (スコア:0)
そういう誤った処理を防ぐために標準で汚染チェックモードを備えていて
外部由来の入力文字列からは正規表現を使って取り出されるべき値を取り出せ!
っていう言語仕様なってるのに
Re: (スコア:0)
どこの方言ですか?
Re:どうしてこんな問題が起きるんだろう (スコア:1)
Re: (スコア:0)
そういうのはソースコードに直接文字を書き込むときにしか起きないから、適当なエンコードかけておくだけで起きない問題だし意図しない変換がおきないようにそれをしておくのが普通だよ。
Re: (スコア:0)
暗黙の型変換は普通変数内の値に対して起こるものだからソースコードに直接文字を書き込むときに起きるわけではないし、
文字列変数内部の値をわざわざエンコードかけて保持しておくなんてめったにしないよ。じゃないと文字列操作や検索が面倒になる。
Re: (スコア:0)
型変換は普通変数内の値に対して起きるのではなく、変数に文字列を代入するときに起きる(どちらも同じようだけどまったく違い)。ソースコードは文字列だから代入される値も文字列で型変換が起きる。jsonへの書き出しなども同じ。
エンコードは、文字列を代入するときに起きるから文字列をエンコードかけて代入時に変換されないようにしてしまう。変数内では型変換が起きないから一度読み込んだ後はデコードして扱う(エンコード値を保持するわけではない)。
Re: (スコア:0)
何故かは分からんが、Appleって昔からソフトウェアでの文字列の扱いがくっっっっっっそ苦手だよね。
人は大きく入れ替わってるだろうに同じようなことがたびたび発生するのは一体どういうことなんだか。
Re: (スコア:0)
文字列だけじゃないだろw
全体的に苦手w
Re: (スコア:0)
文字列のサニタイズ?(サニタイズ警察くるかも)の話よりは、
オブジェクトのシリアライザ・デシリアライザの話に見える。
CORBAとかgRPCみたいにIDL書く手法ならともかく、JSONで連携してエンコーダデコーダは各々で書くみたいな手法を
大企業のコードなりその中のライブラリなりでやってるとこういうこと起きると思う。
Re: (スコア:0)
プログラマなら誰でも知ってることだが、SQLインジェクションや
バッファオーバーフローが厄介なのは、それがあることは知っていても、
完全にバグのないプログラムを作るのは難しいことだぞ。文字化けやメモリ
リークなんかもそうかな。
#だからGCやライブラリやGCに丸投げするのだが、
#汎用ライブラリが使えない領域だとそうもいかん。
「入力チェックさえすれば完璧」「注意すればバグは出ない」
「ルールを作っておけば必ず守られる」「プログラマは完璧超人」
なんて思ってるのは素人だけだぞ。
それ以前に、元の設計の筋が悪いことも多いけどね。
むしろ「入力チェックさえすれば~」と思ってる人の方が、そういう
設計にしがちなんだろうな。それを筋が悪いと思ってないから。
Re: (スコア:0)
玄人は6ヶ月代金だけ取って放置を正しいと判断するってことですか?
Re: (スコア:0)
SQLインジェクションに限っていえば簡単に100%防げるよ。
だってSQL実行するときにデータを変数渡しすればいいだけなんだから。
Re: (スコア:0)
過去にはDBとのコネクタに脆弱性があって、プレースホルダー使ってもSQLインジェクションされるパターンも有ったので要注意ですね。
JVN#59748723
MySQL Connector/J における SQL インジェクションの脆弱性
https://jvn.jp/jp/JVN59748723/ [jvn.jp]
Re:どうしてこんな問題が起きるんだろう (スコア:1)
client-side Prepared Statementというクライアント側でSQL文を組み立てる実装のバグで本来のプレースホルダーではありません。
なのでまともなプレースホルダーを使用するのであればSQLインジェクションは防げます。
Re: (スコア:0)
関係者が最重要視しているのは「納期と費用」のみである。
品質や安全のための工数や費用は削られる。
(インターネットサービス企業は、客の先取り、囲い込みが勝敗を分けるので、開発スピード最重視。ハードウェアではこの戦略はとれないが、ソフトウェアではこの戦略は効果バツグン。)
原発だって、重大事故が起きなかったから、追加の安全対策は軽視され続けた。
ほかにも、IT製品開発費用に対する素人と実務経験者の認識の違いがあると思われる。例えるなら、自動車免許持っていれば、大型バス、大型トラックも運転できるよね。みたいな。○○(Java)ができるなら△△(JavaScript)もできると素人が考えても、実際はそうではない。
Re: (スコア:0)
どうしてって、そりゃappleだからだよ
MacBook、USB-Cハブとの接続で破損
macOS、パスワードのヒントボタンを押すと、パスワードを表示する脆弱性
「キーチェーン」の全パスワード盗まれる恐れ macOSの未解決の脆弱性
macOSに新バグ発見。イメージキャプチャで写真を取込むとサイズ膨張
最新Macに「誰でもログインできる」バグ
アップル最新OSに重大バグ パスワードなしで管理者ログイン
Apple史上最悪のセキュリティバグか、iOSとOS Xに危険すぎる脆弱性
iPhoneなどの旧モデルに「修正不能」な脆弱性
Apple、macOSでメールが解読されてしまう脆弱性
iOSのメール機能、受信するだけで悪意あ
Re: (スコア:0)
人間的なコンピュータだね(鼻くそほじほじ