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

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

7
推測不可能なプライベートURLはパスワードベースの認証と同等ですか?
Webでリソースを公開したい。このリソースを保護したい:特定の個人のみがアクセスできるようにするため。 何らかの種類のパスワードベースの認証を設定できました。たとえば、ファイルを提供する前に、(おそらくユーザーのバッキングデータベースに対して)正しい資格情報の着信要求をチェックするWebサーバーを介してのみ、リソースへのアクセスを許可できます。 または、プライベートURLを使用することもできます。つまり、単純に推測できないパスでリソースをホストできhttps://example.com/23idcojj20ijf...ます。たとえば、正確な文字列を知っている人にアクセスを制限します。 このリソースにアクセスしたい悪人の観点から見ると、これらのアプローチは同等ですか?そうでない場合、それらの違いは何ですか?そして、保守性に関しては、どちらか一方を実装する前に私が知っておくべきどちらかのアプローチに賛否両論はありますか?

7
セキュリティ集約型サイトの小さなバグを修正するために雇われています。コードを見ると、セキュリティホールがいっぱいです。職業はなんですか?[閉まっている]
誰かに雇われて、サイトでちょっとした仕事をしています。大企業向けのサイトです。非常に機密性の高いデータが含まれているため、セキュリティは非常に重要です。コードを分析すると、セキュリティホールで満たされていることに気付きました-読み取り、ユーザーのget / post入力をmysqlリクエストとシステムコマンドに直接投げる多くのPHPファイル。 問題は、彼のためにサイトを作った人は、その仕事に依存している家族や子供を持つプログラマーだということです。「あなたのサイトはキディ遊園地のスクリプトです。あなたのためにやり直してください。元気になります。」 この状況で何をしますか? 更新: 私はここでいくつかの良いアドバイスに従い、サイトでいくつかのセキュリティ上の欠陥を発見したことを開発者に丁寧に報告しました。私はそのラインを指摘し、そこにSQLインジェクション攻撃の潜在的な脆弱性がある可能性があると述べ、彼がそれについて知っているかどうか尋ねました。彼は答えた:「確かに、しかしそれを悪用するには、攻撃者はデータベースの構造に関する情報を持っているべきだと思う。もっとよく理解しなければならない」。 アップデート2: 私はそれが常にそうではないと言って、彼がそれを適切に扱うためにこのStack Overflow質問リンクに従うことを提案しました:PHPでSQLインジェクションを防ぐ方法は?彼はそれを勉強するだろうと言い、以前彼に言ったことに感謝した。おかげさまで、私の役目は終わったと思います。

3
REST APIセキュリティストアドトークンvs JWT vs OAuth
モバイルアプリケーションとAPIの量は日々増加しているため、REST APIを保護するための最適なセキュリティソリューションを探しています。 私はさまざまな認証方法を試しましたが、まだいくつかの誤解があるため、より経験豊富な誰かのアドバイスが必要です。 このすべてを理解する方法を教えてください。何か間違って理解した場合は、お知らせください。 REST APIが一般にWEBと同様にステートレスである限り、各リクエスト(cookies、token ....)で認証データを送信する必要があります。ユーザーを認証するために広く使用されている3つのメカニズムを知っています HTTPSを使用したトークン。私はこのアプローチを何度も使用しましたが、HTTPSで十分です。ユーザーが正しいパスワードとログインを提供すると、応答としてトークンを受け取り、それを以降のリクエストに使用します。トークンはサーバーによって生成され、保存されます。たとえば、ユーザー情報が保存される別のテーブルまたは同じテーブルに保存されます。そのため、各リクエストサーバーで、ユーザーがトークンを持っているかどうかを確認します。トークンがデータベース内と同じである場合。すべてが非常に簡単です。 JWTトークン。このトークンは自己記述的であり、トークン自体に関するすべての必要な情報が含まれています。このトークンは秘密キーワードを使用してサーバーによって生成(署名)されるため、ユーザーは有効期限やその他の要求などを変更できません。これも明らかです。しかし、個人的には、トークンを無効にする方法の1つの大きな問題です。 OAuth 2.サーバーとクライアント間で直接通信が確立される場合、このアプローチを使用する必要がある理由がわかりません。私の知る限り、OAuthサーバーは、他のアプリケーションがパスワードとログインを保存せずにユーザー情報にアクセスできるように、制限されたスコープでトークンを発行するために使用されます。これは、ユーザーが何らかのページでサインアップしたい場合、ソーシャルネットワークにとって優れたソリューションです。サーバーは、たとえばtwitterやfacebookからユーザー情報を取得する許可を要求し、登録フィールドにユーザーデータなどを入力できます。 オンラインストアのモバイルクライアントを検討してください。 最初の質問は、最初のタイプのトークンよりもJWTを好むべきですか?モバイルクライアントでログイン/ログアウトユーザーが必要な場合、トークンをどこかに格納する必要があります。JWTの場合、ログアウト時にトークンを無効にする必要があります。トークンを無効化するには、無効なトークンリスト(ブラックリスト)を作成する方法があります。うーん。テーブル/ファイルのサイズは、トークンがテーブルに保存されてユーザーに関連付けられ、ログアウト時に削除された場合よりもはるかに大きくなります。 それでは、JWTトークンの利点は何ですか? OAuthに関する2番目の質問は、サーバーと直接通信する場合に使用する必要がありますか?クライアントとサーバー間のもう1つのレイヤーの目的はトークンの発行のみですが、通信はoauthサーバーではなくメインサーバーと行われます。私が理解しているように、OAuthサーバーは、ユーザーの個人情報にアクセスするためのサードパーティアプリのアクセス許可(トークン)を付与する責任があります。しかし、私のモバイルクライアントアプリケーションはサードパーティではありません。
104 security  rest  api  oauth  https 

