New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible SSRF with URLs of external resources #867
Comments
|
It seems to me it is a concern of the user of the library to prevent external changes to mPDF templates loading external resources. The library itself cannot decide which resources to allow and which to deny unless it would deny all external resources, which is a no-go. Can you elaborate? |
|
Mh it would be nice to whitelist / blacklist hosts to load external resources from. Is there an easy way to to this or add this currently? |
|
No, there isn't. |
|
well, I was play with a private bug bounty program some days ago. And found one of target server with a html2pdf service of mPDF, then I found when I modify some content which would be transformed. to: It make a request to intranet server. It is a ssrf! So I think this 'character ' may be dangerous in some scenario, and I agree your words:'The library itself cannot decide which resources to allow and which to deny '. But I think it would be better have a switch(config option?) to choose let this mpdf to get the intranet resources or not. |
|
A few remarks:
Whole path handling calls for a refactoring, yes, I guess we can incorporate a blacklist/whitelist while doing that. Will make a separate feature request for that. |
|
Thanks for your reply. I will write the answers one by one.
For more detail about this bug, plz search CVE-2013-2251. In a word, this bug could be triggered with a single GET request, and it will execute any command in the vulnerable server. Also the poc was well-designed to send back the result to my VPS(http://111.112.113.114:9999/result). All that I need is make the server to send a GET requests to the intranet. |
|
@maplebluex I appreciate what you're saying, but it's not our job to sanitise your input. If you allow users to pass HTML without sanitising it, you're asking for trouble. |
|
@jakejackson1 Yeah, in fact the input should be sanitized, but many users do not know how to do it, so I think it would be better to have a choice inside of the mPDF |
|
Closing this, the new feature request remains open. |
Hello, when I was do some security test. I found a vulnerability that may lead to ssrf of the server which host a html2pdf service with mPDF. The poc is as follow:
the another server (192.168.0.2) will get a request from above
In real scenario the poc may be sent from font end . so attacker will send this to server side and trigger a SSRF bug which may lead to attack private network
mPDF version:v7.1.5 OS:UBUNTU 16.0.4
The text was updated successfully, but these errors were encountered: