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

私が聞いたほとんどのセキュリティの脅威は、ソフトウェアのバグが原因で発生しました（たとえば、すべての入力が適切に健全性チェックされていない、スタックオーバーフローなど）。ソーシャルハッキングをすべて除外すると、すべてのセキュリティ上の脅威はバグによるものですか？言い換えると、バグがなければ、セキュリティ上の脅威はありませんか（再び、パスワードの開示などの人間の過失を除く）。または、バグが原因ではない方法でシステムを悪用できますか？

13 security  bug  hacking 

会社の公開サイトの1つに大きなセキュリティホールが見つかりました。これは、イントラネットサイトから変換された最初の公開サイトです。私はこの問題を上司に伝え、彼らは本質的に肩をすくめ、安全にサイトを再構築するにはかなりの労力が必要だと言った。 これは本当に私を悩ませており、実際のハッカーがそれに到達した場合にこれが起こる可能性のある効果を示すために穴を悪用することを考えました。これはおそらく、最良のアイデアではありません。何か悪いものではないとしても、その影響によって仕事にかかることがあります。 状況の大きさを経営者に示すためにできることは何ですか？

13 security  ethics 

SQLインジェクション攻撃で私が見たすべては、パラメータ化されたクエリ、特にストアドプロシージャのクエリが、このような攻撃から保護する唯一の方法であることを示唆しているようです。私が（暗黒時代に）働いていたとき、主に保守性が低いと見られていたため、ストアドプロシージャは貧弱なプラクティスと見なされていました。テスト可能性が低い。高度な結合; システムを1つのベンダーにロックしました。（この質問は他のいくつかの理由をカバーしています）。 私が働いていたとき、プロジェクトはそのような攻撃の可能性にほとんど気づいていませんでした。さまざまな種類の破損からデータベースを保護するために、さまざまなルールが採用されました。これらのルールは次のように要約できます。 クライアント/アプリケーションは、データベーステーブルに直接アクセスできませんでした。 すべてのテーブルへのすべてのアクセスはビューを介して行われました（ベーステーブルへのすべての更新はトリガーを介して行われました）。 すべてのデータ項目にドメインが指定されていました。 データ項目をNULL可能にすることは許可されませんでした-これは、DBAが時々歯を磨くという意味がありました。しかし、強制されました。 ロールと権限が適切に設定されました-たとえば、ビューのみにデータを変更する権限を与える制限されたロール。 SQLインジェクション攻撃を防ぐために、このような（強制的な）ルールのセット（必ずしもこの特定のセットである必要はありませんが）は、パラメーター化されたクエリの適切な代替手段ですか？そうでない場合は、なぜですか？データベースは、データベース（のみ）固有の手段によって、このような攻撃から保護できますか？ 編集 質問の強調は、受け取った最初の回答に照らして、わずかに変わりました。基本質問は変更されていません。 EDIT2 パラメータ化されたクエリに依存するアプローチは、システムに対する攻撃に対する防御の周辺ステップにすぎないようです。より根本的な防御が望ましいと思われ、特にインジェクション攻撃から防御する場合でも、そのようなクエリへの依存は不要であるか、それほど重要ではないようです。 私の質問に暗示されているアプローチは、データベースの「装甲」に基づいており、それが実行可能なオプションであるかどうかはわかりませんでした。さらなる研究は、そのようなアプローチがあることを示唆しています。このタイプのアプローチへのポインタを提供する以下のソースを見つけました。 http://database-programmer.blogspot.com http://thehelsinkideclaration.blogspot.com これらのソースから取得した主な機能は次のとおりです。 広範なセキュリティデータディクショナリと組み合わせた広範なデータディクショナリ データディクショナリからのトリガー、クエリ、および制約の生成 コードを最小化し、データを最大化する これまでの回答は非常に有用であり、パラメータ化されたクエリを無視することから生じる困難を指摘していますが、最終的には元の質問に回答しません（太字で強調されています）。

