2017-07-14 10 views
2

私のピラミッドアプリでは、(プロダクションではなく、テスト/デバッグのための)任意のユーザーとしてログインできると便利です。私の通常のログインプロセスは、ハッシュされたパスワードに対する単純なbcryptチェックです。ピラミッド/ wsgi os.environバックドアのセキュリティへの影響?

ユーザーが提出したバグレポートを複製すると、sqliteデータベースを複製し、全員のパスワードを固定ストリング(ローカルテストのみ)に変更する単純なスクリプトを実行すると便利だとわかりました。これで、あまり便利ではないpostgresqlに切り替えるので、私はログイン機能にバックドアをインストールすることを考えています。

基本的には、特定の変数 'debug'に対して、os.environ(mod_wsgiを通じてApacheによってロードされるdebug.wsgiファイルから設定)をチェックしたいと考えています。存在する場合は、パスワードチェックをバイパスして、任意のパスワード(任意のユーザー)を使用してログインを許可します。

このセキュリティの意味は何ですか?私が理解しているように、wsgiファイルはapacheがロードされるときに一度ソースされるため、production.wsgiファイルでその特定の変数が設定されていない場合、攻撃者(または無能なユーザー)がスプーフィングする可能性はありますか?

+0

あなたは 'ALLOW_LOGIN_WITH_EMPTY_PASSWORD'のような明示的な名前をつけ、それがアクティブなときに正しいパスワードでログインしないようにする必要があります。どうにかして何が達成されるのか分かりません。なぜなら、とにかくデータベースをクローンする必要があるからです。パスワードの設定はSQLiteと同じくらい簡単です。 (コピーを入手する前に、自動化されたプロセスによって他の機密情報を削除する必要があります) – Ryan

+0

ありがとうございますが、これは実際に直接的なセキュリティの影響には対応していません。 –

+0

これは、より具体的な命名を提案することによって、あなたの「無能なユーザー」シナリオを解決します。 「攻撃者」は、まずは意味をなさない。 – Ryan

答えて

1

環境内でそのデバッグ機能を使用してサーバーアプリケーションをインスタンス化するには、攻撃者はWebサーバーを管理する権限が必要です。

外部プロセスから、攻撃者は少なくともデバッグ機能とメモリの書き換えに適したペイロードなしで、メモリにロードされている実行中のサーバーの環境を変更することはできません。サーバーをリロードしたり、サーバー内でスクリプトを実行したりする方が簡単です。

あなたはあなたが安全に行くと思います。編集的な人は、バックドアをビルドからプロダクションに分離(削除)してください。

関連する問題