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

Reactチュートリアルでこれを読みました。これは何を意味するのでしょうか？ 反応は安全です。HTML文字列は生成しないため、XSS保護がデフォルトです。 Reactが安全な場合、XSS攻撃はどのように機能しますか？この安全はどのようにして達成されますか？

108 reactjs  security  xss 

IIS7から「サーバー」応答ヘッダーを削除する方法はありますか？HttpModulesを使用して同じことを達成できることを示すいくつかの記事があります。これは、サーバーに対する管理者権限がない場合に役立ちます。また、ISAPIフィルターを記述したくありません。 サーバーに対する管理者権限があります。だから私は上記のものをやりたくない。それで、私が同じことをするのを手伝ってください。

107 security  iis-7  header  response 

ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 PokerPirateと呼ばれる新しいオープンソースのポーカーボットがあります。私は、Webアプリケーションがポーカーボットを検出/阻止/無効化できる創造的な方法に興味があります。（これは、PokerPirateが書かれたのと同じ精神で、純粋に学術的な議論です。）

107 security  artificial-intelligence  poker 

ボブは何かを達成するためにWebアプリケーションを使用します。そして： 彼のブラウザはダイエット中であるため、クッキーをサポートしていません。 Webアプリケーションは人気があり、特定の瞬間に多くのユーザーに対応します。適切にスケーリングする必要があります。セッションを維持することが同時接続数に制限を課し、そしてもちろん無視できないパフォーマンスのペナルティをもたらす限り、私たちはセッションのないシステムを持ちたいかもしれません:) 重要な注意事項： 我々は持っているトランスポート・セキュリティ（HTTPSとその親友が）。 カーテンの裏側では、Webアプリケーションは現在のユーザーに代わって多くの操作を外部サービスに委任します（これらのシステムはBobをユーザーの1人として認識します）。つまり、Bobの資格情報を転送する必要があります。 では、どのようにしてボブを認証するのですか（すべてのリクエストで）。そのようなことを実装する合理的な方法はどれでしょうか？ HTMLフォームの非表示フィールドを介して資格情報でテニスをする... ボールには資格情報（ユーザー名とパスワード）が含まれ、2つのラケットはそれぞれブラウザーとWebアプリケーションです。つまり、Cookieではなくフォームフィールドを介してデータをやり取りする場合があります。各Web要求で、ブラウザーは資格情報を投稿します。ただし、1ページのアプリケーションの場合、これはテニスではなく、ゴムの壁でスカッシュをするように見えます。これは、資格情報を含むWebフォームがWebページの存続期間全体にわたって維持される可能性があるためです。 （サーバーは、資格情報を返さないように構成されます）。 ユーザー名とパスワードをページのコンテキストに保存する-JavaScript変数など。ここでは単一ページが必要、IMHO。 暗号化トークン-ベースの認証。この場合、ログインアクションにより、暗号化されたセキュリティトークン（ユーザー名+パスワード+その他）が生成されます。このトークンはクライアントに返され、今後のリクエストにはトークンが付随します。これは理にかなっていますか？すでにHTTPSを使用しています... その他... 最後の手段：これを行わないで、資格情報をセッションに保存してください！セッションはいいです。クッキーの有無にかかわらず。 以前に説明されたアイデアのいずれかに関して、Web /セキュリティの懸念が思い浮かびますか？例えば、 タイムアウト - 資格情報とともにタイムスタンプを保持する場合があります（タイムスタンプ=ボブが資格情報を入力した時間）。たとえば、NOW-timestamp> thresholdの場合、リクエストを拒否する可能性があります。 クロスサイトスクリプティング保護-どのような違いもないはずですよね？ これを読んでくれてありがとう:)

107 security  authentication  session-cookies  stateless  cookieless 

バイナリファイルを暗号化したい。私の目標は、パスワードを持たないファイルをだれにも読まれるのを防ぐことです。 同じ鍵長のAESとBlowfishのどちらがより良いソリューションですか？攻撃者はファイルをクラックするための優れたリソース（ソフトウェア、知識、お金）を持っていると想定できます。

106 security  encryption  aes  blowfish 

最初にログインする必要があるWindowsアプリケーションを作成しています。 アカウントの詳細はユーザー名とパスワードで構成され、ローカルに保存する必要があります。 これはセキュリティの問題なので、同じコンピューターを使用している他の人がすべての人の個人データを見ることができません。 このデータを保存するための最良/最も安全な方法は何ですか？ データベースを使いたくないので、Resourceファイルをいくつか試してみました。 しかし、私はこれに少し慣れているので、自分が何をしているか、どこで解決策を探すべきか、完全にはわかりません。

106 c#  security  local 

私は、ある程度安全でなければならない、つまりコマンドのパラメーターを通じて安全なデータを渡さず、できれば一時ファイルを使用しないシェルスクリプトを書いています。コマンドの標準入力に変数を渡すにはどうすればよいですか？または、それが不可能な場合、そのようなタスクに一時ファイルを正しく使用するにはどうすればよいですか？

105 security  bash  stdin 

Google Authenticatorアプリケーションを使用して生成できるワンタイムパスワードを使用しようとしています。 Google認証システムの機能 基本的に、Google認証システムは2種類のパスワードを実装します。 HOTP -パスワードはに準拠して、各呼び出しで変更されることを意味HMACベースのワンタイムパスワード、RFC4226、および TOTP-時間ベースのワンタイムパスワード。（私の知る限り）30秒ごとに変更されます。 Google Authenticatorはオープンソースとしても利用できます：code.google.com/p/google-authenticator 現在のコード HOTPおよびTOTPパスワードを生成するための既存のソリューションを探していましたが、あまり見つかりませんでした。私が持っているコードは、HOTPの生成を担当する次のスニペットです。 import hmac, base64, struct, hashlib, time def get_token(secret, digest_mode=hashlib.sha1, intervals_no=None): if intervals_no == None: intervals_no = int(time.time()) // 30 key = base64.b32decode(secret) msg = struct.pack(">Q", intervals_no) h = hmac.new(key, msg, digest_mode).digest() o = ord(h[19]) & 15 h = (struct.unpack(">I", …

104 python  security  authentication  one-time-password  google-authenticator 

この質問は、クロスサイトリクエストフォージェリ攻撃のみに対する保護についてです。 具体的には：Originヘッダー（CORS）による保護は、CSRFトークンによる保護と同じくらい優れていますか？ 例： Aliceは、ブラウザーを使用して（Cookieを使用して） " https://example.com "にログインします。彼女は最新のブラウザを使用していると思います。 アリスが「https://evil.com」にアクセスし、evil.comのクライアント側コードが「https://example.com」への何らかの要求を実行します（従来のCSRFシナリオ）。 そう： Originヘッダー（サーバー側）をチェックせず、CSRFトークンもチェックしない場合、CSRFセキュリティホールがあります。 CSRFトークンをチェックすれば安全です（ただし、少々面倒です）。 Originヘッダーを確認する場合、evil.comのクライアント側コードからのリクエストは、CSRFトークンを使用する場合と同様にブロックする必要があります。ただし、evil.comのコードでOriginヘッダーを設定できる場合は除きます。 私は、W3C仕様がすべての最新のブラウザーで正しく実装されていると信頼できる場合（少なくとも、クロスオリジンリソースシェアリングのセキュリティを参照）、これはXHRでは不可能であることを知っています（できるでしょうか？） しかし、他の種類のリクエストについてはどうでしょう-例えばフォーム送信？script / img / ...タグをロードしますか？または、ページがリクエストを（合法的に）作成するために使用できる他の方法？それとも、いくつかの既知のJSハック？ 注：私は話していません ネイティブアプリケーション 操作されたブラウザ、 example.comのページのクロスサイトスクリプティングのバグ ...

103 javascript  security  cors  csrf 

私が読んでいる本でprintfは、単一の引数（変換指定子なし）は非推奨であると書かれています。代用をお勧めします printf("Hello World!"); と puts("Hello World!"); または printf("%s", "Hello World!"); 誰かがなぜprintf("Hello World!");間違っているのか教えてもらえますか？本には、脆弱性が含まれていると書かれています。これらの脆弱性は何ですか？

