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

私はセキュリティに重点を置いたWebアプリケーションを開発しています。アプリケーションで作業するユーザー（プログラマー、DBA、品質保証スタッフ）が、パスワード、社会保障番号など、十分に保護する必要があるユーザー入力値をキャプチャしないようにするには、どのような対策を講じることができますか？

10 security 

クライアントの権限と役割に関する情報をJWTに含める必要がありますか？ JWTトークンにそのような情報があると、有効なトークンが来るたびに非常に役立つため、ユーザーに関する権限に関する情報を抽出するのが簡単になり、データベースを呼び出す必要もありません。しかし、そのような情報を含め、データベースで同じことをダブルチェックしないことは、セキュリティの問題でしょうか？ または、 上記のような情報はJWTの一部ではなく、データベースのみを使用してユーザーのアクセスロールとアクセス許可を確認する必要がありますか？

9 security  authentication  jwt 

私は、おそらく最終的にGoogle App Engine（GAE）にデプロイされるJava Webアプリの設計プロセスにいます。GAEの良い点は、恐ろしいDDoS攻撃からアプリを強化することを本当に心配する必要がないことです。「請求上限」を指定するだけで、トラフィックがこの上限（DDoSまたはそれ以外）に達すると、GAEアプリをシャットダウンします。言い換えると、GAEは、アプリを実行し続ける余裕がなくなるまで、基本的に任意の量にスケーリングされます。 したがって、私は、この請求の上限に達し、GAEがアプリをシャットダウンした場合、WebアプリドメインのDNS設定が別の非GAE IPアドレスに「フェイルオーバー」するような不測の事態を計画しています。一部の初期の調査では、CloudFlareなどの特定のCDNがこの正確な状況に対応するサービスを提供していることが示されています。基本的に、私はDNS設定を保持するだけで、フェイルオーバー手順を自動化するために使用できるAPIを提供します。したがって、GAEアプリの請求上限が99％になっていることを検出した場合、このCloudFlare APIにアクセスできます。CloudFlareは、DNS設定を動的に変更して、GAEサーバーから他のIPアドレスを指すようにします。 私の最初の不測の事態は、おそらくGoDaddyまたはRackspaceによって他の場所でホストされているWebアプリケーションの「読み取り専用」（静的コンテンツのみ）バージョンにフェイルオーバーすることです。 しかし、それから突然私に気づきました。DDoS攻撃がドメイン名をターゲットにしている場合、GAE IPアドレスから（たとえば）GoDaddy IPアドレスにロールオーバーするとどのような違いがありますか？要するに、フェイルオーバーはDDoS攻撃者が私のバックアップ/ GoDaddyサイトをダウンさせること以外は何もしません！ 言い換えると、DDoS攻撃者は、GAEによってホストされている私のWebアプリへの攻撃を調整しますwww.blah-whatever.com。これは、実際にはIPアドレス100.2.3.4です。これにより、トラフィックが課金上限の98％に急上昇し、カスタムモニターが100.2.3.4から105.2.3.4へのCloudFlareフェイルオーバーをトリガーします。DDoS攻撃者は気にしません！彼らはまだ攻撃を仕掛けていwww.blah-whatever.comます！DDoS攻撃が続いています！ だから私は尋ねます：CloudFlareのようなCDNはどのような保護を提供するので-別のDNSにフェールオーバーする必要があるときに-同じ、継続的なDDoS攻撃の危険にさらされませんか？そのような保護が存在する場合、フェイルオーバーサイトに課されている技術的な制限（読み取り専用など）はありますか？そうでない場合、彼らは何が良いのですか？前もって感謝します！

9 java  web-applications  security  google-app-engine 

ユーザーの個人的な病気に関する情報を含むデータベースを設計する必要があります。 DBのテーブルの列を実装するためのアプローチは何ですか？情報を暗号化する、2つの異なるDB内でデータを分離する、1つは機密データ用、もう1つは機密データ用ではない、または両方または別のアプローチですか？

9 security  database-design  mysql 

Exchange 2010には委任モデルがあり、winrmコマンドレットのグループは本質的に役割にグループ化され、役割はユーザーに割り当てられます。 （画像ソース） これは、適切な低レベルのテクノロジ（WCF、SOAPなど）を使用し、クライアント側に追加のソフトウェアを必要とせずに、PowerShellのすべての利点をどのように活用できるかを考慮した、優れた柔軟なモデルです。 （画像ソース） 質問 .NETアプリケーションでExchangeの委任モデルを活用する方法はありますか？ このモデルを模倣しようとした人はいますか？ 最初から始めなければならない場合、このアプローチを模倣するにはどうすればよいですか？

9 c#  security  wcf  authorization  iis7 

