アカウント名:
パスワード:
DBには保存してなくても、ついログに出力しちゃってたりする事もあるからほんと気をつけないとだめだよね。
うっかりどっかに残ってしまうのを防ぐアイデアってあるんだろうか。SQLインジェクション防ぐならプリペアードステートメント使うのがセオリーとかXSS防ぐならテンプレートエンジンを正しく使うとかそんなノリで。
Unixの伝統として、書ける権限あるなら読めるのが普通、って感覚が良くない気がする。ログなんて本当はアプリは書き込み権限だけでいいんだよ。
誤ってログに機密情報を出力してしまうのは、そのアプリの権限の問題ではないでしょう。
そもそも「書ける」ということは「書き込む情報を持っている」わけですから、書き込んだ先をアプリから読めなくしたところで意味がないです。
やるとすれば「ログも機密情報の一部とみなして、暗号化するか権限をきちんと設定する」になるのでは。
以前のプロジェクトでは、ログを含めDB以外に機密情報を出さないようにするため、受け入れ時にソースコードの静的解析ツールを走らせて、機密情報のクラスの何か(メソッド、フィールドほか)をログクラスのパラメータに与えているのを調べさせて、引っかか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
保存するつもりはなくても (スコア:0)
DBには保存してなくても、ついログに出力しちゃってたりする事もあるから
ほんと気をつけないとだめだよね。
うっかりどっかに残ってしまうのを防ぐアイデアってあるんだろうか。
SQLインジェクション防ぐならプリペアードステートメント使うのがセオリーとか
XSS防ぐならテンプレートエンジンを正しく使うとか
そんなノリで。
Re:保存するつもりはなくても (スコア:1)
Unixの伝統として、書ける権限あるなら読めるのが普通、って感覚が良くない気がする。
ログなんて本当はアプリは書き込み権限だけでいいんだよ。
Re: (スコア:0)
誤ってログに機密情報を出力してしまうのは、そのアプリの権限の問題ではないでしょう。
そもそも「書ける」ということは「書き込む情報を持っている」わけですから、
書き込んだ先をアプリから読めなくしたところで意味がないです。
やるとすれば「ログも機密情報の一部とみなして、暗号化するか権限をきちんと設定する」になるのでは。
以前のプロジェクトでは、ログを含めDB以外に機密情報を出さないようにするため、
受け入れ時にソースコードの静的解析ツールを走らせて、機密情報のクラスの何か(メソッド、フィールドほか)を
ログクラスのパラメータに与えているのを調べさせて、引っかか
Re: (スコア:0)
アホが書いたcommons loggingのアホな設定がコピペで蔓延してるだけだと思うぞ