オブジェクトをシリアル化/ピクルし、圧縮された文字列としてエンコードし、次のページの URL にパラメーターとして渡して逆シリアル化します。私の Web アプリにはデータベースがありません。私がこれを行っているのは、アプリが遅い外部 Web サービスからデータを取得するためです。
これは受け入れられる慣行ですか?これはセキュリティ上のリスクですか? これを安全にする方法はありますか?
オブジェクトをシリアル化/ピクルし、圧縮された文字列としてエンコードし、次のページの URL にパラメーターとして渡して逆シリアル化します。私の Web アプリにはデータベースがありません。私がこれを行っているのは、アプリが遅い外部 Web サービスからデータを取得するためです。
これは受け入れられる慣行ですか?これはセキュリティ上のリスクですか? これを安全にする方法はありますか?
ビュー間でデータを共有する必要がある場合は、セッションで行います。それがセッションの目的です。セッション情報はデフォルトでデータベースに保存されますが、そうである必要はありません。ファイルシステム、キャッシュ システム (memcache、Redis など)、または署名付き Cookie (Django 1.4+ のみ) を使用することもできます。
見る:
これはセキュリティ上のリスクですか?
使用しているシリアライゼーションがピクルの場合、ドキュメントで示唆されているように、それは間違いなく問題です:
信頼できない、または認証されていないソースから受け取ったデータを unpickle しない
安全な静的値 (JSON など) を保持するためだけに設計されたシリアル化の形式を使用します。
hmacなどを使用して MAC で署名することにより、クライアント側に送信する値を改ざんから保護できます。ユーザー名やタイムスタンプなどの他のプロパティを MAC 署名データに追加して、署名されたデータ ブロックが自由に交換可能になるのを防ぐことを検討する必要がある場合があります。
値がクライアント側のユーザーによって表示および解釈されないようにする必要がある場合は、署名に加えて暗号化アルゴリズム (たとえば、AES - stdlib の一部ではない) を使用する必要があります。
(私はまだ、MAC 署名付きで暗号化された pickle を個人的には信用していません。悪用可能にするためにはサーバー側の秘密を漏洩する必要がありますが、情報漏えいの脆弱性が恣意的なものにエスカレートすることは本当に望んでいません。 -コード実行の脆弱性、これは pickle が表すものです。)
URL パラメータ フィールドがサーバー ログに表示されるため、これは最適なオプションではありません。POST メソッドを使用してデータを送信するか、基本的なデータベースを作成して (他に何もアクセスできない場合は、Sqlite を使用して)、ID を次の画面に渡す方がよいでしょう。