8
信頼できるモバイルアプリケーションのみのREST APIを保護する方法
REST APIが信頼できるクライアント、私の場合は自分のモバイルアプリケーションによって生成されたリクエストにのみ応答することを確認するにはどうすればよいですか?他のソースからの不要なリクエストを防ぎたい。ユーザーがシリアルキーなどを入力するのは望ましくありません。これは、バックグラウンドで、インストール時に、ユーザーの操作なしで発生するはずです。 私の知る限り、HTTPSは、通信相手のサーバーが本人であることを検証することのみを目的としています。もちろん、データを暗号化するためにHTTPSを使用します。 これを達成する方法はありますか? 更新: ユーザーは読み取り専用のアクションを実行できますが、ユーザーはログインする必要がありませんが、ユーザーがログインする必要がある書き込みアクションも実行できます(アクセストークンによる認証)。どちらの場合も、信頼できるモバイルアプリケーションからのみのリクエストにAPIが応答するようにします。 APIは、モバイルアプリケーションを介して新しいアカウントを登録するためにも使用されます。 更新2:これには複数の答えがあるように見えますが、正直なところ、どれに答えとしてフラグを立てるべきかわかりません。できると言う人もいれば、できないと言う人もいます。
96 security  rest  mobile 

7
ロボットはどのようにしてCAPTCHAを打ち負かすことができますか?
Webサイトの電子メールフォームがあります。カスタムCAPTCHAを使用して、ロボットからのスパムを防ぎます。それにもかかわらず、私はまだスパムを受け取ります。 どうして?ロボットはどのようにしてCAPTCHAを打ち負かしますか?ある種の高度なOCRを使用するのか、それとも保存場所からソリューションを取得するのか? どうすればこれを防ぐことができますか?別の種類のCAPTCHAに変更する必要がありますか? 電子メールはフォームから送信されていると確信しています。これは、フォームメッセージを送信する電子メール送信者から送信されるためです。文字スタイルも同じです。記録のために、私はPHP + MySQLを使用していますが、この問題の解決策を探しているわけではありません。ロボットがこれらの技術を打ち負かす一般的な状況に興味がありました。この状況を例として伝えたので、あなたが私が尋ねていることをよりよく理解することができます。
84 security  captcha 

17
ソフトウェアを著作権侵害からどのように保護できますか?
なぜ今日海賊行為がそんなに簡単に見えるのですか? 私たちの技術の進歩と最も信じられないほど驚くべきソフトウェアのエンジニアリングに費やされた数十億ドルの費用で、「シリアル番号/アクティベーションキー以外に著作権侵害から保護する他の手段はまだないと信じるのは少し難しいようです。 「。Windows 7やOffice、さらにはSnow Leopardの作成に莫大なお金(おそらく数十億)が費やされたと思いますが、20分以内に無料で入手できます。おそらく最も簡単なAdobeのすべての製品で同じです。 ソフトウェアを著作権侵害から保護する、だまされない、ハッキングされない方法はありますか?現実的でない場合、理論的にはどうでしょうか?または、これらの企業がどのようなメカニズムを展開していても、ハッカーは常に回避策を見つけることができますか?
77 security 

