アカウント名:
パスワード:
「現在、フォームの送信にGETを使うという脆弱性を改善すべく急いでおります。（中略）完成次第、お知らせいたします。」
開発元の中の人はアホですか・・・？どのメソッドを使うかとかそういう問題じゃないってのがわかってないんだろうか。わかってないんだろうな。
どのメソッドを使うかとかそういう問題じゃないってのがわかってないんだろうか。わかってないんだろうな。
GetからPutに変更しました!という修正になる予感がしました。
PUTが通っちゃったらそっちの方が大問題です。POSTだよPOST。
そうなんだけどね。<form method="put"でも(見かけ上)動いてしまう罠があるので…
いや、漏洩しちゃったお客さんにとってはPUTでおｋ汚物は消毒だー！
#と思ったらウィルス仕込まれてさらに情報抜かれたでござる
PUTが使えるブラウザって、実はいまだに世の中に1つもなかったりしない?Amayaとかどーなんだろ。
セツコそれは出銭や
あまり理解してないので、誤解があったら指摘していただきたいのですが。
google AnalyticsやリファラなどでIDやパスワード情報をURLに含んで渡っていた事が管理画面までクロールされてしまう原因となったので、とりあえずURLにIDやパスワードを含まないようにするというのは、対策の一つとして必要なのでは？
勿論、そもそも不特定多数がアクセス出来るような場所に管理画面を置いておくんじゃないよ！とか。ボットにクロールされるようにしとくな！とか、色々あるとは思いますけど。
サーバはお客さんの自主管理で、汎用的なネットショップスクリプトみたいなものを売るとしたら、意外と厄介だと思うんですけどね。
パスワードを平文で送受信してた所もお忘れなく。
ブログやTwitterの改ざん／なりすましより、エロゲやエロビデオの購買履歴漏洩の方が、社会的仕事的精神的恋人的ダメージの大きさは計り知れないものがある気がします。
件のCGIのURLはhttpsですから平文ではありません(ｷﾘｯ
menu.cgi?admin=password に修正されたのですね。
そういえば某所で
・HTMLソースに <input type="hidden" name="password" value="password"> みたいな感じでパスワードを含めていたり・一般ユーザーでログインしてても、ユーザー管理画面の URL と管理者の ID を指定すると、管理者としてユーザ管理画面を表示できちゃったり
なんてのも見たことあったなあ。ま、１０年くらい昔の話ですが。
さすがに今はもう、そんな牧歌的なセキュリティ意識で開発／運用してる会社なんかないでしょうけどね。
# 無いと信じたい信じたい信じたい
そこまで杜撰ではないですが、Cookieに平文でID・パスワードを保存しているサイト、なんていうのも、時々見かけますね。それだけでは問題が顕在化しにくいのですが、XSSやCSRFの影響をもろに受けるので非常に危険かな、とは思います。（何度かＩＰＡ経由で指摘はしましたが、修正されてないサイトのほうが多いですね……。）
話題のWEBインベンターさんのところにはサンプルがあって、管理機能とか一通り試せるんですが、会員管理でユーザ一覧を表示してユーザのリンクにフォーカスを合わせてURLを見ると
(略)/member.cgi?entry_no=22&ID_NAME=zzzza&PASS_W=zzzza&mode=renew1
( ﾟдﾟ) ・・・
(つд⊂)ｺﾞｼｺﾞｼ
や、管理者にユーザのパスワードがバレバレってのが不味いと思うんですよ。それ以前に平文でパスワードを保持してるのも駄目すぎるし。
> 中小企業では無く超大企業が納入
＜導入側の（ユーザーの）言い分＞ そのくらいのセキュリティは言われなくてもやるのが当然だろ！ 常識考えろ！
＜納入側の言い分＞ 要件書にないものがあるわけないだろ常識考えろ！ コンサルまでやってほしけりゃ、その分金出せ！
・・・ではないでしょうか？
単なる特注のシステムならともかく、セキュリティって利用者の想定を越えたところにあるものだから、請け負う側で対策できないとダメだよね。まあ、そういう僕はセキュリティ対策なんて出来る人間ではないですが。
でも、内部システムって、普通甘々じゃない?人間系も含めて、費用対効果の問われるところだよね。
＞でも、内部システムって、普通甘々じゃない?
「普通」ですと？……（´･ω･｀）
流出事件って内部犯行がけっこう多いですよね。中の人しか使わなくても油断しちゃ駄目ですよう。
その辺のコミュニケーションコストを減らすために、「非機能要件についてはIPAの××ガイドラインに従うこと。なお、具体的な指示・指定を必要とする場合は、別途定めるQA票で当社に確認すること」とか書ける世界になってるとお互いハッピーですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
GETとか関係ねぇ (スコア:2, 興味深い)
開発元の中の人はアホですか・・・？
どのメソッドを使うかとかそういう問題じゃないってのがわかってないんだろうか。
わかってないんだろうな。
屍体メモ [windy.cx]
Re:GETとか関係ねぇ (スコア:4, おもしろおかしい)
どのメソッドを使うかとかそういう問題じゃないってのがわかってないんだろうか。
わかってないんだろうな。
GetからPutに変更しました!
という修正になる予感がしました。
Re:GETとか関係ねぇ (スコア:2)
PUTが通っちゃったらそっちの方が大問題です。POSTだよPOST。
言ってないことに反論するなよ
Re:GETとか関係ねぇ (スコア:2)
そうなんだけどね。
<form method="put"
でも(見かけ上)動いてしまう罠があるので…
Re: (スコア:0)
いや、漏洩しちゃったお客さんにとってはPUTでおｋ
汚物は消毒だー！
#と思ったらウィルス仕込まれてさらに情報抜かれたでござる
Re: (スコア:0)
PUTが使えるブラウザって、実はいまだに世の中に1つもなかったりしない?
Amayaとかどーなんだろ。
Re: (スコア:0)
Re:GETとか関係ねぇ (スコア:1, おもしろおかしい)
Re:GETとか関係ねぇ (スコア:2, おもしろおかしい)
セツコそれは出銭や
Re:GETとか関係ねぇ (スコア:1, 興味深い)
あまり理解してないので、誤解があったら指摘していただきたいのですが。
google AnalyticsやリファラなどでIDやパスワード情報をURLに含んで渡っていた事が
管理画面までクロールされてしまう原因となったので、とりあえずURLにIDやパスワー
ドを含まないようにするというのは、対策の一つとして必要なのでは？
勿論、そもそも不特定多数がアクセス出来るような場所に管理画面を置いておくんじゃ
ないよ！とか。ボットにクロールされるようにしとくな！とか、色々あるとは思いますけど。
サーバはお客さんの自主管理で、汎用的なネットショップスクリプトみたいなものを
売るとしたら、意外と厄介だと思うんですけどね。
Re:GETとか関係ねぇ (スコア:2)
パスワードを平文で送受信してた所もお忘れなく。
Re:GETとか関係ねぇ (スコア:2)
ブログやTwitterの改ざん／なりすましより、エロゲやエロビデオの購買履歴漏洩の方が、
社会的仕事的精神的恋人的ダメージの大きさは計り知れないものがある気がします。
Re: (スコア:0)
Re: (スコア:0)
件のCGIのURLはhttpsですから平文ではありません(ｷﾘｯ
Re: (スコア:0)
成り上がり (スコア:1, おもしろおかしい)
http://example.com/hoge/menu.cgi?admin=1
まあ、すぐ対策されましたが
Re:成り上がり (スコア:1)
menu.cgi?admin=password に修正されたのですね。
1を聞いて0を知れ!
Re: (スコア:0)
そういえば某所で
・HTMLソースに <input type="hidden" name="password" value="password"> みたいな感じでパスワードを含めていたり
・一般ユーザーでログインしてても、ユーザー管理画面の URL と管理者の ID を指定すると、管理者としてユーザ管理画面を表示できちゃったり
なんてのも見たことあったなあ。
ま、１０年くらい昔の話ですが。
さすがに今はもう、そんな牧歌的なセキュリティ意識で開発／運用してる会社なんかないでしょうけどね。
# 無いと信じたい信じたい信じたい
Re:GETとか関係ねぇ (スコア:2)
そこまで杜撰ではないですが、Cookieに平文でID・パスワードを保存しているサイト、なんていうのも、時々見かけますね。それだけでは問題が顕在化しにくいのですが、XSSやCSRFの影響をもろに受けるので非常に危険かな、とは思います。
（何度かＩＰＡ経由で指摘はしましたが、修正されてないサイトのほうが多いですね……。）
Re:GETとか関係ねぇ (スコア:1, 興味深い)
話題のWEBインベンターさんのところにはサンプルがあって、管理機能とか一通り試せるんですが、会員管理でユーザ一覧を表示してユーザのリンクにフォーカスを合わせてURLを見ると
(略)/member.cgi?entry_no=22&ID_NAME=zzzza&PASS_W=zzzza&mode=renew1
( ﾟдﾟ) ・・・
(つд⊂)ｺﾞｼｺﾞｼ
Re: (スコア:0)
Re: (スコア:0)
や、管理者にユーザのパスワードがバレバレってのが不味いと思うんですよ。
それ以前に平文でパスワードを保持してるのも駄目すぎるし。
Re: (スコア:0)
>なんてのも見たことあったなあ。
>ま、１０年くらい昔の話ですが。
私は今日も会社で見ましたし明日も会社で見ることでしょう・・・
それ以外の我が社のシステム(一部)
1、情報検索ソフト
→ソフトウェア起動時にパスワードが必要だがini(当然プレーンテキスト)ファイルに
平文で生パスワードが保存されている、ハードディスクがFAT32フォーマットなので
アクセス制限すら無い、尤も表示するデータがパスワード無しでフルアクセス可能なサーバ上に
Re:GETとか関係ねぇ (スコア:1, 参考になる)
> 中小企業では無く超大企業が納入
＜導入側の（ユーザーの）言い分＞
そのくらいのセキュリティは言われなくてもやるのが当然だろ！
常識考えろ！
＜納入側の言い分＞
要件書にないものがあるわけないだろ常識考えろ！
コンサルまでやってほしけりゃ、その分金出せ！
・・・ではないでしょうか？
Re: (スコア:0)
単なる特注のシステムならともかく、セキュリティって利用者の想定を越えたところにあるものだから、請け負う側で対策できないとダメだよね。
まあ、そういう僕はセキュリティ対策なんて出来る人間ではないですが。
でも、内部システムって、普通甘々じゃない?
人間系も含めて、費用対効果の問われるところだよね。
Re: (スコア:0)
＞でも、内部システムって、普通甘々じゃない?
「普通」ですと？……（´･ω･｀）
流出事件って内部犯行がけっこう多いですよね。
中の人しか使わなくても油断しちゃ駄目ですよう。
Re: (スコア:0)
その辺のコミュニケーションコストを減らすために、「非機能要件についてはIPAの××ガイドラインに従うこと。なお、具体的な指示・指定を必要とする場合は、別途定めるQA票で当社に確認すること」とか書ける世界になってるとお互いハッピーですね。