アカウント名:
パスワード:
それはRESTの問題ではない。
どんな技術を使おうと、認証なしで他人の機密情報にアクセスできたらダメでしょ。
> 認証が行われないのは仕様ではなく単なるバグ
素人目にはそれも含めて仕様だと思うのですが…もし単なるバグだとしたら、本来はどのような動作を意図していたのでしょうか?
魔法のコトバ、「仕様バグ」
URLに秘密情報を入れてはいけないってほとんど常識の部類だと思ったんだけどそう油断して基本設計でわざわざ明記しなかったことがこの事故につながったのか。とても良くわかった
そもそもPOSTよりもログに残りやすいってのがあるけど、決定的なのは、SSL通信の時に大きな差がでるね。
決定的なのは、SSL通信の時に大きな差がでるね。
出ますかね?SSL通信時って、HTTPS通信時ってことですよね?少なくとも、URLのドメイン名より後ろの部分は、暗号化された経路内を流れるから、POSTだろうとGETだろうとPUTだろうと、口座番号が暗号化されているという点では違いが出ない気がしますが。
画面を後ろから覗き見される危険性が、現実的には一番大きいんじゃないかと。
Proxy通すとよく判りますよねCONNECT:XXXXXX(XXXXはアクセス先のホスト名)しかログに残らないフィルタを通過してしまうので、ネットワーク管理者泣かせではあるかもしれず
一般論としては、口座番号そのものはもちろん秘密情報ではないでしょう。口座番号だけ分かっていても、出来るのは「その口座に振り込むこと」くらいですし。問題は「口座番号が分かれば個人情報やクレジットカード情報にアクセスできる」システムを作ってしまったことなわけで。
>一般論としては、口座番号そのものはもちろん秘密情報ではないでしょう。
口座が分かれば差し押さえもできますし、ひろゆき氏 [wikipedia.org]みたいなケースではとっても大事な秘密情報じゃないでしょうか?
いや、令状に基づく法の執行たる差押えと同列に語られても……
所謂、白紙から紙か何かにひとつのブツを一応最初から最後まで完結したカタチで造った事が人たちが多いから、その辺の、「基本設計だとか仕様って言葉自体が、 理解不能=分からない人たちが多い」ですよ、シゴトに限らず(合掌)
まぁ、ガンプラのフルコンプリートモデルさえ1体も組み立てたことの無い人たちと一緒にシゴトした時は、さすがに、ツラかったですね(走召糸色木亥火暴)
>#こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫!」とか言われても信用できないんですよね
仕様がおかしいって話なのに、なんでカバレッジの話を持ってくるのか意味がわからん。どこのどいつが、「カバレッジ」で「仕様」が問題ないことを「絶対大丈夫」とかほざくんだよ…
まぁ、そもそもプログラムのバグに関してでも>「JUnitのカバレッジ100%だから絶対大丈夫!」なんて発言するやつに出会った事ないけど…
しかも何故にJUnit限定?
何と戦っているんだ?仕様がおかしかったら、カバレッジなんか無意味だというだけの話だよね?
>まぁ、そもそもプログラムのバグに関してでも>>「JUnitのカバレッジ100%だから絶対大丈夫!」>なんて発言するやつに出会った事ないけど…
どこかのフレームワークの信者がそのフレームワークの優位性をアピールするために、ユニットテストのカバレッジが高いことを示していた事例があったと記憶している。
ソースを見てみたら、ゲッターやセッターがやたら多くて、メソッドのカバレッジを底上げしていただけという絡繰りだったとか。
>しかも何故にJUnit限定?そりゃ一番有名だからでしょ。べつに限定しているわけじゃない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
あまりにもお粗末 (スコア:3, 興味深い)
・・・だけどもうIT業界自体が「普通」じゃないんだろうな、と思わされる
#こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫!」とか言われても信用できないんですよね
Re:あまりにもお粗末 (スコア:1)
Re:あまりにもお粗末 (スコア:1)
それはRESTの問題ではない。
どんな技術を使おうと、認証なしで他人の機密情報にアクセスできたらダメでしょ。
Re:あまりにもお粗末 (スコア:1)
その口座番号がログインしたユーザーのものかチェックしないってのがそもそもの問題だな。
Re: (スコア:0)
まぁ、口座番号入れても認証を通ってなければ単に404を返すような感じならなくもないかもしれないけど
・・・やっぱり、気持ちよくない設計ですな
Re:あまりにもお粗末 (スコア:1)
元記事から読み取れた"仕様"に関する記述がURL設計だけだったから、氏がどういう風に考えているのか聞きたかったのです。
認証が行われないのは仕様ではなく単なるバグでしょう。
Re: (スコア:0)
> 認証が行われないのは仕様ではなく単なるバグ
素人目にはそれも含めて仕様だと思うのですが…
もし単なるバグだとしたら、本来はどのような動作を意図していたのでしょうか?
Re: (スコア:0)
魔法のコトバ、「仕様バグ」
Re: (スコア:0)
URLに秘密情報を入れてはいけないってほとんど常識の部類だと思ったんだけど
そう油断して基本設計でわざわざ明記しなかったことがこの事故につながったのか。とても良くわかった
Re:あまりにもお粗末 (スコア:1)
Re:あまりにもお粗末 (スコア:2, すばらしい洞察)
実際ログイン後でも毎回その情報が利用されサーバ側から読み込まれる口座情報が変化するアホな仕様だったって事ですねぇ
確かに本質的な間違いはURLにあったとかGETだったとかPOSTだったとかでなく、ログイン認証後の口座情報識別を毎回させていた事にあるように受け取れます
#誰か気付けよ
Re:あまりにもお粗末 (スコア:1, すばらしい洞察)
そもそもPOSTよりもログに残りやすいってのがあるけど、
決定的なのは、SSL通信の時に大きな差がでるね。
Re:あまりにもお粗末 (スコア:2, 参考になる)
決定的なのは、SSL通信の時に大きな差がでるね。
出ますかね?
SSL通信時って、HTTPS通信時ってことですよね?少なくとも、URLのドメイン名より後ろの部分は、暗号化された経路内を流れるから、POSTだろうとGETだろうとPUTだろうと、口座番号が暗号化されているという点では違いが出ない気がしますが。
画面を後ろから覗き見される危険性が、現実的には一番大きいんじゃないかと。
Re: (スコア:0)
Proxy通すとよく判りますよね
CONNECT:XXXXXX(XXXXはアクセス先のホスト名)しかログに残らない
フィルタを通過してしまうので、ネットワーク管理者泣かせでは
あるかもしれず
Re: (スコア:0)
Re:あまりにもお粗末 (スコア:1)
でも口座番号は秘密情報なのかな?
フォームを見れば口座番号のフォーマットはわかります。
企業のウェブサイトには普通に取引口座の番号が書いてありますよ。
口座番号をURLに載せないことによりセキュリティ上の何が担保されるんでしょう?
Re:あまりにもお粗末 (スコア:3, すばらしい洞察)
一般論としては、口座番号そのものはもちろん秘密情報ではないでしょう。口座番号だけ
分かっていても、出来るのは「その口座に振り込むこと」くらいですし。
問題は「口座番号が分かれば個人情報やクレジットカード情報にアクセスできる」システムを
作ってしまったことなわけで。
Re: (スコア:0)
>一般論としては、口座番号そのものはもちろん秘密情報ではないでしょう。
口座が分かれば差し押さえもできますし、ひろゆき氏 [wikipedia.org]みたいなケースではとっても大事な秘密情報じゃないでしょうか?
Re:あまりにもお粗末 (スコア:1)
いや、令状に基づく法の執行たる差押えと同列に語られても……
Re: (スコア:0)
Re:あまりにもお粗末 (スコア:1, おもしろおかしい)
「テスト完璧です」って言われるから困る。
設計/仕様=理解できない (スコア:1, 興味深い)
所謂、白紙から紙か何かにひとつのブツを
一応最初から最後まで完結したカタチで造った
事が人たちが多いから、その辺の、
「基本設計だとか仕様って言葉自体が、
理解不能=分からない人たちが多い」
ですよ、シゴトに限らず(合掌)
まぁ、ガンプラのフルコンプリートモデルさえ
1体も組み立てたことの無い人たちと一緒にシゴト
した時は、さすがに、ツラかったですね(走召糸色木亥火暴)
"castigat ridendo mores" "Saxum volutum non obducitur musco"
Re: (スコア:0)
>#こういうのがあるから「JUnitのカバレッジ100%だから絶対大丈夫!」とか言われても信用できないんですよね
仕様がおかしいって話なのに、なんでカバレッジの話を持ってくるのか意味がわからん。
どこのどいつが、「カバレッジ」で「仕様」が問題ないことを「絶対大丈夫」とかほざくんだよ…
まぁ、そもそもプログラムのバグに関してでも
>「JUnitのカバレッジ100%だから絶対大丈夫!」
なんて発言するやつに出会った事ないけど…
しかも何故にJUnit限定?
Re: (スコア:0)
何と戦っているんだ?
仕様がおかしかったら、カバレッジなんか無意味だというだけの話だよね?
Re: (スコア:0)
>まぁ、そもそもプログラムのバグに関してでも
>>「JUnitのカバレッジ100%だから絶対大丈夫!」
>なんて発言するやつに出会った事ないけど…
どこかのフレームワークの信者がそのフレームワークの優位性をアピールするために、
ユニットテストのカバレッジが高いことを示していた事例があったと記憶している。
ソースを見てみたら、ゲッターやセッターがやたら多くて、
メソッドのカバレッジを底上げしていただけという絡繰りだったとか。
>しかも何故にJUnit限定?
そりゃ一番有名だからでしょ。べつに限定しているわけじゃない。