15
クライアント側のJavascriptからデータベースに直接移動しない理由はありますか?
重複の可能性: Web「サーバーレス」アプリケーションの作成 そこで、Stack Exchangeクローンを構築し、CouchDBのようなものをバックエンドストアとして使用することにしたとしましょう。組み込みの認証とデータベースレベルの承認を使用する場合、クライアント側のJavaScriptが公開されているCouchDBサーバーに直接書き込むことを許可しない理由はありますか?これは基本的にCRUDアプリケーションであり、ビジネスロジックは「投稿者のみが投稿を編集できる」で構成されているため、クライアント側のものとデータベースの間にレイヤーを配置する必要はほとんどありません。CouchDB側で検証を使用して、誰かがガベージデータを入れていないことを確認し、ユーザーが自分の_userデータしか読み取れないようにアクセス許可が適切に設定されていることを確認します。レンダリングは、AngularJSのようなものによってクライアント側で行われます。本質的には、CouchDBサーバーと多数の「静的」ページを用意するだけで十分です。サーバー側の処理は一切必要なく、HTMLページを提供できるものだけが必要です。 データベースを世界中に公開するのは間違っているように見えますが、このシナリオでは、アクセス許可が適切に設定されている限り、その理由を考えることはできません。Web開発者としての私の本能に反しますが、正当な理由は考えられません。それで、なぜこれは悪い考えですか? 編集:同様の議論がここにあるように見えます:Web「サーバーレス」アプリケーションの作成 編集:これまでのところ素晴らしい議論、そして私は皆のフィードバックに感謝します!CouchDBとAngularJSを具体的に呼び出す代わりに、いくつかの一般的な仮定を追加する必要があるように感じます。だからそれを仮定しましょう: データベースは、非表示のストアからユーザーを直接認証できます。 すべてのデータベース通信はSSL経由で行われます データ検証をすることができます(多分?べきではありません)データベースによって処理され 管理機能以外に私たちが気にする唯一の承認は、自分の投稿の編集のみが許可されている人 誰でもすべてのデータを読み取ることができます(パスワードハッシュを含む可能性があるユーザーレコードを除く) 管理機能は、データベース認証によって制限されます 誰も管理者ロールに自分を追加できません データベースは比較的簡単に拡張できます 真のビジネスロジックはほとんどありません。これは基本的なCRUDアプリです

14
SQLインジェクション防止メカニズムがパラメーター化されたクエリを使用する方向に進化したのはなぜですか?
私の考えでは、SQLインジェクション攻撃は次の方法で防止できます。 入力を慎重にスクリーニング、フィルタリング、エンコードする(SQLへの挿入前) 使用して準備された文 /パラメータ化クエリを それぞれに長所と短所があると思いますが、なぜ#2が離陸し、インジェクション攻撃を防ぐための事実上の方法であると見なされるようになったのですか?単に安全でエラーが発生しにくいのですか、それとも他の要因がありましたか? 私が理解しているように、#1が適切に使用され、すべての警告が処理されれば、#2と同じくらい効果的です。 サニタイズ、フィルタリング、エンコード 私の側では、サニタイズ、フィルタリング、およびエンコードの意味が混乱していました。この場合、サニタイズとフィルタリングは入力データを変更または破棄する可能性があることを理解していますが、エンコードはデータをそのまま保持しますが、エンコードしますインジェクション攻撃を避けるために適切に。データをエスケープすることは、それをエンコードする方法と考えることができると信じています。 パラメータ化されたクエリとエンコーディングライブラリ parameterized queriesとの概念がencoding libraries相互に交換可能に扱われている答えがあります。私が間違っている場合は修正しますが、私はそれらが異なっているという印象を受けています。 私が理解しているのは、encoding librariesどんなに優れていても、SQL「プログラム」を変更する可能性は常にあるということです。 Parameterized queries 一方、SQLプログラムをRDBMSに送信すると、RDBMSはクエリを最適化し、クエリ実行プランを定義し、使用するインデックスを選択するなどして、RDBMS内の最後のステップとしてデータをプラグインします。自体。 エンコーディングライブラリ data -> (encoding library) | v SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement パラメータ化されたクエリ data | v SQL -> RDBMS (query execution plan defined) -> …

