Hello there, ('ω')ノ
XXEは、XML外部エンティティインジェクションの略で。
WEBアプリケーションのXMLデータの処理を妨害できる脆弱性で。
多くの場合、アプリケーションサーバのファイルシステム上のファイルを表示して。
アプリケーション自体がバックエンドにアクセスできたり。
外部システムと対話することができたりと。
内部エンティティ：エンティティがDTD内で宣言されている場合
構文：<!ENTITY entity_name "entity_value">
外部エンティティ：エンティティがDTDの外部で宣言されている場合
構文：<!ENTITY entity_name SYSTEM "entity_value">
脆弱性診断ガイドラインをみると。
診断を実施すべき箇所は、リクエストにXMLが含まれている箇所 で。
操作を行う対象は、XMLが格納されている箇所（パラメータ、ファイルなど）で。
ペイロード・検出パターンの例は下記のとおりで。
元の値：
<?xml version="1.0" encoding="ISO-8859-1"?>
<foo>test</foo>
試行例：
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/hosts" >]><foo>&xxe;</foo>
ただ、これだけでは十分な診断ができず。
サーバは予期していなかったデータ形式を受け入れる場合があって。
これで、JSONエンドポイントがXXEに対して脆弱になる可能性があって。
なので、Content-TypeヘッダとHTTPリクエストペイロードを試して。
JSONエンドポイントに対しても悪用される可能性があるかどうかを確認したりと。
たとえば、下記のノーマルなケースがあったとして。
HTTP Request:
HTTP Response:
Content-Typeをxmlに変更して、レスポンスを確認すると。
このエラーからサーバがXML形式のデータとJSON形式のデータを処理できるらしく。
Content-Typeヘッダに記載されているXMLではなかったため解析できなくて。
HTTP Request:
HTTP Request:
このエラーをクリアするには、JSONをXMLに変換する必要があって。
Original JSON
XML Conversion
ただ、単純な変換だと適切にフォーマットされたXMLに必要なルート要素がないので。
無効なXMLになったりもして。
その場合は、XMLを有効にするルート要素<root>を追加するのが最善の策でして。
これで、元のJSONリクエストをXMLとして送信できて。
サーバは有効なレスポンスを返すことができて。
HTTP Request:
HTTP Response:
これでXXEの環境が整ったので。
XXEで、JSONエンドポイントに対して悪用できて。
HTTP Request:
HTTP Response:
Best regards, (^^ゞ
