問題タブ [go-http]

Go + gorilla/mux v1.4 フレームワークを使用して RESTful Web アプリケーションに取り組んでいます。リリース後のいくつかの基本的なセキュリティ テストで、アプリにオープン URL リダイレクトの脆弱性があることが明らかになりました。この脆弱性により、ユーザーは、サーバーが 301 リダイレクトで応答する外部 URL を使用して特別に細工されたリクエストを送信できるようになります。

Burp Suiteを使用してこれをテストしたところ、アプリ内の外部 URL にリダイレクトするすべてのリクエストが 301 Moved Permanently で応答しているように見えることがわかりました。301 が送信される前にこれらのリクエストを傍受する方法をすべて調べましたが、この動作は net/http サーバーの実装に組み込まれているようです。

サーバーに送信された生のリクエストは次のとおりです (myapp.mycompany.com:8000):

そして、いつでも応答は次のとおりです。

http.handler でのこのタイプのリダイレクトを防ぐために request.URL のチェックを入れたにもかかわらず、ハンドラーに到達するためのリクエストを得ることができませんでした。PathPrefix("/").Handler コードで定義されているカスタム ハンドラー コードにアクセスすることを許可せずに、ベース http Web サーバーがリダイレクトを実行しているようです。

私の目標は、アプリケーションがそのような要求に対して 404-Not Found または 400-Bad Request を返すようにすることです。ゴリラ/マックスでこのシナリオに直面した人はいますか? Jetty Web アプリで同じことを試してみたところ、完全に有効な 404 が返されることがわかりました。これを数日間行って、実際にいくつかのアイデアを使用することができました。

JWT トークンが有効であることを確認するミドルウェアを作成しました。

これについていくつかのテストを作成しようとしましたが、どこが間違っているかを把握できます。トークンが無効であるため、テストは失敗するはずですが、まだ合格しています。

誰かが私が間違っている場所を説明できますか?

一部のストリームでクライアントからサーバーに送信される CANCEL を含む RST_STREAM が表示されます。2 つのストリーム データを追加しました。1 つのケースでは RST_STREAM が表示され、別のケースでは表示されません。

RST_STREAM が見られる HTTP2 ストリーム

RST_STREAM が見られない HTTP2 ストリーム

ここでの動作がわかりません。すでに END_STREAM が応答データで受信されているため、http2 スタックが RST_STREAM を送信している理由。

注 1: golang の http2 パッケージを使用golang.org/x/net/http2

注 2: 両方のストリームのデータ コンテンツに違いはありません。