13 design  security  sql  sql-injection 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 安全でないパスワードを選択するユーザーの権利を制限することを考えています（長さによって決定されるパスワードの安全性、使用される文字の種類（大文字/小文字、数字、記号など）、および使用できるかどうか）レインボーテーブルにあります）、侵害された場合にアカウントが受ける損害を制限します。 このアイデアのアプリケーションはまだありませんが、フォーラムなどを書いています：1234をパスワードとして使用するユーザーは、投稿する前にキャプチャを入力するか、厳格なスパム対策の対象となる場合がありますコンテンツを拒否するタイムアウトまたはベイジアンフィルターとして。このフォーラムが非常に階層的であり、モデレーターまたは何らかの手段による「昇格」を許可する場合、これは、それらが特権を獲得するのを阻止するか、特権を持っていることを伝えますが、より安全なものに変更せずにそれらを行使させませんパスワード。 もちろん、これはセキュリティの唯一の尺度となることはできませんが、それ以外の場合は適切なセキュリティプラクティスの次にうまくいくかもしれません。 どう思いますか？これは無理をして、より重要なセキュリティ慣行からフォーカスを奪い取っているのでしょうか、それともリスクを制限し、ユーザーに安全なパスワードの使用を促す良い方法ですか？

13 security  passwords  authorization  risk  permissions 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 現在、ほとんどの一般的なアプリケーションでは、メールによるアカウントのアクティベーションが必要です。開発したアプリを使ったことがないので、重要なセキュリティ機能が欠けていますか？ メールのアクティベーションとは、サイトに登録すると、アカウントがアクティベートされる前にクリックする必要があるリンクを含むメールを送信することを意味します。

13 security  email 

私たちは新しいプロジェクトに取り組んでおり、2人の主任開発者であり、トークンを使用してサーバーとクライアント間の通信を保護する方法の岐路に立っています。 最初の提案：（ワンタイムトークンAKAスタティックトークン） クライアントは、ユーザー名とパスワード、およびcurrent_time（この変数はサーバーのデータベースとクライアント側にも保存されます）をAPIに送信することによってプライマリトークンを要求し、サーバーは入力を解釈し、ハッシュトークンをレンダリングします（例： 58f52c075aca5d3e07869598c4d66648）はデータベースに保存し、クライアントに返します。 クライアントはプライマリトークンを保存し、プライマリトークン+認証要求で送信されたcurrent_time変数を使用して新しいハッシュトークンを作成します（この新しいトークンmain_tokenを呼び出します）。また、サーバーも同じことを行い、同じアルゴリズムを使用して同じトークンを作成します。 クライアントがサーバーAPIを照会するたびに、main_tokenをサーバーに送信します。サーバーは、その中で生成されたトークンをクライアントが送信したmain_tokenと比較します。一致する場合、ユーザーは本物であることを意味します。 2番目の提案：（動的トークン） クライアントは2つのランダムキーを生成します（$ key1 = rand（10000,90000）; $ key2 = rand（10000,90000）;）APIの各リクエストで、クライアントはクエリタイプを使用してハッシュを作成し、複雑なアルゴリズム、およびこれらの2つのキー+ハッシュをサーバーに送信します サーバーは、クライアントで使用されるものと同じアルゴリズムを使用してハッシュを作成し、クライアントが送信したものと比較します。一致する場合、サーバーはクエリの処理に進みます さて、質問は、APIリクエストを保護するために使用する最も論理的で安全な方法はどれですか？

13 security  api 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 高度なプログラミング言語の十分にテストされ、実証されたAPIを使用するのではなく、ハードウェアに密接に接触することから生じる多くのセキュリティリスクがあります。Javaなどの言語よりもCでバッファオーバーフローを引き起こす方がはるかに簡単です。 すべてのCプログラマが知っておくべきリスクまたは脆弱性（バッファオーバーフローなど）とは何ですか（Cプログラマに関連するIEの脆弱性）。これらはどのような問題につながる可能性がありますか？それらを回避する方法、およびプログラムでこれらを発生させる一般的な間違いは何ですか？

