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

?>ファイルの最後にPHPの終了タグを使用することはお勧めできません。ヘッダーの問題は、次のコンテキストでは無関係であるように見えます（これは、これまでのところ唯一の良い議論です）： 最新バージョンのPHPでは、php.iniにoutput_bufferingフラグが設定されています。出力バッファリングが有効になっている場合、返されたコードはすぐにはブラウザーに送信されないため、HTMLの出力後にHTTPヘッダーとCookieを設定できます。 すべての優れた実践書とwikiはこの「ルール」で始まりますが、誰も正当な理由を提供しません。 終了PHPタグをスキップする別の理由はありますか？

374 php  security  http-headers 

IISのWebサイトにhttpsをインストールするには、.pfxファイルが必要です。 証明書（.cerまたはpem）と秘密キー（.crt）の2つのファイルがありますが、IISは.pfxファイルのみを受け入れます。 私は明らかに証明書をインストールし、それは証明書マネージャー（mmc）で利用可能ですが、証明書のエクスポートウィザードを選択すると、PFX形式を選択できません（グレー表示されます）。 それを行うためのツールまたはそれをプログラムで行うC＃の例はありますか？

363 windows  security  iis  certificate  ssl-certificate 

ライセンスキーは、著作権侵害対策としての事実上の標準です。正直なところ、これは私に（in）Security Through Obscurityのように感じますが、ライセンスキーがどのように生成されるのかは本当にわかりません。ライセンスキー生成の良い（安全な）例は何ですか？彼らが使用している暗号プリミティブ（ある場合）は何ですか？メッセージダイジェストですか？もしそうなら、彼らはどのデータをハッシュするでしょうか？クラッカーが独自の鍵ジェネレータを作成するのを困難にするために、開発者はどのような方法を採用していますか？キージェネレータはどのように作られていますか？

361 security  cryptography  license-key 

1台のマシンで2つのHTTPサービスを実行しています。Cookieを共有しているかどうか、またはブラウザが2つのサーバーソケットを区別しているかどうかを知りたいだけです。

355 security  http  cookies 