柔軟かつ簡単に（そのようなものが存在する場合）実装すると同時に、可能であれば組み込みの手段を利用する必要がある これまでのところ、MembershipProviderとRoleProvidersを実装しています。これはかっこいいですが、次にどこに行きますか？ 「特権」という用語を追加し、アプリケーション内にハードコードする必要があるように感じます。ユーザーは、特権を役割に追加し、役割をユーザーに割り当てるように役割を構成します。 それは良いモデルのように聞こえますか？ロールに追加することに加えて、ユーザーレベルで特権を追加することを検討する必要がありますか？セットアップ（混乱）と次のサポートに問題があると思います。 そうしないと、一部の特定のユーザーにはより少ない特権が必要になります-管理者は別のロールを作成する必要があります。 このようなシステムの特効薬はありますか？そして、なぜMicrosoftはメンバーシップとロールプロバイダーよりも先に進まなかったのですか？ 別のアイデア：ロールを「特権」ホルダーのままにして、ハードコーディングします。次に、使用可能なすべてのマークアップ/属性などを使用して、アプリ内のこれらのロールをコード化できます-すべてMicrosoft。 新しいエンティティ「グループ」を追加し、このような関係を作成します ユーザー ユーザーグループ 団体 RoleGroups 役割 この方法で、ロールをグループにまとめ、それらのグループをユーザーに割り当てることができます。素晴らしいサウンドで、他のソフトウェアパターンと一致します。しかし、実際にはRoleProvider内に次のようなものを実装することはできません。 AddUsersToRoles RemoveUsersFromRoles そして、ハードコーディングされるため、いくつかのものが実際にはもう意味をなさない DeleteRole CreateRole

9 design-patterns  security 

コーディングの際、コードが本来意図されていない方法で悪用され、保護された情報にアクセスしたり、コマンドを実行したり、ユーザーにしたくない何かを積極的に考えたりしませんか？

9 security 

ITコンサルタントは、クライアントのコード/データを保護するために、どのような状況でハードドライブを暗号化する必要がありますか？ それがあなたの仕事の負荷に多くを追加しない場合、あなたがラップトップが盗まれた場合でも、たとえ誰かがあなたのラップトップが盗まれたとしても、誰かがあなたのメールファイルや他のドキュメントにアクセスするのを少なくとも防ぐために「弱い」パスワードでフルディスク暗号化を使うのもよいと私は考えていますデータベースファイルやその他の非常に機密性の高いデータにはアクセスできません。

9 security 

密封されたjarファイルを作成しましたが、密封されていないjarファイルを使用した場合と比較して違いはありません。 瓶が密封されていることを確認するためにどのようなテストを実行できますか？ シールされていないものを使用することを好む理由は何ですか？ 封印すると、プロジェクトのユーザーに問題が発生しますか？

9 java  security 

背景から始めるために、この投稿はCSRFトークンについてJeff Atwoodが述べたものです。このページで、彼は続けて言っています： さらに強力ですが、より複雑な防止方法は、サーバーの状態を活用することです。つまり、クライアントに送信するすべてのHTMLフォームに対して一意のランダムキーを生成（およびタイムアウト付きで追跡）します。Stack Overflowでこのメソッドのバリアントを使用して、大きな成功を収めています。 しかし、この投稿自体では、Jeffはトークンをいつ、どのように更新する必要があるかについて決してコメントしていません。 私が取り組んでいるWebアプリで同様のテクニックを使用していました。それはこのように動作します： ユーザーがPOSTサーバーにデータを送信するたびに、csrfトークンが送信されます。 このCSRFトークンは、ユーザーのセッションで暗号的に強力なCookieに保存されます。 トークンが有効な場合は、ユーザーのリクエストが処理され、逆の場合も同様です。 リクエストが有効な場合は、サーバー側の古いトークンを破棄し、新しいトークンを作成します。サーバーからの応答には、次の要求で使用される新しいcsrfトークンが含まれています。ページ上のすべてのフォームの古いトークンが新しいトークンで更新されるため、次のリクエストが適切に処理されます。 トークンを更新してからPOSTリクエストするのが賢明ですか、それともユーザーがGETリクエストを行ったときにのみ更新を行い、次のGETリクエストが行われるまで同じトークンを保持する必要がありますか？

9 web-development  programming-practices  security  patterns-and-practices 