9
主キーを公開しないのはなぜですか
私の教育では、実際のプライマリキー(DBキーだけでなく、すべてのプライマリアクセサー)をユーザーに公開することは欠陥のあるアイデアであると言われました。 私はいつもそれをセキュリティの問題だと思っていました(攻撃者が自分のものではないものを読もうとする可能性があるため)。 ユーザーがとにかくアクセスを許可されているかどうかを確認する必要があるので、その背後に別の理由がありますか? また、とにかくユーザーがデータにアクセスする必要があるため、その間のどこかに外部の公開キーが必要になります。公開キーには主キーと同じ問題がありますよね? とにかくそれを行う理由についての例の要求があったので、ここに1つがあります。質問は、この例に当てはまる場合だけでなく、原則自体に関するものであることを忘れないでください。他の状況に対処する回答は明示的に歓迎されます。 アクティビティを処理し、複数のUIとシステム間通信用の少なくとも1つの自動APIを備えたアプリケーション(Web、モバイル)アプリケーションには複数の顧客がいるため、データの分離(論理的には、データは同じDBに格納されます)はシステムに必要です。各リクエストは、どのような場合でも有効性がチェックされます。 アクティビティは非常に細かいので、いくつかのコンテナオブジェクトにまとめられ、「タスク」と呼びます。 3つのユースケース: ユーザーAは、ユーザーBを何らかのタスクに送りたいので、ユーザーBにリンク(HTTP)を送信して、そこでアクティビティを実行させます。 ユーザーBは建物の外に出て、モバイルデバイスでタスクを開く必要があります。 アカウンティングは顧客にタスクの料金を請求したいが、REST-アプリケーションのAPIを参照するコードによってタスク/アクティビティを自動的にロードするサードパーティの会計システムを使用する 各ユースケースでは、エージェントがタスクとアクティビティのアドレス可能な識別子を持っていることが必要です(または、より簡単になります)。

8
パスワードの再利用を「保護」するために、送信する前にクライアントでパスワードをハッシュするWebページがほとんどないのはなぜですか(そしてサーバー上で再度ハッシュするのですか)。
インターネットにはログイン情報を必要とする多くのサイトがあり、パスワードの再利用を防ぐ唯一の方法は、サーバー上でパスワードがハッシュされるという「約束」です。 したがって、パスワードを再ハッシュするサーバーに送信する前に、クライアントコンピューターで(Javascriptを使用して)パスワードをハッシュするWebページを作成するのはどれくらい難しいでしょうか。理論的には、これは追加のセキュリティを提供しませんが、実際には、サーバーでパスワードをハッシュしない「不正サイト」から保護するために使用できます。

7
スタックトレースは、ユーザーに表示されるエラーメッセージに含める必要がありますか?
私は職場で少し議論があり、誰が正しいのか、何が正しいのかを理解しようとしています。 コンテキスト:顧客が会計やその他のERPに使用するイントラネットWebアプリケーション。 (物事がクラッシュした場合)ユーザーに表示されるエラーメッセージには、スタックトレースなど、できるだけ多くの情報を含めるべきだと思います。もちろん、それはまず、「エラーが発生しました。開発者に以下の情報を送信してください」という大きなわかりやすい手紙で始める必要があります。 私の推論では、クラッシュしたアプリケーションのスクリーンショットがしばしば唯一の簡単に入手できる情報源になるということです。確かに、クライアントのシステム管理者の把握を試みたり、ログファイルの場所を説明したりすることができますが、それはおそらく遅くて苦痛です(ほとんどの場合、クライアントの担当者と話すのはそうです)。 また、すべての例外で必要なものを見つけるためにログファイルを探し回る必要のない開発では、即時かつ完全な情報を持つことが非常に役立ちます。(ただし、これは構成スイッチで解決できます。) 残念ながら、ある種の「セキュリティ監査」があり(ソースなしでどのように行われたかはわかりませんが...何でも)、彼らはセキュリティの脅威としてそれらを引用する完全な例外メッセージについて不平を言いました。当然、クライアント(私が知っている少なくとも1人)はこれを額面通りに受け取っており、現在はメッセージのクリーンアップを要求しています。 潜在的な攻撃者がスタックトレースを使用して、以前は理解できなかったものを把握する方法を理解できません。これまでにこれを行った人の例、証拠はありますか?私たちはこの愚かな考えと戦うべきだと思うが、おそらく私はここで愚か者だから... 誰が正しい?

