SO が伝統的にこのように使用されていないことは知っています (または、そうかもしれません) が、私は webapp のセキュリティについて学んでおり、SO の専門家からこの記事についての意見を聞くのは良いことであり、励みになると考えていました (私は今それを読んで、それはセッションセキュリティにあります)。
http://carsonified.com/blog/dev/how-to-create-bulletproof-sessions/
たぶん、何らかの議論をして、著者が誤って述べたり忘れたりしたこと、およびどのようなより良いプラクティスがあるかを指摘することができますか?
たとえば、SQL インジェクションなどの別のセキュリティ トピックに関しては、多くの人が mysql_real_escape_strings などを推奨していますが、専門家は、準備済みステートメントに勝るものはないと言うでしょう。コメントを見ると、この記事には問題があるように見えるので、彼の内容がどこまで良いのか悪いのか気になります。
この記事は非常に素晴らしいと思いますが、これらは基本的な概念に過ぎず、誰かが真剣にセキュリティを意識したアプリケーションを作ろうとすれば、このようなことは解決されるでしょう。つまり記事のレベルがかなり低い。
中間者攻撃のような問題はここでは扱いません (ただし、このような問題は通常、アプリケーション層の範囲外であると想像できます)。別の考えられる脆弱性は、乱数の生成です。そのため、セッション キー生成の実装によっては、セッション キーのエントロピーが可能な限り最大のエントロピーよりもはるかに低くなる可能性があり、ブルート フォース攻撃が実行可能になる場合とそうでない場合があります。
したがって、ソリューションがどのようになるかは、セキュリティ要件に大きく依存します。すべての場合に機能する単一のセキュリティ ソリューションはありません。後者を適用するには、有効なセッション ID があり、セッションがバインドされている IP を知っているとします。また、この例のターゲットは銀行であると想定します。これで、自分のアカウントに送金するリクエストを実行し、IP アドレスを偽装して盗んだセッションを提供することで、これを機能させることができます。わかりました、IP アドレスが偽装されているため、リクエストの返信は届きませんが、サーバーがリクエストを受け入れたのでお金を受け取りました。
重要なのは、コンテキストに応じて、セキュリティ要件とセキュリティ ソリューションが大きく異なる可能性があるということです。