Flash ベースのアップローダを実装しているときに、 Flash が正しい Cookie を提供しないという問題に直面しました。POST 変数を介して PHP セッション ID を渡す必要があります。
私たちは、POST PHPSESSID をチェックする機能的なソリューションを考え出し、実装しました。
セッション ID の POST は、Cookie で送信するのと同じくらい安全ですか?
考えられる理由: どちらも http ヘッダーにあり、クライアントが偽造する可能性があるためです。考えられる反対の理由: Cookie よりも POST 変数を偽造する方が簡単だからです。
POST の偽造は Cookie と同じくらい簡単です。これらは両方とも、cURL でフラグを設定するだけで実行できます。
そうは言っても、あなたにも良い解決策があると思います。
POST するためにアクティブ コンテンツからセッション ID を取得できる場合、これはおそらく、セッション Cookie がHttpOnlyとマークされていないことを意味します。これは、クロスサイト スクリプティング攻撃から防御するための良いアイデアであると私たちのホストの 1 人が主張しています。
代わりに、JavaScript ベースまたは更新ベースのアップローダ モニタを検討してください。これは、Cookie を HttpOnly にすることができる他のすべてのものと十分に統合する必要があります。
一方、サイトがサードパーティのコンテンツを受け入れていない場合、クロスサイト スクリプティング攻撃は問題にならない可能性があります。その場合、POST は問題ありません。
HTTPリクエストで何かを偽造するので（curlまたはflashを使用して）、GET経由で送信することもうまくいくと思います。重要なことは、cookie/post/get パラメータで暗号化される内容と、サーバー側でどのように暗号化およびチェックされるかです。
本当にどちらが偽造しやすいかを心配しているなら、あなたは間違ったことを心配しています. 簡単に言えば、どちらも経験豊富な攻撃者にとって些細なことです。いずれかを選択することで「スクリプト キディ」を締め出すことができますが、それらの人々は心配する必要はありません。自問すべき質問は、「誰かが ID を偽造するのを防ぐにはどうすればよいか」ということです。それは起こります。ID が暗号化されておらず、簡単に推測できる場合、それは問題です。ハッキングされます。どちらがより安全かという質問なので、気になっていると思います。
ここで考慮すべきもう 1 つの点は、アプリケーションがフラッシュであるため、コンパイルされたコードが攻撃者のマシン上にあるため、(javascript HTML コードと同様に) 変更されやすいことです。彼らはバイナリを調べて、コードがどのように機能するか、およびサーバーから何を取得する必要があるかを把握できます。
POST データは HTTP ヘッダーではありませんが、TCP ストリームの一部として送信されるため、HTTP ヘッダーと同じくらい簡単に読み取り/偽造できます。HTTP リクエストをインターセプトすると、次のようになります。
POST /path/to/script HTTP/1.1
Host: yourdomain.com
User-Agent: Mozilla/99.9 (blahblahblah)
Cookie: __utma=whateverthisisacookievalue;phpsessid=somePHPsessionID
data=thisisthepostdata&otherdata=moredummydata&etc=blah
他の人が言ったように、POST と Cookie (および GET データ、つまりクエリ文字列) はすべて、同じ HTTP パケット内の単なるテキストであるため、簡単に偽装できます。
繰り返しますが、Cookie と Post はどちらも同じように安全ではありません。