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

暗号化とITセキュリティに関する質問。これは、コンピュータ、ネットワーク、またはデータベースのセキュリティです。

1
アカウントの作成中に、パスワードを自動的に生成してユーザーに送信するか、ユーザーが自分でパスワードを作成できるようにする方が良いでしょうか?
この質問は、私たちが取り組んでいるウェブサイトの「アカウントの作成」ページについて同僚と話し合っているときに今日出てきました。 私の同僚の意見では、登録をできるだけ迅速かつシームレスに行う必要があるため、ユーザーにメールを尋ねて残りを処理するだけです。 私はその意図に同意しますが、いくつかの懸念があります。 我々はパスワードを生成するので、我々は持っているパスワードが強い十分であることを確認する責任を 私の経験では、わかりにくいパスワードに直面したとき、ユーザーはそれを投稿に書き留める可能性が高い パスワードを書き留めていないユーザーは、パスワードを忘れる可能性が高いです。つまり、定期的に新しいパスワードを要求する必要があり、誰にとっても面白くない ただし、ユーザーが作成したパスワードの一般的な品質と、多くの人がすべて(「震え」)に同じパスワードを使用する傾向があるという事実を考えると、強力なパスワードを生成することが理にかなっていることがわかります。 私はまだそれについて不安を感じています。ユーザーがクレジットカードの詳細を保存するオプションを持つ商人のウェブサイトに取り組んでいるので、最も安全なアプローチを使用することが明らかに非常に重要です。

3
デスクトップアプリケーションは、Webサービスの前にどのようにリモートサーバーと通信しましたか?
デスクトップアプリケーションにはあまり慣れていませんが、クライアントサーバーデスクトップアプリを作成する必要がある場合、データアクセスはWebサービスを介して行われます。Webサービスを介したデータアクセスはセキュリティを提供すると考えています。dbサーバーのユーザー名やパスワードなどを渡す必要はありません。 Webサービスの前、データベースアプリケーションはこれをどのように行っていましたか?すべての重要なdb情報がデスクトップアプリのインストールに渡されましたか?もしそうなら、プログラマはどのようにセキュリティの側面を管理しましたか?または、プログラマーはWebサービスに似たものを使用しましたか?

3
クライアント側のWebアプリケーションに秘密データを安全に保存する
すべてのクライアント側テクノロジー(HTML、CSS、JavaScript / AngularJSなど)になるこのWebアプリケーションがあります。このWebアプリケーションは、データにアクセスして変更するためにREST APIと対話します。現時点では、REST APIが使用する認証システムの種類については未定です。 私の理解では、あらゆる種類のAPI認証システム(APIキー、OAuth 1/2など)には特定のデータが含まれる必要があり、そうしないとアクセスが危険にさらされる可能性があります。APIキーの場合、キー自体は秘密である必要があり、OAuth 2の場合、クライアントのシークレット/アクセストークン/リフレッシュトークンを秘密にする必要があります。OAuth1に含まれる4つのキーのいくつかは秘密にする必要があります。 OAuthの経験が多すぎる1)。サーバーサイドに中間層を配置せずに、純粋なクライアントサイドのWebアプリケーションにこの秘密のものを保存する方法があるかどうか考えていました。 私はこれについて考えようとしてきましたが、それを行う場所は考えられません。誰でもソースを表示したり、コンソールを開いてデータを取得したりできるため、JavaScriptに保存することはできません。localStorageの安全性と、ユーザーがそのデータにアクセス/変更できるかどうかは100%わかりません。ローカルストレージが安全であったとしても、そこにデータを取り込む2つの方法は考えられません。一つの方法は、私が考えることができる最も安全でないものであるjavascriptソースコードにデータを保存することです。残りのapi自体がトークンを提供するOAuth 2のようなものを使用している場合、トークンはプレーンテキストとして返されるため、これらのトークンは(最初のオプションよりも)安全ではありません。コンピューターが行っているリクエストは見ることができます。 クライアント側で完全に実行されているアプリケーションに、サーバー側の中間層を使用せずに、機密データを安全に保存できる方法はありますか?