13 c  security  low-level  vulnerabilities 

約10年間、私はSQL Serverデータストアを使用して社内のさまざまなデスクトップクライアントアプリケーションに取り組んできました。これらのプロジェクトを開始したことはほとんどありませんでした。ほとんどは買収作業です。 どこでも一定のように思われることの1つは、このアプリケーションが使用する単一のグローバルSQL Serverユーザーアカウントがあり、それが共通データベースへのアクセス許可を付与しsaたことです。 。 アプリケーションがデータベースへのアクセスに使用するこのユーザー名とパスワードを実際に非表示にすることはできません。通常、ファイルに保存されているiniかconfig、実行可能ファイル自体に焼き付けられています。いずれの場合も、少し掘り下げればユーザーに表示されます。あるケースでは、実際にconfigファイルを使用して暗号化しましたが、もちろん暗号化キーを実行可能ファイルに保存する必要がありました（この制限にナイーブではありませんでしたが、十分に精通している人をいじるのを効果的に阻止しました）configファイルを検索します）。 これらのシステムはすべて、アプリケーションに組み込まれたユーザー認証システムを備えていましたが、もちろん、すべてアプリケーション自体で管理されていました。つまり、ユーザー情報はデータベースに保存されていました。アプリケーションは、アクセスレベルに基づいて実行できることを制限していましたが、データベースに接続してアドホッククエリを実行できる場合は、あらゆる意味で意味がありません。 この問題を回避するために他のシステムが何をするかを知りたいです。私が知っているオプションは次のとおりです。 SQL Serverのセキュリティメカニズムを使用してユーザーとロールのリストを管理し、デスクトップアプリケーションにT-SQLクエリを介してユーザーを追加および削除させます。 データベースに直接接続する代わりに、サーバー上で実行される何らかの種類のWebサービスを作成し、そこに認証ロジックを配置します。すべてのリクエストにセキュリティ検証を実行させます。 ユーザーをデータベースから分離しているため、ユーザーは最上級のエンティティではなく、外部キー関係などでそれらを参照できないため、最初のオプションは少しいです。 2番目は、大きなパフォーマンスの問題のように思えますが、多くの余分な作業があり、さらに、NHibernateのようなORMマッパーを簡単に使用することはできません（と思います）。 誰でもこれを経験していますか？ベストプラクティス？ 編集 もう少し考えて、SQL Server認証は実際にこの問題を解決できますか？たとえば、タイムシートを編集できるようにユーザーがタイムシートレコードを挿入および更新できる必要がある場合、SQLサーバーがタイムシートの詳細テーブルの他の行へのアクセスを禁止する方法はありません。つまり、他の人のタイムシートも読み書きできます。

12 database  security 

プログラムの作成者であるあなたは、おそらくセキュリティの脆弱性と潜在的なハッキングを知っている誰よりも優れた立場にいるでしょう。作成したシステムの脆弱性を知っている場合、リリース前にセキュリティを強化する兆候を追加する必要がありますか、それともケースごとに評価してセキュリティギャップの重大度を判断する必要がありますか？

12 security  release 

