0

I am currently doing a bug bounty program and found a possible file upload vulnerability, but I am not so sure about it.

The vulnerability is on the chat function. In the chat function, users are allowed to communicate with each other and attach files.

Upon sending the message, I turned on my burpsuite and intercept the request. It turns out that the body of the POST request to the server includes the URL image where the image was uploaded. The image is uploaded to a subdomain of the company and when it is changed to my own domain, I was able to upload my own file from my domain, but is only limited to images. I tried uploading .SVG files with XSS payloads but they are not executed inside of the chat. I found out the image being displayed inside of the chat is being put inside of an <img> tag.

So it would look something like this;

<img class='...' src='https://myowndomain.com/StoredXss.svg>

If we click on the image, it will only be enlarged but the xss payload isn't executed and of course, if we 'open new tab' this image, the xss will be executed.

Things I tried:

  • change the extension into a php file (doesn't execute since it is wrapped inside of a img tag)
  • change the url with xss payload (dangerous chars are converted to html entities)

Is there a possibility to exploit this in the chat?

Improve this question
3
  • It sounds like you exploited it. What is your expected result?
    – schroeder ♦
    Commented Aug 11, 2020 at 16:35
  • There is a high change of possibility when .svg can be uploaded, a script tag can be added in to alert document.cookie. But I guess in this case since it is being wrapped inside of a img tag, it is not possible. Is there any other things that i can do here? I guess this is more of a Unrestricted File Upload Question.
    – Emanuel Beni
    Commented Aug 11, 2020 at 16:36
  • @schroeder, I am expecting the script to be executed inside of the chat, but here i could only execute the payload from my own domain when i 'open new tab' the image
    – Emanuel Beni
    Commented Aug 11, 2020 at 16:37

1 Answer 1

Reset to default
2

As far as you're letting on, this isn't an "unrestricted file upload" vulnerability. "Unrestricted file upload" means uploading the file to their domain/server, not yours. SVG images sourced this way (via images) don't normally execute the javascript they contain. If you manage to upload an .svg file to their domain, and it's accessible via a URL, then you'll have a stored XSS vulnerability if you can get someone to visit the URL directly.

PHP files accessed on your domain would only ever execute code on the server they were hosted on, referenced inside an image tag or not. I think you're confusing sourcing a document as an image inside HTML with PHP file inclusion, wherein the server's PHP source specifies an attacker-controlled file for evaluation. Web servers don't go grab image links specified inside the HTML document they're responding with and interpret them as server side PHP code.

Improve this answer
2
  • +1 but two nitpicks: SVG sourced via images don't ever execute as JavaScript. Getting it uploaded to their server would be more promising but still low impact, because the only way it could possibly execute JavaScript (assuming They missed some mitigations) I'd if you send a user w link directly to it and get them to click it. This makes it a bit more like reflected XSS than stored because of the social engineering factor
    – Conor Mancone
    Commented Aug 13, 2020 at 2:27
  • @ConorMancone Never say never when it comes to web browsers. I'll clarify the stored xss portion though.
    – Dean Valentine
    Commented Aug 13, 2020 at 2:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .