How to exploit XSS vulnerability through an iframe

Question

Recently, I found a stored cross site scripting vulnerability in a rather large website, but I am not sure if it is dangerous or worth reporting. On this website, there is a resource section that is accessible by logged in users, where they can post certain personal resources that can be used only by themselves. It is not possible to share a resource to another user. Also, there is also a portfolio page, where you can make things public. I found two possible vulnerabilities, but I am asking to see if they are dangerous at all.

Stored XSS : The first vulnerability includes the resources page, where you can post a link. The first time you post the link, it is sanitized, and you cannot get anything useful through. Upon editing the link, though, it is not sanitized, and you can easily insert a <script>alert(1)</script> or a <script>window.location.href="https://google.com"</script>.

HTML Injection : On a different page called portfolio, a user can construct a portfolio and add resources. This page does not have the same XSS vulnerability as the previous page, and it is impossible to get javascript execution as far as I know. However, it is possible to insert an iframe into it. The iframe src cannot contain any javascript, but I can make the src lead to my resources page (where the stored xss vulnerability is located), to get javascript execution on the public profile page.

The Problem : The problem with this vulnerability, is that it only works when I view the portfolio page, because the resources page in the iframe is only accessible to me. The resource page link is possible to access using only one session cookie (my session cookie) when viewing it. Is there any way that I could pass my cookie into the iframe so that the xss vulnerability could be viewed on any user? Could I pass the cookie as a http header (there is a 'Set-Cookie' header). If I use an iframe, can the child access the parent's cookies? Is this even a vulnerability / can I make it work? Thanks so much!

Answer 1

As described, I don't see any avenue to XSS another user. The site should probably still be notified, but it would be good to make it clear that the exploitability is low-to-none.

However, it is hard to make an iframe totally safe. Disallowing javascript: source URIs is a good start, but they also need to forbid data: URIs as those are treated as same-origin and thus can contain arbitrary malicious script that can interact with the host window. They need to make sure there's no frameable same-origin pages that do anything which would be harmful in this context (as you already tried). They need to make sure to either prohibit or similarly restrict <object> and <embed> and <svg>. They need to ensure that an attacker can't do things like make the iframe cover the whole page and show a login form or other phishing content. An attacker could also point the iframe at a malicious external site, such as one hosting an exploit kit (which tries to take over the browser, not just the page). It is nearly impossible to keep from some kind of potentially-reputationally-harmful content, such as pornographic or politically extreme images

Additionally, there is of course the risk of the iframe (or any other embeddable HTML element) having a malicious event handler or inline style that could still allow XSS. Allowing HTML at all is risky (although you should find something harmful that can be demonstrated before reporting it as a finding, of course).

Answer 2

This is called Self-XSS.

It can be usefull if you can combine it with a csrf vulnerability on the auth.

1. Insert the XSS
2. Trigger a user to visit a controlled page
3. Use a csrf vulnerability to log off this user and connect him to your account
4. Redirect him to your infected page

Or as @reed suggest, use a csrf vuln to edit the link on the victim account and redirect him to the infected page.