2
役割ベースのアクセス許可ベースのアクセス制御
私は、アクセス制御(認可)に関して、ロールとパーミッションの固有のトレードオフを理解しようとしています。 与えられたものから始めましょう:私たちのシステムでは、パーミッションはきめ細かいアクセス単位です(「リソースXの編集」、「ダッシュボードページへのアクセス」など)。役割は 1+権限のコレクションになります。ユーザーは 1+役割を持つことができます。これらの関係(ユーザー、ロール、権限)はすべてデータベースに保存され、必要に応じてその場で変更できます。 私の懸念: (1)アクセス制御のためにロールをチェックすることの「悪い」ところは何ですか?代わりにアクセス許可を確認することでどのような利点が得られますか?言い換えると、これらの2つのスニペットの違いは次のとおりです。 if(SecurityUtils.hasRole(user)) { // Grant them access to a feature } // vs. if(SecurityUtils.hasPermission(user)) { // Grant them access to a feature } そして: (2)このシナリオでは、ロールはどのような有用な価値を提供しますか?1つ以上のアクセス許可をユーザーに直接割り当てることはできませんか?ロールはどのような抽象化の具体的な価値を提供しますか(特定の例を挙げられますか)?

13
ランダムな見知らぬ人からのソースコードをコンパイルすることはどれくらい安全ですか?[閉まっている]
求職者がスキルを証明するために送信するコードをレビューするとします。明らかに、彼らが送信する実行可能ファイルを実行したくない。それほど明確ではありませんが、コードのコンパイル結果を実行したくないのです(たとえば、Javaではコメント内の実行可能なコードを非表示にできます)。 コードをコンパイルするのはどうですか?私のコンパイラを悪用する巧妙な文字シーケンスがコードに含まれていて、コンパイラがマシンを危険にさらしている場合はどうでしょうか? 「コンパイラーの脆弱性」をGoogleで検索すると、コンパイラーの最適化とコードの発行、および発行されたコードが元のソースコードの意図どおりに安全であるかどうかがヒットします。 コンパイラーは通常、いくつかの巧妙なコードをコンパイルするときにユーザーマシンを危険にさらさないように検証されていますか?見知らぬ人からのコードをコンパイルすることはどれくらい安全ですか?

9
開発マシン上のウイルス対策ソフトウェアを支持する意味のある強力な議論を探している[非公開]
意見を形成するとき、学問的伝統に従うことは良い習慣です- あなたが保持する意見に反対することができる限り一生懸命に考え、反論を見つけようとします。 しかし、どんなに一生懸命努力しても、開発マシンでウイルス対策(および関連するセキュリティ対策)を支持する合理的な議論を見つけることはできません。 開発中のウイルス対策(AV)に対する議論はたくさんあります。 AVをオンにして1分間のビルドで10倍の時間がかかることは珍しくありません 会議の講演で、IntelliJ開発者は、IDEが遅い場合にAVソフトウェアが疑わしいと主張しています 解凍には、AVをオンにした状態で約100 kb / sの速度が伴います AVはCygwinを完全に使用不能にします(vimは単純なファイルを開くのに1分かかります) AVにより、同僚の電子メールから有用なファイル(JAR、DLL)をダウンロードできない AV /セキュリティ対策によりポートのブロックを解除できないため、開発に複数のコンピューターを使用することはできません AVは、MavenやAntなど、ファイルの回転率が高いプログラムのパフォーマンスを低下させます 最後になりましたが、AVは実際に私を何から保護しますか?私のAVプログラムがセキュリティスレッドを停止することを認識していません。 理由がNDAのものを開示することの恐怖である場合-心にそれを設定した場合、AVがそれを行うことを妨げる可能性はありません。 理由がソースコードやドキュメントを失う恐れがある場合-これには分散リビジョンシステムがあります(レポには少なくとも20のコピーがあり、毎日同期しています)。 顧客データの開示を恐れる場合、開発者は実際の運用データベースに接続して作業することはめったになく、代わりにおもちゃの環境で遊んでいます。 開発マシンでAVを使用することを支持する有意義な議論があったとしても、偏執的に保護された環境で仮想マシンを実行する能力に直面すると、それらはバラバラになります。 私はこの問題について心を開いておきたいので、開発者向けのウイルス対策ソフトウェアを支持する意味のある強力な議論を誰かが提示できますか?

10
文字を許可せず、パスワードの長さを制限する正当な理由はありますか?
パスワードを許可する長さを制限したり、特定の文字を禁止したりするサイトを数多く目にしました。パスワードの検索スペースを広げて長くしたいので、それは私に制限されています。また、それらがハッシュされていないかもしれないという不快な感覚を私に与えます。 そこにあるの良いアッパー長さを設定したり、パスワードの文字を除くいずれかの理由は?

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