タグ付けされた質問 「owasp」

5
「X-Content-Type-Options = nosniff」とは何ですか?
OWASP ZAPを使用してローカルホストで侵入テストを行っていますが、次のメッセージが報告され続けます。 Anti-MIME-SniffingヘッダーX-Content-Type-Optionsが「nosniff」に設定されていませんでした このチェックは、Internet Explorer 8とGoogle Chromeに固有です。Content-Typeヘッダーが不明な場合は、各ページにContent-TypeヘッダーとX-CONTENT-TYPE-OPTIONSが設定されていることを確認してください これが何を意味するのか私にはわかりませんし、オンラインでも何も見つかりませんでした。追加しようとしました: <meta content="text/html; charset=UTF-8; X-Content-Type-Options=nosniff" http-equiv="Content-Type" /> しかし、私はまだアラートを受け取ります。 パラメータを設定する正しい方法は何ですか?

4
CSRF防止トークンをCookieに入れるのはなぜ一般的ですか?
CSRFの問題全体とそれを防ぐための適切な方法を理解しようとしています。(私が読み、理解し、同意したリソース:OWASP CSRF防止に関するチートシート、CSRFに関する質問) 私が理解しているように、CSRFに関連する脆弱性は、(Webサーバーの観点から)着信HTTPリクエストの有効なセッションCookieが認証済みユーザーの希望を反映しているという仮定によって導入されています。ただし、オリジンドメインのすべてのCookieはブラウザーによってリクエストに魔法のようにアタッチされているため、実際のサーバーは、リクエスト内の有効なセッションCookieの存在から、認証されたセッションを持つブラウザーからのリクエストであると推測できます。それはコードについて何も仮定することはできませんそのブラウザで実行している、またはそれが本当にユーザーの希望を反映しているかどうか。これを防ぐ方法は、リクエストに追加の認証情報(「CSRFトークン」)を含めることです。これは、ブラウザの自動Cookie処理以外の方法で行われます。大まかに言えば、セッションCookieはユーザー/ブラウザーを認証し、CSRFトークンはブラウザーで実行されているコードを認証します。 つまり、簡単に言うと、セッションCookieを使用してWebアプリケーションのユーザーを認証している場合は、各応答にCSRFトークンを追加し、各(変更)リクエストで一致するCSRFトークンを要求する必要があります。次に、CSRFトークンはサーバーからブラウザーへとサーバーからサーバーへの往復を行い、要求を行っているページがそのサーバーによって承認されている(生成されている)ことをサーバーに証明します。 私の質問に戻ります。これは、その往復でそのCSRFトークンに使用される特定の転送方法についてです。 (AngularJS、Django、Railsなどで)CSRFトークンをサーバーからクライアントにCookieとして(つまり、Set-Cookieヘッダーで)送信し、クライアントのJavascriptでCookieから削ってそれを添付するのが一般的ですサーバーに送り返す別のXSRF-TOKENヘッダーとして。 (別の方法は、たとえばExpressによって推奨される方法です。サーバーによって生成されたCSRFトークンは、サーバー側のテンプレート拡張を介して応答本文に含まれ、サーバーに戻すコード/マークアップに直接添付されます。非表示のフォーム入力として。この例は、よりWeb 1.0風の方法ですが、より一般的なJSの重いクライアントに一般化されます。 CSRFトークンのダウンストリームトランスポートとしてSet-Cookieを使用するのはなぜそれほど一般的ですか。なぜこれが良いアイデアなのでしょうか。これらすべてのフレームワークの作成者がオプションを慎重に検討し、これを間違えなかったと思います。しかし、一見したところ、基本的にCookieの設計上の制限を回避するためにCookieを使用することは、お粗末なようです。実際、ラウンドトリップトランスポートとしてCookie(サーバーの下流にSet-Cookie:ヘッダーがブラウザにCSRFトークンを通知し、ブラウザにそれをサーバーに返すようにCookie:ヘッダーを上流に送信する)を使用した場合、脆弱性が再導入されます。修正しようとしています。 上記のフレームワークは、CSRFトークンのラウンドトリップ全体でCookieを使用しないことに気づきました。彼らはSet-Cookieダウンストリームを使用し、次に他の何か(X-CSRF-Tokenヘッダーなど)をアップストリームに使用します。これにより、脆弱性が排除されます。ただし、ダウンストリームトランスポートとしてSet-Cookieを使用しても、誤解を招く可能性があり、危険です。これで、ブラウザはCSRFトークンをすべての要求に添付し、本物の悪意のあるXSRF要求を含みます。せいぜい要求が必要以上に大きくなり、最悪の場合でも意味のあるサーバーコードの一部が実際にそれを使用しようとする可能性があり、これは本当に悪いことです。さらに、CSRFトークンの実際の受信者はクライアント側のJavascriptであるため、このCookieをhttpのみで保護することはできません。
283 security  cookies  web  csrf  owasp 

9
PHP $ _SERVER ['HTTP_HOST']対$ _SERVER ['SERVER_NAME']、manページを正しく理解していますか?
多くの検索を行い、PHPの$ _SERVERドキュメントも読みました。私のサイト全体で使用されている単純なリンク定義のPHPスクリプトに何を使用するかについて、この権利はありますか? $_SERVER['SERVER_NAME'] これは、Webサーバーの構成ファイル(私の場合はApache2)に基づいており、(1)VirtualHost、(2)ServerName、(3)UseCanonicalNameなどのいくつかのディレクティブによって異なります。 $_SERVER['HTTP_HOST'] クライアントからのリクエストに基づいています。 したがって、私のスクリプトをできるだけ互換性のあるものにするために使用する適切なものは、私には思えます$_SERVER['HTTP_HOST']。この仮定は正しいですか? フォローアップコメント: この記事を読んだ後、私は少し偏執狂になったと思いますが、一部の人々は「彼らはどの$_SERVER変数も信用しないだろう」と述べました: http://markjaquith.wordpress.com/2009/09/21/php-server-vars-not-safe-in-forms-or-links/ http://php.net/manual/en/reserved.variables.server.php#89567(コメント:Vladimir Kornea 14-Mar-2009 01:06) どうやら議論は主に$_SERVER['PHP_SELF']、なぜXSS攻撃を防ぐために適切にエスケープせずにフォームアクション属性でそれを使用すべきでないかについてです。 上記の私の元の質問についての私の結論は$_SERVER['HTTP_HOST']、フォームで使用されている場合でも、XSS攻撃を心配する必要なく、サイト上のすべてのリンクに使用しても「安全」であるということです。 私が間違っていたら訂正してください。
167 php  apache  security  owasp 

6
ローカルストレージを安全と見なすことはできますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する オフラインで長期間機能するWebアプリケーションを開発する必要があります。これを実行可能にするために、機密データ(個人データですが、ハッシュ化して保存するだけの種類のデータではありません)をローカルストレージに保存することは避けられません。 これは推奨される方法ではないことを受け入れますが、データを保護するために次のようにしています。 スタンフォードのjavascript暗号ライブラリとAES-256を使用して、ローカルストレージに入るすべてのものを暗号化する ユーザーパスワードは暗号化キーであり、デバイスに保存されていません sslを介して単一の信頼されたサーバーから(オンラインのときに)すべてのコンテンツを提供する owasp antisamyプロジェクトを使用して、サーバーのローカルストレージとの間のすべてのデータを検証する *を使用せずにappcacheのネットワークセクションで、信頼されたサーバーとの接続に必要なURIのみを一覧表示する 一般に、OWASP XSSチートシートで提案されているガイドラインを適用しようとする 私は悪魔がしばしば詳細にあることを感謝し、ローカルストレージとJavaScriptベースのセキュリティ全般について多くの懐疑論があることを知っています。誰もが存在するかどうかについてコメントできますか: 上記のアプローチの根本的な欠陥? そのような欠陥の可能な解決策はありますか? html 5アプリケーションが長期間オフラインで機能する必要がある場合にローカルストレージを保護するより良い方法はありますか? 助けてくれてありがとう。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.