10
セキュリティ制限により、サービスがnullを返すか、例外をスローする必要がありますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はこの問題に関して、より経験豊富な開発者と少し意見の相違があり、他の人がそれについてどう思うか疑問に思っています。私たちの環境は、Java、EJB 3、サービスなどです。 私が書いたコードは、物を取得して物を作成するサービスを呼び出します。私が遭遇した問題は、意味をなさないヌルポインタ例外を受け取ったことです。たとえば、サービスにオブジェクトの作成を依頼すると、nullが返されます。既知の有効なIDを持つオブジェクトを検索しようとすると、nullが返されます。私は自分のコードで何が間違っていたのかを理解しようといくつかの時間を費やしました。私は経験が少ないので、私は通常、何か間違ったことをしたと思いますが、nullリターンの理由はセキュリティであることがわかります。私のサービスを使用しているユーザープリンシパルがターゲットサービスに対する適切なアクセス許可を持っていなかった場合、単にnullを返します。ここにある他のほとんどのサービスもあまり文書化されていないので、明らかにこれはあなたが知っておくべきことです。 これは、サービスと対話するコードを作成する開発者としてはかなり混乱します。サービスに例外があり、ユーザーにこの物をロードしたり、物を作成したりするための適切なアクセス許可がないことを教えてくれるなら、それは私にとってはるかに理にかなっています。そうすると、サービスが期待どおりに機能しなかった理由がすぐにわかります。 サービスを書いた経験豊富な開発者は、データの要求はエラー状態ではなく、例外はエラー状態でのみスローされるべきであり、ユーザーがデータにアクセスできないときではないと主張しました。このデータは多くの場合GUIで検索され、適切な権限のないユーザーの場合、これらは単に「存在しません」。要するに、質問は間違っていないため、例外ではありません。これらのユーザーには「存在しない」ものがあるため、getメソッドはnullを返します。ユーザーがそのモノを作成することを許可されなかった場合、Createメソッドはnullを返します。 これは正常なものですか?何が起こっているのかを知るのがずっと簡単だと思うので、例外を使うことを好みます。そのため、たとえば、nullを返すのではなく、無効なIDを持つオブジェクトを要求した場合にNotFoundExceptionをスローすることも好みます。

7
ログには決して表示してはならない情報は何ですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 ログ(アプリケーションのトレース)に表示してはならないものについて、会社のガイドラインを作成しようとしています。実際には、一部の開発者は、トレース内のできるだけ多くの情報として含めるようにしようと、それは危険なこれらのログを保存すること、およびそれらを提出する非常に危険な彼女は、この気にしませんので、お客様は、この情報が格納されている知っていない場合は特に、ドキュメントや警告メッセージを決して読んでいない。 たとえば、ファイルを処理する場合、一部の開発者はファイルの名前をトレースしたいと思われます。たとえば、ファイル名をディレクトリに追加する前に、エラー時にすべてをトレースすると、たとえば、追加された名前が長すぎること、およびコードのバグが連結された文字列。これは役立ちますが、これは機密データであり、決してログに表示してはいけません。 同じやり方で: パスワード、 IPアドレスとネットワーク情報(MACアドレス、ホスト名など)¹、 データベースアクセス、 ユーザーおよび保存されたビジネスデータからの直接入力 トレースに表示されることはありません。 それでは、他にどんな種類の情報をログから追放する必要があるのでしょうか?私が使用できるガイドラインはすでに書かれていますか? ¹明らかに、私はIISやApacheのログなどについて話をしているのではありません。私が話しているのは、信頼されていないエンティティのアクティビティを追跡するのではなく、アプリケーション自体をデバッグすることだけを目的として収集される情報です。 編集:回答とコメントをありがとう。私の質問はあまり正確ではないので、コメントで尋ねられた質問に答えようとします。 ログで何をしているのですか? アプリケーションのログはメモリに保存される場合があります。つまり、ローカルホストのハードディスクにプレーンで、データベースに、プレーンに、またはWindowsイベントに保存されます。すべての場合において、懸念はそれらのソースが十分に安全でないかもしれないということです。たとえば、顧客がアプリケーションを実行し、このアプリケーションがログを一時ディレクトリのプレーンテキストファイルに保存すると、PCに物理的にアクセスできる人は誰でもそれらのログを読むことができます。 アプリケーションのログはインターネット経由でも送信できます。たとえば、顧客がアプリケーションに問題がある場合、このアプリケーションをフルトレースモードで実行し、ログファイルを送信するように依頼できます。また、一部のアプリケーションは、クラッシュレポートを自動的に送信する場合があります(そして、機密データに関する警告がある場合でも、ほとんどの場合、顧客はそれらを読みません)。 特定の分野について話していますか? いいえ。一般的なビジネスアプリケーションのみに取り組んでいるので、機密データはビジネスデータのみです。特定の規制の対象となる健康やその他の分野に関連するものはありません。しかし、それについてお話しいただきありがとうございます。おそらく、ガイドラインに含めることができるものについての手がかりを得るために、これらのフィールドを見てみる必要があります。 データを暗号化する方が簡単ではありませんか? いいえ。特にC#診断とを使用する場合は、すべてのアプリケーションが非常に難しくなりTraceSourceます。また、承認を管理する必要がありますが、これは最も簡単なことではありません。最後に、顧客から提出されたログについて話している場合、機密データにアクセスすることなく、ログを読み取ることができる必要があります。したがって、技術的には、機密情報をログに一切含めず、それらのログがどのように、どこに保存されているかを気にすることは簡単です。