今日、マネージャーから質問がありました。特に、一般的なユーザー名とパスワードのログインフィールドの「パスワードを記憶」する多くの一般的なブラウザーの性質に関して、Webフォームアプリケーションの認証に適したデザインとは何ですか。 受け入れられると思う答えを見つけるのに苦労しています。ソニーの恥ずかしいセキュリティ上の欠陥に照らして、人々に保存されているデータの感度は低くても、私は本当に注意したいです。社会保障番号や住所すら保存していませんが、電話番号、メールアドレス、訪問者の写真を保存しています。 彼は、ユーザーが単純にパブリック端末でパスワードを記憶でき、誰かがこの端末にジャンプして、不正な方法でデータの表示または変更を開始できることを心配しています。ただし、少なくともWindowsワークステーションでは、ブラウザーがWindowsユーザーアカウント間で「パスワードを記憶する」ことはありません。 これを超えて、サーバー側で一方向パスワード暗号化を実装しています（暗号化されたパスワードをデータベースに保存し、ユーザーが指定したパスワードをサーバーで暗号化し、データベースの暗号化された文字列と比較します）。SSL暗号化を組み込む直接的な計画はありませんが、これはまだオプションです。 このアプローチには重大なセキュリティ上の欠陥がありますか？より良い提案はありますか？

12 web-applications  security  browser  authentication 

新しいRESTful Webサービスを設定していますが、役割ベースのアクセス制御モデルを提供する必要があります。ユーザーがユーザー名とパスワードを入力してサービスにアクセスできるようにするアーキテクチャを作成し、役割に基づいてサービスの使用方法（使用できるサービス、読み取りvs読み取り/書き込みなど）を制限する必要がありますそのユーザーに割り当てられます。 私は他の質問を見て回り、欲しいものを見つけました。たとえば、資格情報をRESTサービスのrestful-authenticationに渡す方法、ベストプラクティスを扱う方法については、いくつかの素晴らしい議論があります。また、プログラマーがWebサイトを作成するときに知っておくべきこと（すべての開発者が公開Webサイトを構築する前に知っておくべきこと）についての優れた指針もあります。 しかし、これらのソリューションを実装するソフトウェアアーキテクチャのベストプラクティスとパターンに関する優れた投稿、記事、書籍を見つけることができませんでした。 具体的には： ユーザーの詳細とアクセス権はどのように保存する必要がありますか？（データモデル、場所、形式） サーバーでこれらを表現および追跡するための優れた設計パターンは何ですか？（メモリ内のセッション、毎回のデータベース検索など） コードベースでこれらの権利を安全な方法でサービスにマッピングするための良いパターンは何ですか？ システムをより安全で信頼性の高いものに保つのに役立つアーキテクチャの選択肢は何ですか？ トレンチから学んだことは何ですか？ 特定の技術以外のソフトウェアアーキテクチャの設計パターンと推奨事項を探しています。 （テクノロジーが重要な場合は、python、twisted、およびpostgresqlデータベースを使用してこれを実装する予定です）

12 web-development  design-patterns  security  web-services  rest 

プレーンテキストで保存できないパスワードなどのハッシュ値にソルト値を追加する場合、ソルト値を取得するのに最適な場所はどこですか？コンテキストのために、これがWebページログインのパスワード用であると仮定します。

12 security  hashing 

ユーザーを識別するために、ユーザー名よりもメールを使用した登録ログインの方が良いでしょうか？

12 security  user-interface  front-end 

より堅牢な認証サービスを実装したいのですが、やりたいことのjwt大部分を占めています。コードの記述方法は理解していますが、予約済みissとaudクレームの違いを理解するのに少し問題があります。1つはトークンを発行しているサーバーを定義し、1つは使用を目的としたアプリケーションを指していることを理解しています。しかし、私の聴衆と発行者が同じものであることを私が理解している方法は、myserver.com来た人myserver.comが承認され認証されるようにトークンを発行することです。2つのクレームの違いはわかりませんが、1つあることは知っています。 で書かれた良い記事がありましたmsdn すべての予約済みのクレームで、発行者とオーディエンスが完全に異なっていたため、最も混乱しました。

12 security  authentication  authorization  jwt 

パスワードがハッシュされて保存されている場合、パスワードをリセットしようとすると、パスワードが最後のパスワードと似ていることをコンピューターはどのように知るでしょうか？1つはハッシュ化され、元に戻すことはできないため、2つのパスワードはまったく異なりませんか？

11 database  security  hashing  passwords