アカウント名:
パスワード:
実際, プロジェクトマネージャレベルでは, 末端の開発者・Webデザイナはセキュリティに関して「全く考慮していない」ことを前提にプロジェクトをコントロールすべきですね.
逆に開発者・Webデザイナがセキュリティに関する知識を持つのは当然なんて, よっぽど小さなプロジェクトでもないかぎり, 極めて危険な思想でしょう.
単純に Prepare サイコーってだけなら、#985433 [srad.jp] で書かれている SqlCommand クラスが普通に Prepare 持ってます。
#985433 は、それをさらに業務的に利用しやすい .NET Framework 上のフレームワークを作ろうって話では?
知っている人は知っているし、知らない人は知らない。敢えて言うまでもないし、Web アプリケーション開発エンジニアと一般化できるようなものでもない。
ということで、反論なんて出ないし出せないのではないでしょうか。
ごく一部を除いて、知らない人の方が圧倒的に多いというのは実感としてありますけれど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
日本人は手をあげない (スコア:5, すばらしい洞察)
全員覚えるのは、無理！ (スコア:5, すばらしい洞察)
どうせセキュリティの不具合って
・無理な遷移やデザインの都合を優先しろと言われた
・当初の話には一言もなかった機能をリリース間近に要求される
・どうでもいい機能と開発側が勝手に思い込む
・本当に知らない(理解力が残念な開発者)
とかでしょ。
よく分かっている人たちだけで、フレームワーク独自で作るか
SpringとかMojaviとかCatalystとかrailsとかカスタマイズして、フレームワークレベルでSQLインジェクションやXSSは対処すべきだと思う。
それで、ある程度分かっている人たちで、そのベースフレームワークをプロジェクト用に直して、分からない人たちは、フレームワークから外れないでソース書けとなるんでないの。
ディレクターに必要なのは、ユーザビリティーやサイト目的に外れる要求を出してくるクライアントを説得する能力ではないかと思われ。
高木さんのサニタイズ言うなキャンペーン [takagi-hiromitsu.jp]もそうだけど、
変にセキュリティ対策という考えを持つより、
正常系の処理に組み込む（組み込まれているようにする）ことが
大事で、それぞれが独自のプロ意識をもって取り組むほうが、
なんちゃってセキュリティを防げるよ。
Re:全員覚えるのは、無理！ (スコア:1)
実際, プロジェクトマネージャレベルでは, 末端の開発者・Webデザイナはセキュリティに関して「全く考慮していない」ことを前提にプロジェクトをコントロールすべきですね.
逆に開発者・Webデザイナがセキュリティに関する知識を持つのは当然なんて, よっぽど小さなプロジェクトでもないかぎり, 極めて危険な思想でしょう.
Re:全員覚えるのは、無理！ (スコア:1)
もちろん開発標準とかの中で指示はするけど、信用はしない。
むしろ、テスト項目として挙げない（もしくはすり抜けてしまう）事の方が
理解不可能です。
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:全員覚えるのは、無理！ (スコア:1)
「正しくないSQLインジェクション対策」で、一見するとSQLインジェクション対策がなされているかのように
テストをすり抜ける可能性があります。（テスト内容にもよる）
もちろんテストは必要ですが、それは最後の砦であって、脆弱性についての対策はもっと別の部分でなされる
べきでしょう。
# 脆弱性有無のチェックには、テスト駆動開発の手法はそぐわないのではないかと密かに思ったり。
つうことで、元コメント(#985044 [slashdot.jp])の趣旨にほぼ賛成。
Re:全員覚えるのは、無理！ (スコア:1, 興味深い)
なになに、出力段階で特殊文字はエスケープすることが本来の意図であり、サニタイズという言葉はCGI入力を無害化すれば対策になると勘違いさせるからよろしくない。
…いや、サニタイズは「外部入力の文字は全て安全でないとみなし、安全な文字だけを出力するようにする」方法論では。
昔から CGI 出力のエスケープをどうやるかやり方はいくつかあって、そのうちのひとつ。これはHTMLのレイアウトとコンポーネントを分離し、プログラム小部分ではその部分のviewになるHTML部品を文字列で作成。最後にレイアウトマネージャが各部品文字列をそのまま出力するようなタイプのCGIで便利なやり方で、コンポーネント指向好きに愛用されていた。
特に Perl の taint 機能と併用すると漏れがなくなる。というか taint はこのやり方のために導入されたわけだし。
サニタイズすれば対策になるという説明をやめようという趣旨はいいけど、出力時にエスケープするのが本質であるというのは首をかしげるな。
Re:全員覚えるのは、無理！ (スコア:1)
半年以上前の話に「今度は～やってるんですか」とか言われても
困ると思います。
知ってる人は敬遠される (スコア:4, 興味深い)
うちにもシステム側にもHTML/CSS側にも詳しい人がいるんですが、
そういう人は単価が高いため、技術知識等が少々アレゲでも
安い人を回すしかないケースが多々。
また、短納期でとにかく量産して稼いでるところは、
セキュリティの事には簡単な対処だけで済まそうとしてるところも多く、
あまり深いツッコミを入れられて工程が伸びるのを嫌がるケースも珍しくないんです。
Re:知ってる人は敬遠される (スコア:1)
アレゲで安いなら最高じゃないの？
＃アレゲってそういう意味じゃない？
技術者でも大丈夫か? (スコア:3, 興味深い)
旧来のOSなどアプリケーションの作成に詳しい方でも、Web技術にあまり詳しくない方がプロジェクトを仕切ると、Webサイトがちゃんと動くか、見た目は大丈夫か?のテストしかしないみたいなことがあったのですが、腕のある技術者でも大丈夫かなぁと思うことがしばしば。
Re:技術者でも大丈夫か? (スコア:5, 興味深い)
あり得た問題です。ここが、XSS脆弱性などと大きく異なるところ。
（Webによって、SQLインジェクションの影響がより広範囲かつ深刻になった、という事情はありますが）
なので、「旧来のOSなどアプリケーションの作成に詳しい方」であれば、仮に「Web技術にあまり詳しくない」と
してもSQLインジェクションは知っているはずで、すなわち「Webサイトがちゃんと動くか」の確認内容にSQL
インジェクションの有無の確認も入っているはずなのです。
Web化によってSQLインジェクションがことさら注目されるようになったということは、旧来のC/Sアプリでいかに
そのあたりがサボられていたか、ということの裏返しのような気がします。
従来も問題はあったのだが、使用者が限られており、影響も
「 "It's mine." を登録しようとするとエラーになるんですけど？」
「それは制限です」
…程度で済んでいた、ということでしょう。
Re:技術者でも大丈夫か? (スコア:4, 興味深い)
程度ならいいのですが、CSで育った技術者の中には、SQL Injectionを指摘すると「何を気にしてるの？」と馬鹿にする向きもありますよ。
曰く
「『その文字は入れないでください』とか言えばいいだけでしょ。」
「悪意をもっているなら法律で対処可能だから気にする必要はありません」
「工数を増すの？ 仕事なんだよ。ちゃんと考えたら？」
と。
# いまだに見る問題なのでAC
Re:技術者でも大丈夫か? (スコア:1)
ですが、未だにこの問題が報告されている現状からしますと,
多いにあり得る状況なんですよ。
授業参観効果 (スコア:2, すばらしい洞察)
十分にあり得ます。
Youthの半分はバファリンでできています。
プログラマ？ クリエータ？ (スコア:3, 参考になる)
その中でウェブ関連の業務に携わっている人員はひとケタ。
よって、HTML + CSS のベタなホームページから、Perl、PHP、Java を
使ったウェブシステムまでひとりで何でも作ります。
さいきんは CMS や Blog システムの設置・カスタマイズが多いんですけどね。
その他、取材のためデジタルカメラを持って現地踏査とか、
お客さんの端末のメール設定とか、果てはキオスク端末（質量 100kg！）の
設置とか、すっかり便利屋さんと化しています。
アクセシビリティやウェブセキュリティについても一応勉強してますが、
ほんと流した程度だなあ orz
Re:プログラマ？ クリエータ？ (スコア:4, 興味深い)
Web製作というものが仕事として認められるようになり始めた当初、「Web製作」といえば、単純にWebの見栄えとアクセシビリティーのデザインを行うものでした。極端な話、DTPの延長で、デザイナーの仕事と思われてました。
それが、Flashが載り、Javaが載り、ActiveXが載り・・・と単なる閲覧ではなく、アプリケーションとして働くようになってきて、その辺から「Web製作」の意味がそれらの「開発」を含むようになってきたわけです(厳密に言えば、独立してる現場もありますが)。
「Web外観デザイン」と「Web動作デザイン」は求められる能力もセンスも違います。どちらが優位というわけでもありません。それを「Web製作」という言葉で一括りにしてしまうのが問題なのではないでしょうか。
Re:プログラマ？ クリエータ？ (スコア:2, 参考になる)
Re:プログラマ？ クリエータ？ (スコア:1, 参考になる)
> やってる人ははるか以前から着目していました。
> ～～以下略～～
非常に同意。3～4年ぐらい前からちゃんとした本なども出るようになって、会議やクライアントに話が通る様になってきてホッとしてます。
# それ以前は「なに面倒なこと言ってんだ？」とか、アクセシビリティーや
# ユーザビリティーを勘違いして、ごくごく個人的な使い勝手を盛り込まさ
# れたり、Webデザイナーという肩書きののデコレーショナーや前衛的/奇抜
# なインターフェイスがもてはやされたり・・・ね。
Re:プログラマ？ クリエータ？ (スコア:1)
Re:プログラマ？ クリエータ？ (スコア:1)
Re:プログラマ？ クリエータ？ (スコア:1)
#というか厳格にいえばHTMLで日本語が扱えるようになったのはRFC2070以降ですし。
いわゆる業務として行うWeb制作の話ですよねえ…？
うーむ、"呼称の問題"、というのが意図することは、まあわかるのですが、その頃やっていたアクセシビリティとやらにおける具体的な施策（成果物）はどういうものだったでしょうか。
だって日本人だもの・・・ (スコア:3, すばらしい洞察)
>と尋ねたところ6割程度の人しか手を挙げなかったのが
知っていても決して手を上げないのが日本人の習性ですから:-
Re:だって日本人だもの・・・ (スコア:3, すばらしい洞察)
とゆう質問の意味を、
・辞書的な意味で、知っている
・骨身に染み付くぐらいに、知っている
・目を瞑ったまま対処できるぐらいに、知っている
等々、どうゆうレベルに取るかによって、
態度が変わる気がします。
// 「お前はSQLを知っているか？」と問われて、
// 躊躇無くyesとこたえられない気がするけどID
Re:だって日本人だもの・・・ (スコア:2, おもしろおかしい)
Re:だって日本人だもの・・・ (スコア:1, フレームのもと)
単にサニタイズ問題に矮小化されがちであるのは非常に気になりますねえ．．．
# これに気がついている技術者が少ないことが，特に．
みんつ
Re:だって日本人だもの・・・ (スコア:1)
ストレートに解釈するところの「権限」だとすると、これを「権限昇格」というのはあまり一般的でないような。
Re:だって日本人だもの・・・ (スコア:2, すばらしい洞察)
日本人の習性としてはむしろ（場の雰囲気にもよりますが）
- 常に上げない
- 人数が多ければ（実際に知ってる・知らないにかかわらず）上げる
というパターンのような
「SQLインジェクション」という言葉を知らない人
と尋ねるとまた別の結果がでるような
平気ですよ。 (スコア:3, おもしろおかしい)
<font color=red size=144>SQLインジェクション絶対禁止</font>
って、書いておいただけで何も問題は起こっていませんよ。
WEB制作者 (スコア:2, 興味深い)
「SQLインジェクションとかそういうのは開発の方が考えること」
で終りそうな感じです。
WEB制作の部署はシステム側には無関心なので6割どころか1割もいない感じです。
他ではどうなんでしょうか？うちの会社が特別なんですかね？
Re:WEB制作者 (スコア:3, 興味深い)
「SQLインジェクション？そんなことも解決してくれないフレームワークで開発してるわけ？」
で終わりそうな気が。
＃デフォルトで備わっているサニタイズ機能をわざわざOFFにして「色とか自由に付けられるようにしました！」とか言う新人君に目眩がすることもあるけどid
Re:WEB制作者 (スコア:1)
◆IZUMI162i6 [mailto]
Re:WEB制作者 (スコア:1)
かつ開発者と WEB制作部署がきちんと分離している環境でなら
テストする上では WEB制作部署も知っていなければならないでしょうが、基本的に開発が考えることでしょう。
# それ以前に、OJT と称してまともに DB しらない人間に
# SQL文 を書かせるなよ。。。
マクロの基本は検索置換(by y.mikome)
Web系というわけじゃないが (スコア:2, おもしろおかしい)
俺(へタレSE)「このWebアプリケーションではクライアントとサーバの通信にHTTPプロトコルを使用しています。デフォルトのTCPポート番号はxxxxです。」
ボス(SE)「ちょっと待て、HTTPなら80じゃないのか？」
俺「違います」
ボス「そんなんで通信できるのか？」
……め、眩暈が。
SQLインジェクション周知の徹底も重要ですが (スコア:2, 興味深い)
フレームワークの構築とその使用の徹底もより重要と考えます。
＃例えば.NETが提供するフレームワークの内データベース処理を担当するADO.NETは
＃SQLインジェクションが構造的に不可能なように構築されてたと思います
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
ご指摘の通り、SQLCommand関連のクラスとかを直接叩けば生コードはいくらでも叩けます。
が、ADO.NETで推奨されているように、
発行されたフォームから持ってくる更新当、値の代入には”パラメータ”技術を介するように
徹底するとかでも潜在する危険度はぐっと減る事でしょう。言いたいのはそーゆーことです。
（開発環境で用意されているウィザードを使うと勝手にその辺はやってくれますが
まあ実際は自動生成されたコードいじったりおおむねSQLCommandとかを直接操作するの
ですしね）
＃実際にはもっと突き詰めて内部的にそのような処理を行うラッパークラスを
＃独自のフレームワーク上で用意し、Web開発者にはそのフレームワークで用意
＃したメソッドを使うよう徹底するというのがいいのではないかという事です。
＃そうするとSQLインジェクションへの注意をフレームワーク開発上に集中でき
＃末端のWeb開発者含めた全員に周知徹底コードの厳密な監視を随時行うという
＃あまり現実的でなさそうな工数をある程度削減できるのではないかと。
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
> 徹底するとかでも潜在する危険度はぐっと減る事でしょう
プログラマが意識してそれを選択しなければならないとしたら、「きちんとエスケープすることを徹底すればよい」
というのとあまり変わらないと思いますよ。
パラメタライズドクエリ（変数バインド）自体は大昔からあるわけで。それがきちんと使われないから脆弱性が
減らないのですから。
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
私の手元では(Javaなので)PreparedStatementと静的解析ツールのFindbugs [sourceforge.net]を組み合わせて、多分おっしゃっているようなことを実現してはいるとは思いますが…。
.NET環境では、そういうものって無いのでしょうか？
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
単純に Prepare サイコーってだけなら、#985433 [srad.jp] で書かれている SqlCommand クラスが普通に Prepare 持ってます。
#985433 は、それをさらに業務的に利用しやすい .NET Framework 上のフレームワークを作ろうって話では?
Re:SQLインジェクション周知の徹底も重要ですが (スコア:1)
せいぜい見つかったのは、SQLCommandオブジェクトを作るときに、生成もとのStringがfinalというかConst宣言したString型変数が渡されたかどうかを検出させる方法がない…と言っている程度に見えたから、「それなら静的解析ツールに頼ったほうがいいんでない？」と思ったのですが、どうでしょう。
# .NET環境用のものもいくつかあるようですね。
# 有料ですけが…。
板ばさみ (スコア:1)
企画部門は、「インタラクティブなUIを」システム部門は、「なにそれ、ムリムリ」という、クライアントの板ばさみにあうことがよくあります。
まず、社内で話してほしぃ。。。orz
「制作者が思っている以上に、開発エンジニアはHTMLを知らない。」 (スコア:1)
Re:「制作者が思っている以上に、開発エンジニアはHTMLを知らない。」 (スコア:1)
知っている人は知っているし、知らない人は知らない。敢えて言うまでもないし、Web アプリケーション開発エンジニアと一般化できるようなものでもない。
ということで、反論なんて出ないし出せないのではないでしょうか。
ごく一部を除いて、知らない人の方が圧倒的に多いというのは実感としてありますけれど。
Re:CSSを覚えるより (スコア:1, 興味深い)
ソースがあれば教えて下さい。
概ね同意だが…… (スコア:1, オフトピック)
※これが誤解ではないのなら、既に議論の余地は無いが（苦笑）
使っているPHPだろうがASP(.net)だろうがPerlだろうがJavaだろうがC++だろうがC#だろうがVBだろうがVBAだろうがRubyだろうが（以下略）、「馬鹿」という属性は開発者個人に属するものであって言語に属するものではない。
……まぁ（言語に限らず）開発者が馬鹿ばっかなコトには概ね同意はするが、それは単に「スタージョンの法則」 [wikipedia.org]がIT業界にも当てはまるというダケのことだろう（笑）
_ to boldly go where no man has gone before!
まあまあ・・・ (スコア:1)
PHPってお手軽であるがゆえ、SQLインジェクションとかそういった知識背景無くても書けてしまう。怖いのは「その辺知らないことを知らない」連中が増殖していること。
だから「PHPいじってる馬鹿」ってのはその辺の連中のことでしょう。逆に、よくわかっていてPHPを使っている連中もいますし、馬鹿はどんな言語扱ってもトラブル起こしますからね。
-- gonta --
"May Macintosh be with you"
Re:大袈裟に書いてあるけど (スコア:1)
必要充分だとは思いませんが、実用上それでもまかなえてしまう現状もあるのではないかとは思えます。それも多分に。
WWWが登場した当初はクライアントはリクエストを送ることでページデータを拾ってきて、それをただ表示するだけでした。ローカルでスクリプトや実行コードを動かすわけじゃないので、壊れたページやブラウザのバグで「うまく表示できない」事はあっても、それが原因でPCに侵入されるとかサーバーに侵入するなんてのはほぼありえませんでした。クライアントもサーバーも双方が動的に働くようになってる事が多い現状では、やはり携わる者には意識の改革は必要だと思えます。
＃すっかりWebにドップリなのに「まだ登場して10年も経ってないんだよな～」とか言ってたんですが、そうか…気づけばもう13年目にもなるのですな。
Re:大袈裟に書いてあるけど (スコア:1)
Re:大袈裟に書いてあるけど (スコア:5, 参考になる)
・SCRIPT要素は書けない。
・A要素のHREF属性に、javascriptスキームの値は書けない（というかscriptという文字列を含む値が書けない）。
という実装仕様だったけど、実装者は数値文字参照のことを知らなかった（HTMLの仕様を知らなかった）。そのため、
<a href="javascript:alert('XSS');">click me</a>
はフィルタを貫通して書き込めた。その後、数値文字参照については対応されたようだが、実装者は数値文字参照の最後のセミコロンが省略できることを知らなかった（HTMLの仕様を知らなかった）。そのため、
<a href="javascript:alert('XSS');">click me</a>
はフィルタを貫通して書き込めた。
…というような話です。
HTMLの仕様をきちんと知っていないと、ブラックリスト方式なフィルタを実装するのは結構大変だという一例として挙げられていました。
ということで、まあとりあえずは、セキュアなWebシステムだと思っていたものも、HTMLをよく知っていないことにより、何らかの穴があるかもしれない…ということはいえるのではないですかね。
なお、SSLの話は第2部中では後半にあたるのですが、後半の話はHTMLを知っていないと、というオチではなくて、セミナーのテーマどおりに「ディレクターが知っておくべき」の文脈に焦点のあるものでした。
Re:大袈裟に書いてあるけど (スコア:1)
一つ目の貫通した例は、
<a href="javascript:alert('XSS')>click me</a>
です。
# 蛇足ながら、つまりslashcodeは数値文字参照の最後のセミコロンが省略できることを知らない（あるいは、省略したものは数値文字参照として扱われない）ということなのだな、と……。
Re:Web制作者って HTML CSSを理解しているの？ (スコア:1)
# 納品されたコンテンツで頭抱えたことも何度かあったっけ
---- 何ぃ！ザシャー