アカウント名:
パスワード:
>管理者向け画面のソース内に全ユーザーのものと思われるユーザー名、メールアドレス、「暗号化」されたパスワードが含まれていたというもの
これが本当なら、なんの目的でこんな作りにしたんだろう。「ソース画面」ってHTMLのソースって意味でいいんだよね?コメントにして画面では非表示にしてたってことなのかな。正直目的がさっぱりわからない。忘れたユーザーに復号して教えてあげるため?それにしてもちゃんとした暗号化すればよかったのに・・・
自分はいつもハッシュ化したものをDBに保存するけど、それを表示するページは作ったことないな。
人為的ミスでしょう。実際に見たとかじゃないので単なる予想ですが、DBがやたらアクセス制限しているせいで、DBの中身を見るためにクライアントを繋げることが困難(sshでトンネル張ればできるんだけど面倒)とかで、仕方ないのでクエリの結果をソースに書き込んで、ユーザー作成時にテーブルの中身が正常に更新されることを確認してた、とか。それで戻すの忘れ、テストでもソースまで見ないし誰も気づかないままリリースされて発覚に至る、的な。そんなとこでしょう。全ユーザーのユーザー名・パスワードがが含まれたっていうのはたまたまで同じページをデバッグ的な感じで使い回していたんじゃないかな、と予想。
バックエンドはFirebaseやで。なのでアクセス制限でガチガチなわけがない。
タレコミ人(#3635021) [srad.jp]が貼ってたのに消されたリンク [note.mu]の内容からすると、漏れるユーザはアクセスしたページに関連するユーザで、予測可能なURLだった管理画面からは全ユーザの情報が漏れていたっぽい。
ページ内スクリプトで必要なデータをページアクセスのリクエスト時にクエリして、結果を埋め込んでたんじゃ無いですかね。で、アクセス先ページで必要なユーザだけをユーザ情報テーブルから抽出するクエリは書いたけど、取得するカラム無制限にしてたとかでメールアドレスからパスまで全部ダンプされたと。
それにしてもちゃんとした暗号化すればよかったのに・・・
「暗号化したパスワード」をブラウザ側で復号可能であれば、暗号化したところで「ちょっと手間が増えるだけ」程度にしかならない。サーバから復号鍵を受け取るようにすればソースを見ただけでは復号できなくはなるけど、そんなことするならブラウザ側でハッシュと照合するようにした方が楽。
というわけで暗号化したパスワードをブラウザに送るのも無意味な気がするなぁ
CGIの類を設置するときに必ず毎回やる(おいこら)、スクリプトとして実行する設定がどこか抜けてて、アクセスするとソースコードが丸見えになるバグとかは? そして、password.jsonとかpassword.phpとかで保存していて、index.cgiかindex.phpから読み込む設定だったのが、それらのファイルも丸見えだったとか。
なんだかよく分からないままbase64使っちゃうような技術レベルの方々が何かやらかしてそれを自分たちなりの言葉で説明したこと、をきちんと読み解くのはほんとむつかしいな。先生なんぞやってると、そんな質問だらけだけど。
たぶん、暗号化何にするか未決定なのでとりあえずbase64で仮実装→直されずそのままこんな感じじゃないかな?#生テキストじゃなきゃ良いと思ってるのが役職に多い
元記事のSS画像を見るとJSON形式っぽいので、そのデータを使って何らかのユーザ管理の処理をする仕様だった気がする。本来は管理画面に入るためにBasic認証とかをかけとかなきゃいけないのに、それが抜けてて丸見えになってたという稀によくあるパターンじゃないかと。ここまでへっぽこな仕様で情報流出をしてると、何をやらかしても不思議ではないから困る。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
目的はなんだろう (スコア:0)
>管理者向け画面のソース内に全ユーザーのものと思われるユーザー名、メールアドレス、「暗号化」されたパスワードが含まれていたというもの
これが本当なら、なんの目的でこんな作りにしたんだろう。
「ソース画面」ってHTMLのソースって意味でいいんだよね?コメントにして画面では非表示にしてたってことなのかな。
正直目的がさっぱりわからない。忘れたユーザーに復号して教えてあげるため?それにしてもちゃんとした暗号化すればよかったのに・・・
自分はいつもハッシュ化したものをDBに保存するけど、それを表示するページは作ったことないな。
Re:目的はなんだろう (スコア:2)
人為的ミスでしょう。実際に見たとかじゃないので単なる予想ですが、
DBがやたらアクセス制限しているせいで、DBの中身を見るためにクライアントを繋げることが困難(sshでトンネル張ればできるんだけど面倒)とかで、仕方ないのでクエリの結果をソースに書き込んで、ユーザー作成時にテーブルの中身が正常に更新されることを確認してた、とか。それで戻すの忘れ、テストでもソースまで見ないし誰も気づかないままリリースされて発覚に至る、的な。そんなとこでしょう。全ユーザーのユーザー名・パスワードがが含まれたっていうのはたまたまで同じページをデバッグ的な感じで使い回していたんじゃないかな、と予想。
Re: (スコア:0)
バックエンドはFirebaseやで。
なのでアクセス制限でガチガチなわけがない。
Re: (スコア:0)
タレコミ人(#3635021) [srad.jp]が貼ってたのに消されたリンク [note.mu]の内容からすると、
漏れるユーザはアクセスしたページに関連するユーザで、
予測可能なURLだった管理画面からは全ユーザの情報が漏れていたっぽい。
ページ内スクリプトで必要なデータをページアクセスのリクエスト時にクエリして、
結果を埋め込んでたんじゃ無いですかね。
で、アクセス先ページで必要なユーザだけをユーザ情報テーブルから抽出するクエリは書いたけど、
取得するカラム無制限にしてたとかでメールアドレスからパスまで全部ダンプされたと。
Re: (スコア:0)
それにしてもちゃんとした暗号化すればよかったのに・・・
「暗号化したパスワード」をブラウザ側で復号可能であれば、暗号化したところで「ちょっと手間が増えるだけ」程度にしかならない。
サーバから復号鍵を受け取るようにすればソースを見ただけでは復号できなくはなるけど、そんなことするならブラウザ側でハッシュと照合するようにした方が楽。
というわけで暗号化したパスワードをブラウザに送るのも無意味な気がするなぁ
Re: (スコア:0)
CGIの類を設置するときに必ず毎回やる(おいこら)、スクリプトとして実行する設定がどこか抜けてて、アクセスするとソースコードが丸見えになるバグとかは? そして、password.jsonとかpassword.phpとかで保存していて、index.cgiかindex.phpから読み込む設定だったのが、それらのファイルも丸見えだったとか。
なんだかよく分からないままbase64使っちゃうような技術レベルの方々が何かやらかしてそれを自分たちなりの言葉で説明したこと、をきちんと読み解くのはほんとむつかしいな。先生なんぞやってると、そんな質問だらけだけど。
Re: (スコア:0)
たぶん、暗号化何にするか未決定なのでとりあえずbase64で仮実装→直されずそのまま
こんな感じじゃないかな?
#生テキストじゃなきゃ良いと思ってるのが役職に多い
Re: (スコア:0)
元記事のSS画像を見るとJSON形式っぽいので、そのデータを使って何らかのユーザ管理の処理をする仕様だった気がする。
本来は管理画面に入るためにBasic認証とかをかけとかなきゃいけないのに、それが抜けてて丸見えになってたという稀によくあるパターンじゃないかと。
ここまでへっぽこな仕様で情報流出をしてると、何をやらかしても不思議ではないから困る。