web-dev-qa-db-ja.com

ASP.NET Web APIおよび潜在的なXSS

コントローラにデフォルトのGET呼び出しを処理するメソッドがなかったため、ASP.NET Web APIにXSSの脆弱性があったのかと思います。

GETメソッドがコードで処理されていない場合、
/api/mycontroller/?<script>alert('hi');</script>は次の結果になります：

_{"Message":"No HTTP resource was found that matches the request URI
 'http://localhost:8888/api/mycontroller/?'.",
 "MessageDetail":"No action was found on the controller 'MyController' that 
  matches the request."}
_

スクリプトタグはJSONソース内にあり、ページに表示されないだけであることに注意してください。

疑問符/api/mycontroller/<script>alert('hi');</script>をドロップすると、
"A potentially dangerous Request.Path value was detected from the client (<)."これで、HttpExceptionがユーザーを保護しています。

APIのルーティングは単にデフォルトのルーティングです。

_.Routes.MapHttpRoute(
    "DefaultApi", 
    "api/{controller}/{id}", 
    new { id = RouteParameter.Optional });
_

そして今私はデフォルトのアクションメソッドに追加しました：

_[HttpGet]
public HttpResponseMessage Get()
{ 
    // do something. 
}
_

ただし、このアクションメソッドを配置することは、開発者がAPIを作成しているときに簡単に見落とされる可能性があると思います。

だから私は疑問に思っていました、これは悪用可能なXSSの問題ですか？

xssasp.net
6
Boggin

この状態は、ほとんどのアプリケーションでおそらく悪用可能なXSS脆弱性ではありませんでした。これは、プログラマーが意図せずに問題を引き起こすのを防ぐための「多層防御」フィルターである可能性が高いです。

XSSは、戻り値のデータ型に応じてcontent-typeをapplication/xmlまたはapplication/jsonに設定することでAPIで解決されます（およびtext/plainもXSSを防ぐために一般的に使用されます）。反射的で永続的なXSSが問題になるのは、ページにHTMLコンテンツタイプがある場合のみです。 DOMベースのXSSは、依然としてWebサービスの懸念事項です。 Content-Security Policy は、HTMLインジェクションを使用してJavaScriptを実行する機能をさらに制限するために使用でき、DOMベースのXSSの防止に役立ちます。

最新のブラウザーを使用する場合、XSSペイロードは非実行コンテンツタイプでは実行しないでください。それでも、レガシーまたは非標準のブラウザーのコンテンツスニッフィングを明示的に無効にすることをお勧めします。

X-Content-Type-Options: nosniff
8
rook