5
管理者ユーザーが他のユーザーとしてログインできるようにする
管理者ユーザーがパスワードをバイパスして別のユーザーとしてログインできるようにする可能性を実装することは良い習慣だと思いますか?これは、マスターパスワードまたはユーザー管理内の機能「このユーザーとしてログイン」によって実装できます。 管理者は、報告された問題の再現を試行したり、許可が許可されているかどうかを確認したりするために、そのような機能を要求しています。

5
ソフトウェアの脆弱性に対する攻撃/ツールのソフトウェアライフサイクルの固有の側面は何ですか?
私の地元の大学には、約20人の学生からなる小さな学生向けコンピューティングクラブがあります。クラブには、モバイル開発、ロボット工学、ゲーム開発、ハッキング/セキュリティなど、特定の分野に重点を置いた小さなチームがいくつかあります。 ユーザーストーリー、タスクの複雑さの見積もり、バージョン管理と自動ビルド/テストの継続的な統合など、いくつかのチームにいくつかの基本的なアジャイル開発コンセプトを紹介しています。 ウォーターフォール、スパイラル、RUP、アジャイルなど、いくつかの基本的な開発ライフサイクルに精通していますが、セキュリティをハッキング/侵害するためのソフトウェア開発ライフサイクルのようなものがあるのだろうかと思っています。確かに、ハッカーはコンピュータコードを書いていますが、そのコードのライフサイクルは何ですか?いったん違反が発見されてパッチが適用されると、その違反を悪用したコードは役に立たなくなるので、彼らがメンテナンスにあまり関心を持つことはないと思います。 ライフサイクルは次のようになると思います: セキュリティのギャップを見つける セキュリティのギャップを悪用する ペイロードの調達 ペイロードを利用する 製品の目的がセキュリティ違反である場合、ソフトウェアの開発ライフサイクルにはどのような違いがありますか(ある場合)?

3
OAuth2フロー-サーバーは認証サーバーで検証されますか?
私はOAuth2で頭を悩ませようと何度も読んでいましたが、それでも何か混乱しています。 クライアントがOAuthプロバイダー(Googleなど)を承認し、リソースサーバーがユーザーのプロファイルデータにアクセスできることを理解しています。その後、クライアントはアクセストークンをリソースサーバーに送信し、リソースを返すことができます。 しかし、どのドキュメントでもカバーされていないように見えるのは、クライアントアプリがリソースサーバーにリソースを要求し、それにアクセストークンを渡したときに何が起こるかです。これまでに読んだことはすべて、リソースサーバーが要求されたリソースで応答するだけであると述べています。 しかし、それは巨大な穴のようです。確かにリソースサーバーはアクセストークンを何らかの方法で検証する必要があります。そうしないと、古い要求を偽造して、古い、盗まれた、偽の、またはランダムに生成されたトークンを渡すだけで、それを受け入れるだけです。 これまでに読んだものは不完全だと感じるので、誰でも簡単にOAuth2の説明に従うことを私に向けることができますか?
10 security  oauth2 

4
開発者はマルウェアの研究から何かを学ぶことができますか?[閉まっている]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 マルウェアは、マルウェア対策ソフトウェアなどから身を隠すための興味深い手法を使用しています。彼らは自分自身を「変化」させることができます。それは実行中のマシンとほとんど同じ意味を持ちながら、実際にコードを変更し、アンチウイルス定義を無効にするなどです。 (悪意のない)開発者がそのソースを研究することから学ぶことができるものがあるかどうか、またはソースを利用できない場合にそれらを逆にしてそのプロセスから得られるものを研究することはありますか?レルム。 マルウェアを書くことに興味はありません。(少なくとも非教育目的ではありません)この質問は、マルウェアの作成方法などの質問ではなく、作成済みのマルウェアから何を学ぶことができるかという質問ではありません。 また、おそらく非倫理的だと思います(そうではないと思います)。脆弱性/エクスプロイト/セキュリティ、または基盤となるオペレーティングシステムをよりよく理解するために、独自のマルウェアを作成することで何か利益がありますか?

3
セキュリティ会社のプログラマーは何をしますか?
クライアントシステムのセキュリティについて相談するセキュリティ会社を聞いたことがあります。私がこの分野で知っている人はすべてネットワークエンジニアですが、プログラマーもセキュリティに関与していることは知っています。監査/コンサルティングを行うセキュリティプログラマは実際に何をしますか?彼らは文字通り、人々のレガシーシステムのすべての脆弱性を探すコードベースを通過しますか?私はいつもそれが彼らのしたことだと思っていましたが、これは非常に信頼性が低く、誤った安心感を提供する以上のことはしないようです。注:私は、暗号化アルゴリズムなどを書くプログラマーについてではなく、ソフトウェアのセキュリティ監査/コンサルティングに関係するプログラマーについてのみ話します。