私はC＃で個人的なプロジェクトに取り組んでいますが、その目的は、ユーザーが他のユーザーが作成したスクリプトを実行して、そのスクリプトのアクセス許可を制限できるようにすることです。私のプログラムは、サードパーティのライブラリを使用してスクリプトをコンパイルし、.NETコードアクセスセキュリティメカニズムを使用してそれらをサンドボックス化し、ユーザーが付与したい権限のみがスクリプトにあることを確認します。 大まかに言って、私のセキュリティ要件は次のとおりです。 ユーザーは、信頼できないスクリプトのアクセスを、すべてのファイルシステムアクセスの禁止を含む、ファイルシステムの特定の部分のみに制限できる必要があります。 ユーザーは、信頼できないスクリプトのネットワーク接続を、すべてのネットワーク接続の禁止を含め、特定のIPアドレスまたはホスト名のみに制限できる必要があります。 ユーザースクリプトがホストアプリケーションをハングまたは終了させることができても問題ありませんが、ユーザースクリプトは権限の制限を回避できてはなりません（つまり、サービス拒否は問題ありませんが、違反は許されません）。 私は一種の個人的な演習として、C ++で同様のことをしようと考えています。明らかに、ユーザースクリプトがLuaのようなスクリプト言語で書かれている場合でも、ネイティブコードを直接実行すると、状況はさらに複雑になります。 最初に考えられるアプローチは、スクリプト環境の標準ライブラリ関数に独自のフックを挿入することです。たとえば、スクリプト言語がLuaの場合、io.openを通常に公開する代わりに、スクリプトの権限に対して引数をチェックするラッパーを公開してから、それらを元の実装に渡す必要があります。 このアプローチに対する私の懸念は、セキュリティを担当する自分自身のコードの量が大幅に増加することです。そのため、私が書いた潜在的なセキュリティの脆弱性があります。言い換えると、.NET CASを使用する場合、自分のサンドボックスコードを信頼する必要があるのではなく、Microsoftがサンドボックスコードでうまく機能したことを信頼できます。 私が知らない代替案はありますか？

8 c++  security 

このトピックはかなり取り上げられていますが、自分の特定の状況に対する答えを見つけることができません。 現在、私は.gitignore機密コンテンツを除外し、それ（構成ファイルなど）を個別に保持するために使用しています。私のコードベースがますます多くのプロジェクトに拡大するにつれて、これは管理が非常に難しくなり、変更を追跡したり、ファイルを適切にバックアップしたりする実際の方法もありません。 そこにこの問題のためのいくつかのツールのような、ではないgit-secret、Hashicorp Vaultとgit-crypt私は（さまざまな理由のために）私の開発のすべてを行うのWindows、これらの作品のどれも。 現在、私は自社内で作業する唯一の開発者であり、拡張する予定はありません。ソース管理（Gitlab）は、主に自分の参照と変更を記録する機能に使用されます。いくつかの接続文字列または構成ファイルをソース管理にプッシュすることは、大きな問題またはリスクになるでしょうか？その情報は現在、セキュリティで保護されていないネットワークドライブにあります（NTFSアクセス許可を除く） 私は、ベストプラクティスはこのようなものをソース管理にプッシュすることではないという考えを得ますが、ローカルネットワークの外部ではアクセスできないプライベートにホストされたGitlabインスタンスがあります-これはリスクが少ないことを意味しますか？

8 git  security 

存続期間の短いアクセストークンと存続期間の長いリフレッシュトークンを使用して、REST APIのトークンベースの認証システムを実装しています。これは、関連するAPIエンドポイントの抽象的な概要です（HTTPSはすべてのエンドポイントに適用されます）。 エンドポイント： POST /register/ POST /login/ POST /logout/ POST /password/change/ 実装： POST /register/： リクエスト：クライアントがユーザー名、メール、パスワードをJSONで送信します。 サーバーアクション： 入力を検証し、データベースにユーザーを作成します（ユーザーID、ユーザー名、電子メール、パスワードハッシュを格納します）。 JWT形式で短期間有効なアクセストークンを作成します（ユーザーID、発行日、有効期限が含まれます）。 長期間有効な更新トークンをUUID文字列として作成し、データベースに保存します（ユーザーIDと更新トークンを保存します）。 応答：サーバーはJSONでアクセストークンと更新トークンを返します。 POST /login/： リクエスト：クライアントはJSONでユーザー名とパスワードを送信します。 サーバーアクション： 入力を検証し、データベースをチェックして資格情報が有効かどうかをチェックします。 資格情報が有効な場合、前述のように、有効期間が短いアクセストークンと有効期間が長いリフレッシュトークンを作成します。 レスポンス：と同じで/register/、アクセストークンと更新トークンをJSONで返します。 POST /logout/： 要求：クライアントはヘッダー内の更新トークンをトークンAuthorizationとして送信しBearerます。 サーバーアクション： 更新トークンデータベースをチェックして、更新トークンを検証します。 データベースから更新トークンを削除します。 注：これにより、アクセストークンは有効なままになりますが、有効期間は短いため（1時間程度なので、問題ないはずです）。 応答：ログアウト要求がJSONで正常に処理されたかどうかを返します。 POST /password/change/： リクエスト：クライアントはアクセストークンをAuthorizationヘッダーとしてBearerトークンとして送信し、古いパスワードと新しいパスワードをHTTPS経由でJSONで送信します。 サーバーアクション： アクセストークンをデコードしてユーザーを取得し、ユーザーの古いパスワードをデータベースで確認します。 データベース内のユーザーのパスワードハッシュを新しいパスワードのハッシュに設定します。 リフレッシュトークンデータベース内のユーザーに関連付けられたすべてのリフレッシュトークンを削除して、基本的に既存のセッションをログアウトします（有効期間の短いアクセストークンを残します）。 応答：パスワード変更リクエストがJSONで正常に処理されたかどうかを返します。 質問： このアプローチは安全ですか？具体的には： HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？さらに、プログラムによるログインを防ぐにはどうすればよいですか？ 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？ クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？ リフレッシュトークンを保存するための1つのアイデアは、ユーザーがログインすると、リフレッシュトークンをクライアントに送信するだけでなく、サーバーがトークンをフラグHttpOnly付きのCookieに保存することsecureです。承認は引き続きAuthorizationヘッダーを介して行われますが、クライアントが最初に読み込まれるときにGET、Cookieに有効な更新トークンが含まれているかどうかを確認するリクエストをエンドポイントに送信でき、有効な更新トークンが含まれている場合はJSONでユーザーに返します。つまり、Cookieが実際に使用されるのは、Cookie内の更新トークンをクライアントに返すときだけです。このアプローチは安全ですか？Cookieからリフレッシュトークンを要求するときに副作用がないため、CSRFを防ぐことができると思いますが、攻撃者がリフレッシュトークンを傍受する別の方法があります（HTTPSを想定）？