リモートサーバーの証明書を取得しようとしています。これを使用してキーストアに追加し、Javaアプリケーション内で使用できます。 シニア開発者（休暇中:(）がこれを実行できることを私に知らせました： openssl s_client -connect host.host:9999 生の証明書をダンプして、それをコピーしてエクスポートできます。次の出力が表示されます。 depth=1 /C=NZ/ST=Test State or Province/O=Organization Name/OU=Organizational Unit Name/CN=Test CA verify error:num=19:self signed certificate in certificate chain verify return:0 23177:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1086:SSL alert number 40 23177:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: 私もこのオプションを試しました -showcerts そして、これ（debian mind youで実行） -CApath /etc/ssl/certs/ しかし、同じエラーが発生します。 このソースは、私はそのCApathフラグを使用することができると言いますが、助けにはならないようです。私は無駄に複数のパスを試してみました。 どこが悪いのか教えてください。

354 linux  security  certificate  openssl  ssl-certificate 

今朝、Firefoxブラウザーを最新バージョン（22から23に）にアップグレードすると、バックオフィス（Webサイト）の重要な側面のいくつかが機能しなくなりました。 Firebugログを見ると、次のエラーが報告されていました。 Blocked loading mixed active content "http://code.jquery.com/ui/1.8.10/themes/smoothness/jquery-ui.css" Blocked loading mixed active content "http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/jquery-ui.min.js"` 上記の2つのうち、後者がロードされていないことが原因で発生する他のエラー。 上記は何を意味し、それをどのように解決しますか？

350 http  security  firefox  https  mixed-content 

のINインスタンスでSQL 句を使用するための最良の回避策は何ですか？これは、java.sql.PreparedStatementSQLインジェクション攻撃のセキュリティ問題のため、複数の値に対してサポートされていません。1つの?プレースホルダーは、値のリストではなく1つの値を表します。 次のSQLステートメントについて考えてみます。 SELECT my_column FROM my_table where search_column IN (?) 使用することpreparedStatement.setString( 1, "'A', 'B', 'C'" );は?、そもそも使用する理由の回避策での、実際には機能しない試みです。 どのような回避策がありますか？

342 java  security  jdbc  prepared-statement  in-clause 

ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 Stack OverflowにCAPTCHAのサポートを追加する予定です。これは、ボット、スパマー、およびその他の悪意のあるスクリプト化されたアクティビティを防ぐために必要です。ここでは人間に物事を投稿または編集してもらいたいだけです！ 最初の防衛線として、JavaScript（jQuery）CAPTCHAを使用します。 http://docs.jquery.com/Tutorials:Safer_Contact_Forms_Without_CAPTCHAs このアプローチの利点は、ほとんどの人にとって、CAPTCHAが表示されないことです。 ただし、JavaScriptが無効になっている場合でも、フォールバックが必要であり、ここで注意が必要です。 ASP.NET用の従来のCAPTCHAコントロールを作成しましたが、これを再利用できます。 ただし、リクエストごとにサーバー上でこれらのすべての画像を作成するオーバーヘッドを回避するために、テキストを使用することをおすすめします。 のようなものを見てきました。 ASCIIテキストキャプチャ： \/\/(_)\/\/ 数学パズル：7マイナス3の2倍とは何ですか？ トリビアの質問：ヒキガエルとアイスキャンディーのどちらが良い味ですか？ たぶん私はここで風車を傾けているだけかもしれませんが<noscript>、可能であれば、リソースをあまり消費しない、画像ベースでない互換性のあるCAPTCHA を使用したいと思います。 アイデア？

318 security  language-agnostic  captcha 

Angular、Ember、Reactなどのフレームワークを使用してSPAスタイルのアプリケーションを構築する場合、認証とセッション管理のベストプラクティスは何だと思いますか？問題への取り組みを検討する方法はいくつか考えられます。 APIとUIのオリジンドメインが同じであると想定して、通常のWebアプリケーションでの認証と同じように扱います。 これには、セッションCookie、サーバー側セッションストレージ、およびおそらく認証済みWeb UIがヒットして現在のユーザー情報を取得し、パーソナライゼーションやクライアント側の役割/機能の決定に役立つ可能性があるいくつかのセッションAPIエンドポイントが含まれる可能性があります。もちろん、サーバーは引き続きデータへのアクセスを保護するルールを適用し、UIはこの情報を使用してエクスペリエンスをカスタマイズします。 パブリックAPIを使用するサードパーティのクライアントと同様に扱い、OAuthと同様のトークンシステムで認証します。このトークンメカニズムは、サーバーAPIに対して行われたすべてのリクエストを認証するためにクライアントUIによって使用されます。 私はあまり専門家ではありませんが、ほとんどの場合、＃1で完全に十分ですが、経験豊富な意見をいくつか聞きたいです。

308 security  angularjs  authentication  ember.js  single-page-application 

JWTを取得してペイロードをデコードできる場合、どのように安全ですか？ヘッダーからトークンを取得し、ペイロードのユーザー情報をデコードして変更し、同じ正しいエンコードされたシークレットで送り返すことはできませんか？ 安全である必要があることは承知していますが、実際にテクノロジーについて理解したいと思います。何が欠けていますか？

302 security  jwt  express-jwt 

私のサイトのすべての安全でないHTTPリクエスト（例http://www.example.com）をHTTPS（https://www.example.com）にリダイレクトしようとしています。私はPHPを使用しています。.htaccessでこれを行うことはできますか？

294 security  http  .htaccess  redirect  https 

保存する前にパスワードを2回ハッシュすることは、1回だけハッシュするよりも安全ですか？ 私が話しているのはこれを行うことです： $hashed_password = hash(hash($plaintext_password)); これだけではなく： $hashed_password = hash($plaintext_password); 安全性が低い場合、適切な説明（またはリンク）を提供できますか？ また、使用されるハッシュ関数は違いを生みますか？同じハッシュ関数を繰り返す代わりに、md5とsha1を（たとえば）混在させると、違いはありますか？ 注1：「ダブルハッシュ」とは、パスワードをよりわかりにくくするために、パスワードを2回ハッシュすることを指します。私は衝突を解決するためのテクニックについて話しているのではありません。 注2：本当に安全にするために、ランダムなソルトを追加する必要があることはわかっています。問題は、同じアルゴリズムで2回ハッシュすることがハッシュを助けるか傷つけるかです。

293 security  hash  passwords  cryptography  password-hash 

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 

HTTP GETをHTTP POSTと比較する場合、セキュリティの観点からの違いは何ですか？選択肢の1つは本質的に他の選択肢よりも安全ですか？もしそうなら、なぜですか？ POSTはURLの情報を公開しないことに気づきましたが、その中に本当の価値はありますか、それともあいまいなことによる単なるセキュリティですか？セキュリティが懸念される場合にPOSTを選択する必要がある理由はありますか？ 編集： HTTPSを介して、POSTデータはエンコードされますが、URLがサードパーティによって盗聴される可能性はありますか？さらに、私はJSPを扱っています。JSPまたは同様のフレームワークを使用する場合、POSTまたはGETに機密データをまとめて配置せず、代わりにサーバー側のコードを使用して機密情報を処理するのがベストプラクティスであると言っても過言ではないでしょうか。

282 html  security  http 

ASP.NET 4.0がインストールされたWindows Server 2008では、関連するユーザーアカウントが多数あり、どれがどのように異なり、どのように異なるのか、そして実際にアプリが実行されているのはどれなのかわかりません。ここにリストがあります： IIS_IUSRS IUSR DefaultAppPool ASP.NET v4.0 NETWORK_SERVICE ローカルサービス。 何が何？

282 asp.net  security  iis  user-accounts