102 c  security  printf  format-specifiers  puts 

私は、維持しているアプリケーションの1つに対応するRESTful APIの構築に取り組んでいます。現在、より制御されたアクセスとセキュリティを必要とするさまざまなものを組み込むことを検討しています。APIをセキュリティで保護する方法を調査しているときに、どのフォームを使用するかについていくつかの異なる意見を見つけました。HTTP-Authが最適な方法であると言うリソースもあれば、APIキーを好むリソースもあれば、OAuthで誓う他のリソース（私がSOで見つけた質問を含む）もありました。 そしてもちろん、APIキーなどを好む人は、OAuthがユーザーの代わりにアクセス権を取得するアプリケーション向けに設計されていると言っています（私が理解しているように、Facebookアカウントを使用してFacebook以外のサイトにサインインするなど）。特にサインアップしたサイトのリソースに直接アクセスするユーザー（Twitterサーバーにアクセスする公式のTwitterクライアントなど）ではありません。ただし、OAuthの推奨事項は、最も基本的な認証ニーズにも当てはまるようです。 では、私の質問は-すべてがHTTPS経由で行われるとすると、3つの間の実際的な違いは何ですか？いつ他の人よりも考慮すべきですか？

101 security  api  restful-authentication 

私はPHPセッション処理についていくつかの調査を行っておりsession.gc_maxlifetime、1440秒という値に遭遇しました。なぜ標準値が1440であり、それがどのように計算されるのか疑問に思っていましたか？この計算の根拠は何ですか？ セッションを続けることはどのくらい意味がありますか？session.gc_maxlifetimeのどの最小値/最大値をお勧めしますか？値が高いほど、Webアプリがセッションハイジャックに対して脆弱であると私は思います。

101 php  security  session 