7
ビューでのセキュリティ条件文の使用はMVCの違反ですか?
多くの場合、ユーザーに表示されるもの(Webページなど)は、部分的にセキュリティチェックに基づいています。私は通常、ユーザーレベルのACLセキュリティをシステムのビジネスロジックの一部と見なしています。ビューがセキュリティを明示的にチェックして条件付きでUI要素を表示する場合、ビジネスロジックを含むことでMVCに違反していますか?

2
APIの不正使用を回避するにはどうすればよいですか?
「ウィジェット」、つまりパートナーがWebサイトに埋め込んで、UIを表示し、APIを呼び出すスクリプトを設計する必要があります。 基本的に、API呼び出しで提供するいくつかのIDに基づいて、これらのサイトのデータを表示します。回避したいのは、誰かがAPIを悪用し、それを使用してカタログ全体をこすり取ることです。 スクリプトを埋め込む各パートナーには、APIを呼び出すときに提供する必要がある公開鍵が与えられます。スクリプトをロードするときに、このキーを追加するように依頼することをお勧めします。例: <script src="//initrode.com/widget/loader.js?key=xxxx"></script> このようにして、スクリプトのリクエストを使用してキー/ソースIPペアを登録し、キー/ IPペアが登録されたものと一致する場合に限り、後続のAPI呼び出しに応答できます(ライフタイムが制限され、1日あたりのリクエスト数に制限があります)。 それは明らかに難読化によるセキュリティです(スクリプトを再読み込みすると完全にバイパスされます)。しかし、アクセスを制限する他の方法はありません。すべてのユーザーに一意のキーを提供することはできません。パートナーにのみ提供します。すべてのコードが誰でも利用できるようになるため、私は秘密鍵システムを使用できません。基本的に、パブリックAPIへのアクセスを制限しています。つまり、その定義が矛盾しています。 このソリューションについてどう思いますか、これらの制約をどうしますか?

9
ユーザー登録のための合理的で安全なパスワード要件は何ですか?
これは、UPSから入手したパスワードパッケージです(パッケージステータスのチェック用)。 パスワードの長さは8〜26文字にする必要があります。小文字、大文字、数字、特殊文字、スペースの3つ以上の文字タイプを含める必要があります。パスワードには、ユーザーID、名前、または電子メールアドレスが含まれていない場合があります。(SSO_1007) 私は実際にこのパスワードを生成するために多少脳を壊さなければなりませんが、それだけでなく、最も重要なことに、3日後にはこのパスワードが何であるか忘れてしまうことでしょう。ユーザーはそれほど幸せではありません。パスワードのリセットは頻繁に行われる可能性があります。ユーザーは、必要がない限り、サイトの使用を避けようとするでしょう。 ウェブサイトをセットアップするときの合理的で安全なパスワードポリシーとは何ですか?企業によっては、ハッカーがパスワードを100万回以上試行するのを恐れている可能性があるため、「特殊文字、小文字、大文字」の要件をすべて追加していますが、アカウントをオフにするか、単にパスワードを使用して、ユーザーが30回または100回試行した場合にパスワードのリセットを要求する または、ユーザーが30回試行した後、毎回5秒の遅延を追加しますか?その場合、それらの特殊文字はそれほど必要ありません。

2
Websocketクライアントから送信する場合、マスキングは本当に必要ですか
現在のWebsocket RFCでは、Websocket クライアントが送信時にフレーム内のすべてのデータをマスクする必要があります(ただし、サーバーは必須ではありません)。プロトコルがこのように設計された理由は、フレームデータがクライアントとサーバーの間の悪意のあるサービス(プロキシなど)によって変更されるのを防ぐためです。ただし、マスキングキーはまだそのようなサービスで認識されています(各フレームの先頭でフレームごとに送信されます)。 フレームを次のポイントに渡す前に、そのようなサービスがキーを使用してコンテンツのマスクを解除、変更、および再マスクできると仮定するのは間違っていますか?私が間違っていない場合、これはどのようにして想定される脆弱性を修正しますか?

2
3-Strike Securityの弱点
私はセキュリティ、特にパスワードセキュリティ/暗号化に関するいくつかの文献を読んでいて、疑問に思っていることが1つあります。3ストライクルールは、パスワードセキュリティの完璧なソリューションですか?つまり、パスワードの試行回数がいくつかの限られた数に制限されている場合、すべての認証要求が受け入れられなくなると、ユーザーの侵入を防ぐことができませんか?何かへのアクセスや制御を得ることは、常に認証システムを通過することを意味するわけではありませんが、この機能は辞書/総当たり攻撃を時代遅れにしないのですか?行方不明のものはありますか?
10 security 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.