Webプログラミングにおいて、すべての言語はセキュアでない 21
ストーリー by hylom
「何を使うか」ではなく「どう使うか」が大事です 部門より
「何を使うか」ではなく「どう使うか」が大事です 部門より
あるAnonymous Coward 曰く、
しばしば、「○○というプログラミング言語は△△に比べて安全だ」「Webプログラミングの分野において最も安全な言語は何？」といった主張が繰り広げられることがある。これに対しSecurity Ninjaが「どの言語を選択しても関係ない、（なぜなら）それらは等しくセキュアでないからだ！」と反論している。
記事ではWhite Hat Securtyの統計レポート を元に、「どの言語も脆弱性がある入力の割合は大差なし」「かつて重要な脆弱性があったWebサイトの割合はどの言語でも70～80％台」「現在でも脆弱性があるWebサイトの割合はどの言語でも50～70％台」といったデータが示されている。このデータではPerlで実装されたWebサイトについて若干脆弱性が多いように見えるものの、結論としては「どの言語も等しくセキュアでない」とのことで、「セキュアなコードはセキュアな開発プロセスや開発者に対するセキュリティ教育を含むビジネスへの取り組みによってしか産まれない」と述べている。
平等に価値がない (スコア:5, おもしろおかしい)
俺は厳しいが公平だ 言語差別は許さん
VB豚、Perl豚、PHP豚を、俺は見下さん
すべて―――平等に価値がない！
Re:平等に価値がない (スコア:5, おもしろおかしい)
Re:平等に価値がない (スコア:1, おもしろおかしい)
ネットワークとセキュリティの知識が足りなかったのか 貴様？」
軍曹殉職
言語がセキュアにするのではない (スコア:4, おもしろおかしい)
チャック・ノリス [wikipedia.org]がセキュアにするのだ。
むしろ (スコア:3, おもしろおかしい)
すべての言語はセキュアでない ... チャック･ノリスの前では
# どちらかというと、チャック･ノリスはセキュアでなくする方だとおもふ。
Re:言語がセキュアにするのではない (スコア:1)
ソビエトロシアでは、チャック・ノリスが言語をセキュアにする！
言語？ (スコア:2)
どんな環境でも、穴があるようにコーディングしたら、セキュアじゃないでしょ。
何やったら問題かを、わかった上でコーディングしないと。
Web上のセキュリティホールって、何をさすのかも問題だし。SQLインジェクションなのか？CSRFなのか？
ただ、PHPの出力がデフォルトでhtmlspecialcharsがかかった状態で出力されるべきである、というのは同意だな。それだけでも（詳しくない人間が当座で書いた）初心者コードがかなり助かったと思う。あと、PDO標準装備であるべきだったと思う・・・PHP登場時は、クラスが無かったら無理か。
magic_quote, magic_quote_gpcってのもあるみたいだけど、評判悪いし。
-- gonta --
"May Macintosh be with you"
Re:言語？ (スコア:3, すばらしい洞察)
現状では言語仕様自体がセキュアなんてことはないと思う。
もし、存在するとすればXSSやSQLインジェクションなんか書いたら
コンパイルエラーかワーニングで指摘してくれる新世代の言語なんだろう。
ただそれでも環境設定一つで脆弱性は生み出されてしまう。
言語だけでセキュアにしようなんていうのはその考えが「脆弱性」
セキュリティ教育による「技術者意識の向上」が一番の解決策だろう。
Re:言語？ (スコア:1)
> もし、存在するとすればXSSやSQLインジェクションなんか書いたら
> コンパイルエラーかワーニングで指摘してくれる新世代の言語なんだろう。
旧世代の perl4 の時代から、perl には taint モードがありますよ。
外部から入力されたデータは「汚染されている」ものとマークされ、
変数代入などで汚染が伝播していきます。
でもって「危険なオペレーション」に「汚染されたデータ」を入れるとエラーになる。
最大の問題は、デフォルトはオフで、-Tオプションを付けないとtaint mode にならないことですかね。
setuid している場合は自動でオンになるので、普通のスクリプト言語として使う分には困らないのですが…
あと、taint mode を使ってると、たまに汚染除去がめんどくさくなって
「$a=($a=~/^(.*)$/)[0];」みたいなコードを書いちゃったりして、
> セキュリティ教育による「技術者意識の向上」が一番の解決策だろう。
という意見はその通りだと思う耳が痛い話ですが…
Re: (スコア:0)
どんな言語でも結局は書き手の技量に依存するわけですね。
読みにくいのも、インセキュアなのも、スパゲッティ……なのは、スパゲッティモンスター様の気分次第か。
# XSS対策は本当に難しいです。
Re: (スコア:0)
これはこれでhtmlspecialchars()されると危険な状態が作られてしまいそう
発見しにくいうえに原理を理解するのがややこしい
ピザおいしいです＾＾ (スコア:1)
「バナナのみ食すというダイエットは絶食に比べて安全だ」「低カロリー料理の分野において最も美味なものは何？」といった主張が繰り広げられることがある。
これに対しオデは「どの食事を選択しても関係ない、（なぜなら）君らは等しく運動をしていないからだ！」と反論してみる。
// 痩せるための行動 → システム構築と考えると
// 結局は「当人の意識次第」ってことだよね。
// whatよりhowの精神でございましょうて(:>^
安全な言語は無いけど，道具が何でも良いわけではない (スコア:1, すばらしい洞察)
今さらメモリ保護の無い言語をウェブアプリケーション開発には使わないし，優れたフレームワークや欠陥検出ツールが脆弱性を減らすために有効なのも間違いない．
そもそも， Security Ninja の記事が酷い誤誘導だ．「安全な言語は無い」のと「言語の選択には意味がない」のは全然別の話だろう．
WhiteHat Website Security Statistics Report には下のように書かれていて，言語やフレームワーク毎に脆弱性の種類などに違いがあったとしているのに．
(アブストを流し読みしただけなので，あとは専門の人に任せた．隣接分野なので本文まで読む暇はないです)
Re: (スコア:0)
>メモリ保護の無い言語をウェブアプリケーション開発には使わない
ウェブアプリケーション開発の一部にカーネルモジュールなどが使われてますよ。
http://www.facebook.com/note.php?note_id=388112370932 [facebook.com]
http://lwn.net/Articles/357658/ [lwn.net]
http://sunos.saita.ma/ [saita.ma]
メモリ保護の無い言語、例えばC言語でも、Clang Static Analy
さすがにみんなスルーしてるけど (スコア:1)
さすがにみんなスルーしているけど
こんな突っこまれやすい主張や質問、誰もしてないっすよ。聞いたことない。まあ、どこかにあるかもしれないけど、誰も相手にしないから話題にもならないんじゃないかな？
LIVE-GON(リベゴン)
Re:セキュアでない経営者を排除するのが唯一の方法 (スコア:1, おもしろおかしい)
Re: (スコア:0)
なんでやねん。
Windowsが少なくなって何が増えたらましになるんや？
Re: (スコア:0)
正しく設定されたWindows Server 2008は十分堅固だと思いますよ。
まあ、Windows Serverを正しく設定するのはLinuxサーバーを正しく設定するのと
同じ程度に難しいですが。
Re: (スコア:0)
そしてPCを使う人々は絶滅が確定するんだ。新しい人間が入ってこなくなるから。
……つうかだ、こういう選民主義者的な手合いしかいないのか、この界隈は。