Exploiting a High‑Risk SSRF Vulnerability in a Financial Crowdsourcing Web Application

During a financial crowdsourcing project the author encountered a web system that returned only blank pages and 404 responses, giving the impression of having no functionality. Initial reconnaissance involved viewing the page source and identifying three potential clues: a referenced libs/plugins/jquery.js file, a URL pattern html/apply.html?data= , and a path cxx/token/decrypt .

The jquery file was a standard front‑end library and was ignored, while the other two paths also resulted in 404 errors. A directory brute‑force against the host revealed three directories that returned 403 Forbidden: /html/ , /css/ and /js/ . Recognizing that 403 responses indicate existing resources, the author focused on the /js/ directory.

Using Burp Suite’s Intruder module, three JavaScript files were discovered:

http://xxx-desktop.xxx.com/js/apply.js
http://xxx-desktop.xxx.com/js/pagination.js
http://xxx-desktop.xxx.com/js/common.js

Analysis of common.js exposed an API prefix /xxxapi/ . Further inspection of apply.js revealed an endpoint file/pdf/view?file= . By concatenating the prefix and endpoint, the full vulnerable URL was constructed:

http://xxx-desktop.xxx.com/xxxapi/file/pdf/view?file=

The author hypothesized that the file parameter accepts an arbitrary URL, enabling Server‑Side Request Forgery (SSRF). A test request pointing to a VPS listener confirmed that the server performed an outbound HTTP request, proving the SSRF vector.

Exploiting the SSRF, internal services were accessed, such as an Elasticsearch instance ( http://10.x.x.191:9200 ) and an internal web application ( http://10.x.x.65:8081 ). Example request:

GET /xxxapi/file/pdf/view?file=http://10.x.x.191:9200/ HTTP/1.1
Host: xxx-desktop.xxx.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

The successful exploitation created an internal HTTP tunnel, demonstrating a high‑severity SSRF vulnerability. The write‑up concludes with three key takeaways: examine empty pages for hidden clues, expand the search for exploitable information, and treat 403 responses as potentially more valuable than 404s.