8 design  rest  api  security  authentication 

ここでは、RESTful APIの認証と承認のメカニズムを扱う多くの質問がありますが、アプリケーションレベルで安全なサービスを実装する方法の詳細については触れていません。 たとえば、私のWebアプリケーション（Javaを念頭に置いていますが、これは実際にはすべてのバックエンドに当てはまります）に、APIのユーザーがユーザー名とパスワードでログインできる安全な認証システムがあるとします。ユーザーがリクエストを行うと、リクエスト処理パイプラインの任意の時点でgetAuthenticatedUser()、ユーザーがログインしていない場合はnullユーザー、またはログインしているユーザーを表すユーザードメインオブジェクトを返すメソッドを呼び出すことができます。 APIにより、認証されたユーザーはデータにアクセスできます。たとえば、GET /api/orders/はそのユーザーの注文リストを返します。同様に、GET to /api/tasks/{task_id}はその特定のタスクに関連するデータを返します。 ユーザーのアカウントに関連付けることができるいくつかの異なるドメインオブジェクトがあると仮定します（注文とタスクは2つの例であり、顧客、請求書などもある可能性があります）。認証されたユーザーだけが自分のオブジェクトに関するデータにアクセスできるようにしたいので、ユーザーがを呼び出すときは、ユーザーが/api/invoices/{invoice_id}そのリソースにアクセスすることを許可されていることを確認してから、サービスを提供します。 私の質問は、この承認の問題に対処するためのパターンや戦略は存在するのでしょうか。私が検討しているオプションの1つは、ヘルパーインターフェイス（つまりSecurityUtils.isUserAuthorized(user, object)）を作成することです。これは、リクエストの処理中に呼び出して、ユーザーがオブジェクトをフェッチすることを許可されていることを確認できます。これは、これらの呼び出しの多くでアプリケーションのエンドポイントコードを汚染するため、理想的ではありません。 Object someEndpoint(int objectId) { if (!SecurityUtils.isUserAuthorized(loggedInUser, objectDAO.get(objectId)) { throw new UnauthorizedException(); } ... } ...そして、少し面倒かもしれませんが、すべてのドメインタイプにこのメソッドを実装するという問題があります。これが唯一のオプションかもしれませんが、私はあなたの提案を聞いて興味があります！

8 java  rest  security  backend 

Webhook（Webカートから）からローカルのMicrosoft SQL Serverにデータを追加しようとしています。私にとって最良のルートは、PHPスクリプトを使用して新しいデータ（jsonとしてのPOST）をリッスンし、それを解析してから、クエリを実行してMSSQLに追加することです。 PHPスクリプト（共有ホストのWebサイトにあります）とローカルMSSQLデータベースの間の接続に関するセキュリティについてはよく知りません。PHPスクリプトを同じローカルホストで実行したままにします（ApacheをWindowsで実行します）が、WebhookのURIはパブリックにアクセスできる必要があります。 または、ローカルホストからスクリプトをスケジュールして、WebカートAPIを介して定期的に更新を確認することもできますが、私のようなアマチュアプログラマーにとってはWebhookの方が簡単です。 リモートの共有ホストでPHPを使用してローカルマシンのMSSQLに接続する場合、セキュリティを確保するためにどのような手順を実行できますか？

8 php  security  sql-server  server  server-security