1

プッシュオーバーを使用して通信するパーソナルサーバーがあります。つまり、サーバーは、さまざまな優先度でメッセージを電話に直接送信するスクリプトをトリガーできます。ただし、これは1つの方法です。Pushoverのhtmlリンクを追加する機能を使用してこれを回避したいと思います。

私はソケットコードをよく知っていますが、それに含まれるセキュリティについてはややぼんやりしています。これがどのように機能するかの例は、電源が切れることです。サーバーがUPSに接続されているため、電話で電源が切れているというメッセージがすぐに送信されます。システムをシャットダウンしますか？（その後のメッセージは電源復旧時に送信される可能性があります。つまり、シャットダウンしたくない場合があります。）たとえば、example.com：4000/insert_a_generated_hash_hereへのリンクが含まれます。サーバーをシャットダウンすることにした場合、ポート4000を監視しているデーモンは受信します

GET /insert_a_generated_hash_here HTTP/1.1\r\n
host: www.example.com\r\n
\r\n

私が最初に心配しているのは、nullで終了していない文字列です。それはどのくらいの問題ですか？recvは自動的にnull終了しますか？

とにかく、私はhttp getを取得してハッシュします（または、潜在的に敵対的な文字列をハッシュすることはどれほど安全ですか？）。

MD5を使用した場合、http getは25b382b678bb33a21fa677c66e9d02a1にハッシュされます（MD5を使用する必要がありますか？これは私が考えた最初のハッシュです）。

この時点で、そのハッシュ（操作しても安全なはずですか？）は、「現在アクティブな」コマンドのテーブルと比較されます。サーバーは元の生成されたハッシュを作成したため、httpリクエストのハッシュを作成できます。着信ハッシュがテーブル内の何かと一致する場合、もちろん、そのコマンドは実行済みの事前に用意されたコマンドのみです。コマンドも10分間だけアクティブになり、その時点でアクティブリストから削除されます。また、「このコマンドは発行されましたが、アクティブではありませんでした」というメッセージを電話に送信する「非アクティブ」リストを追加することもできます。

この場合、コマンドはシャットダウンになりますが、サーバー上のユーザーがパッケージマネージャーなどを介して何かをインストールすることを承認する場合があります。デーモンは、単純なWebページに関連するhttp応答を返す場合もあります。 「OK！」と言って （それは大したことではないと思いますか？）

これはどれほど安全で、何に注意する必要がありますか？それとも、アイデア全体がセキュリティ自殺の頂点ですか？

4

1 に答える 1

1

MD5は広く使用されていますが、壊れていることが知られています。代わりに、SHA-1などを調べてください。

ヌル終了するものを想定しないでください（または、DavidSchwartzが以下で述べているように、正しいヌル終了を提供するとは限りません）。アプリケーションがこれに依存している場合は、要求を受け取ったときにデーモンで自分で行うようにしてください。確かにこれは重要です。終了せず、単にメモリを破棄する「文字列」を喜んで読み取ったり操作したりして、バッファオーバーフローを発生させたくはありません。

「テーブル」とは、デーモン内にハードコードされたルックアップテーブルを指しているのですか、それともデータベーステーブルを指しているのですか。これらのことがメモリ内で発生している場合は、「実行可能」ではないため、問題はありません。たとえば、データベースを使用している場合、悪意のあるユーザーが何らかの方法でデータベースを悪用する攻撃文字列を作成する可能性があります（含まれているすべてのデータを公開するか、システムへの不正アクセスを取得します）。悪意のある文字列をハッシュしても効果はありませんが、ハッシュにソルトを追加しない場合、システムでコマンドを直接実行できるようにすると、悪意のあるユーザーが自分の文字列をハッシュしてコマンドを実行する可能性があります。 （申し訳ありませんが、システムの全体像を把握しているかどうかはわかりません）。

いずれにせよ、あなたの戦略は（それが実行可能で維持可能であるときはいつでも）セキュリティの観点から良いものです。実行できるものを正確に列挙することで、システムの動作をより完全に制御できます。これは、ユーザー入力の衛生状態の形式です。生のユーザーリクエストを受け取り、システム内で正しく機能するように変換します（無効な場合は変換しません）。とはいえ、これらのリクエストのいずれかが生のユーザー入力を使用している場合は、さらにチェックすることをお勧めします。つまり、リクエストが単純に翻訳されていない場合（つまり、受信した場合shutdown <message>）、単純に実行する前にサニタイズすることが重要です<message>（悪意のあるコードである可能性があります）。そうでない場合（つまりshutdown、適切なアクションを受け取って実行するだけの場合）、私は心配しません。

Web応答を送信する限り、これはおそらく問題ありません。応答がハードコーディングされている（そして動的ソースから取得されていない）場合、これについてはそれほど心配する必要はありません。ハードコードされた応答は、ディスクから他に何も読み取ろうとせず、この送信を利用できないため（バッファオーバーフローなどがないと仮定して）安全です。

私が考えることができるもう1つの攻撃ベクトルは、認証がない場合です。これがオープンサーバーの場合、ある種のアドミッションコントロールのために何らかの方法でロックダウンすることをお勧めします。これにより、悪意のあるユーザーがサーバー上で不正な方法で完全に有効なコマンドを実行するのを防ぐことができます。

編集

Webインターフェイスをより安全にするために、単純なユーザー認証フォームを使用することをお勧めします。ハッシュに単純に依存することは、隠すことによるセキュリティの原則に従うため、これに依存するべきではありません。このフォームには、前に説明したのと同じユーザー入力の問題（入力サニテーション、バッファオーバーフローなど）があることに注意してください。ユーザー入力をエンコードされた方法で直接ハッシュし（つまりsha1(user:pass)）、このハッシュをどこかに保存する必要がある有効なログインハッシュのリストと比較するのが最も簡単な場合があります。sha1(malicious_payload)これは単なるハッシュになるため、ユーザー入力のサニテーションに役立ちます。とはいえ、これでも、アクティブにチェックする必要のあるバッファオーバーフローからは保護されません。一般に、およびの代わりにstrncpyまたはのようなコマンドの長さ指定バージョンを使用しますstrncmpstrcpystrcmp。最後に、このフォームは、パスワードが何らかの形で漏洩した場合でも、ソーシャルエンジニアリング攻撃（つまり、パスワードフィッシング）やパスワードの盗難に見舞われる可能性があります。とは言うものの、これらはシステムの障害ではなく、多くの場合、セキュリティの人間的な要素にあります。

于 2013-03-21T18:40:16.060 に答える