の力について学べば学ぶほど、java.lang.reflect.AccessibleObject.setAccessibleそれが何をすることができるかに驚いています。これは私の質問への私の回答から転用されています（リフレクションを使用して、単体テストの静的な最終File.separatorCharを変更します）。 import java.lang.reflect.*; public class EverythingIsTrue { static void setFinalStatic(Field field, Object newValue) throws Exception { field.setAccessible(true); Field modifiersField = Field.class.getDeclaredField("modifiers"); modifiersField.setAccessible(true); modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); field.set(null, newValue); } public static void main(String args[]) throws Exception { setFinalStatic(Boolean.class.getField("FALSE"), true); System.out.format("Everything is %s", false); // "Everything is true" } } あなたは本当にとんでもないことをすることができます： …

100 java  security  reflection 

私がいることを実感OAuthの仕様は、特にトークン（ConsumerKey、ConsumerSecret、AccessToken、RequestToken、TokenSecret、または検証用コードの起源については何も指定しませんが、非常に安全なトークンを作成するための任意のベストプラクティスがある場合、私は好奇心が強いです/秘密の組み合わせ）。 私が見るように、トークンを作成するにはいくつかのアプローチがあります： ランダムなバイトを使用し、コンシューマー/ユーザーに関連付けられたDBに保存します 一部のユーザー/コンシューマー固有のデータをハッシュし、コンシューマー/ユーザーに関連付けられたDBに保存します ユーザー/消費者固有のデータを暗号化する （1）の利点は、データベースが最も安全と思われる唯一の情報源であることです。（2）や（3）よりも攻撃を行うのは難しいでしょう。 実際のデータ（2）をハッシュすると、おそらく既知のデータからトークンを再生成できます。とにかく保存/検索する必要があるので、（1）には実際には何の利点も提供しない可能性があります。（1）よりもCPUに負荷がかかります。 実際のデータを暗号化すると（3）、暗号化を解除して情報を知ることができます。これは、（1）と（2）よりも必要なストレージが少なく、検索数が少ない可能性がありますが、安全性も低くなる可能性があります。 考慮すべき他のアプローチ/利点/欠点はありますか？ 編集：別の考慮事項は、トークンに何らかのランダムな値が存在する必要があることです。これは、新しいトークンを期限切れにして再発行する機能が存在する必要があるため、実際のデータのみで構成されてはならないためです。 続く質問： 暗号的に非常に安全にするための最小トークン長はありますか？私が理解しているように、トークンシークレットが長いほど、より安全な署名が作成されます。この理解は正しいですか？ ハッシュの観点から、特定のエンコーディングを別のエンコーディングよりも使用する利点はありますか？たとえば、16進エンコーディング（GUID文字列など）を使用する多くのAPIが表示されます。OAuth署名アルゴリズムでは、トークンは文字列として使用されます。16進文字列を使用すると、Base64エンコーディングを使用する場合よりも、使用可能な文字セットがはるかに小さくなります（予測可能になります）。同じ長さの2つの文字列の場合、文字セットが大きい文字列ほど、ハッシュ分布が広くなります。これにより、セキュリティが向上すると思われます。この仮定は正しいですか？ OAuth仕様では、この問題が11.10 Entropy of Secretsで発生しています。

100 security  encryption  oauth  hash 

職場では、塩に関して2つの競合する理論があります。私が取り組んでいる製品は、ユーザー名や電話番号などを使用してハッシュをソルトします。基本的にユーザーごとに異なりますが、すぐに利用できます。他の製品はユーザーごとにランダムにソルトを生成し、ユーザーがパスワードを変更するたびに変更されます。ソルトはデータベースで暗号化されます。 私の質問は、2番目のアプローチが本当に必要かどうかです。純粋に理論的な観点からは、最初のアプローチよりも安全であることは理解できますが、実用性の観点からはどうでしょうか。現在、ユーザーを認証するには、ソルトを暗号化せずにログイン情報に適用する必要があります。 それについて考えた後、私はこのアプローチから実際のセキュリティの向上を見ることはありません。アカウントごとにソルトを変更すると、攻撃者が各アカウントのハッシュをすばやく特定する方法を知っていたとしても、ハッシュアルゴリズムをブルートフォースにしようとする試みが非常に困難になります。これは、パスワードが十分に強力であることを前提としています。（明らかに、すべてが2桁のパスワードのセットの正しいハッシュを見つけることは、8桁のパスワードの正しいハッシュを見つけるよりもはるかに簡単です）。私の論理が間違っていますか、それとも私が見逃しているものはありますか？ 編集：わかりましたので、ここで、ソルトを暗号化するのは本当に難しいと思う理由です。（私が正しい軌道に乗っているかどうかはわかります）。 以下の説明では、パスワードは常に8文字、saltは5文字で、すべてのパスワードが小文字で構成されていると仮定します（計算を簡単にするためです）。 エントリごとに異なるソルトがあると、同じレインボーテーブルを使用できません（実際には、十分なサイズの1つがあれば実際には技術的に使用できますが、今のところは無視します）。これは私が理解していることから、ソルトの本当の鍵です。すべてのアカウントをクラックするには、それぞれについて話すために、車輪を再発明する必要があるためです。ハッシュを生成するために正しいソルトをパスワードに適用する方法を知っている場合、ソルトはハッシュされたフレーズの長さ/複雑さを実際に拡張するだけなので、そうします。したがって、ソルトとは何かを知っているので、パスワードとソルトを "知っている"ために生成する必要がある組み合わせの数を13 ^ 26から8 ^ 26に削減します。今ではそれが簡単になりますが、それでも本当に難しいです。 ソルトの暗号化に移ります。ソルトが暗号化されていることがわかっている場合は、最初にそれを解読しようとはしません（十分なレベルの暗号化があることを前提として）。無視します。それを解読する方法を理解する代わりに、前の例に戻って、13 ^ 26のすべてのキーを含むより大きなレインボーテーブルを生成します。ソルトを知らないと間違いなく私は遅くなりますが、ソルトの暗号化を最初に解読しようとするという記念すべき仕事が増えるとは思いません。だからそれだけの価値はないと思います。考え？ 以下は、ブルートフォース攻撃を受けた場合のパスワードの保持期間を説明するリンクです。http： //www.lockdown.co.uk/？pg = combi

99 security  encryption  hash  brute-force