Users can copy unlinkable URLs using the context menu on links and images and then load them manually
Categories
(Firefox :: Menus, defect)
Tracking
()
People
(Reporter: kirtikumar.a.r, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36/8mqNJauL-25
Firefox for Android
Steps to reproduce:
To reproduce this issue, you can either host HTML through Network protocol with the below content:
<img src="about:crashes">
or you can navigate to
data:text/html,<img src="about:crashes">
After you have performed either of the above steps, right-click on the image file and copy the image link and paste and go into any new tab
Actual results:
It actually allows us to navigate to any privileged URIs.
Expected results:
It shouldn't allow us to navigate/copy the privileged URIs like chrome won't allow us to do, you can try the below PoC in the chrome to know the expected behavior:
data:text/html,<img src="chrome://crashes">
When you will copy the image link and go to the new tab, you can see it will say about:blank#blocked. For more information, when you right click on about:crashes (in the IMG) and open it in a new tab, firefox won't open it as it might be dangerous. So, expecting same behavior for copying like chrome does.
|
Reporter | |
Comment 1•4 years ago
|
||
Btw, here is an interesting behavior. :P
When you open:
data:text/html,<img src="chrome://crashes">
in firefox, the image itself is absent, you can't copy the link or anything. Can we have a similar case for any URIs starting with: File://, about: etc?
Another interesting case is below:
data:text/html,<img src="file:///C:\">
Copy the image link and open it in a new tab, it will navigate you to the privileged local storage URI and from this blog, it should have a restriction like Chrome doesn't allow for it. Adding Eric from Microsoft into CC if I am incorrect anywhere he can correct and as his blog was taken into the ref. :-)
Cheers!
|
|
Reporter | |
Comment 2•4 years ago
|
||
One more observation. In Firefox, when you try the below one:
<a href="about:crashes">test</a>
And open it in a new tab, it shows clean page obviously not the content of the about:crahes but here, it should have behaved like it was doing in the IMG tag i.e. it shouldn't open a new tab with a privileged scheme from a non-privileged scheme like when we try the below one in the chrome, edge or any chromium-based browser, it also blocks them:
data:text/html,<a href="chrome://crashes">kirti</a>
Open it in a new tab and you should see that it will say about:blank#blocked.
|
||
Comment 3•4 years ago
|
||
Please don't randomly CC people to security sensitive issues (plus, I don't see how you know that is actually the correct email address)
Eric's blogpost doesn't cover "copy link" and manually navigating, it only covers clicking links directly, and embedding images directly, neither of which work.
|
|
Reporter | |
Comment 4•4 years ago
|
||
I'm not randomly CC'ing him. We worked on the issue of privileged URIs. Due to the reason, I CC'd him.
I know him correct email because he is my best friend and I asked him through his personal twitter handle: @ericlaw
Eric's blogpost doesn't cover "copy link" and manually navigating, it only covers clicking links directly, and embedding images directly, neither of which work.
I worked with him on privileged URI case. That's why, I have added him.
|
|
||
Comment 5•4 years ago
|
||
Dan: I think we should make this public and mark it sec-vector or sec-low, does that sound OK? I'm not sure if we have dupes on file, it wouldn't surprise me if so.
Reporter: I have no way of knowing about your friendship with Eric. Either way, did you originally report the issues with the context menu to Chrome and Edge, and if so, can you provide links to them? In particular, I note that this trivial testcase:
https://output.jsbin.com/waniliraqu
still writes "dangerous" URLs to the clipboard (in all browsers, you can update the URL being copied as you see fit, it doesn't make a difference), and requires less user interaction than what you propose (1 click instead of 2, and less transparency to the user as to what is actually happening). So in effect, I'm not sure what Chromium is trying to address.
I'd like to understand better what threat vectors the Chromium team considered important enough to warrant making this change, without addressing clipboard writes using web APIs.
(In reply to Kirtikumar Anandrao Ramchandani from comment #2)
One more observation. In Firefox, when you try the below one:
<a href="about:crashes">test</a>And open it in a new tab, it shows clean page obviously not the content of the about:crahes but here, it should have behaved like it was doing in the IMG tag i.e. it shouldn't open a new tab with a privileged scheme from a non-privileged scheme
But it didn't, it opened a blank new tab (about:blank, which isn't privileged). The UX is clearly not great, but it's not a security vulnerability and we didn't open "a privileged scheme".
|
|
Reporter | |
Comment 6•4 years ago
|
||
RE#5:
Due to this reason of URIs, I added Eric into the case as he has worked on URIs in the Chrome team and better idea why it is working in that manner. Anyways, answering the questions.
Either way, did you originally report the issues with the context menu to Chrome and Edge, and if so, can you provide links to them?
I have collaborated with a friend and he has sent the case to Chromium Team, the ID number is 1262959.
I understand that trivial case and was going to use it but I wanted to differentiate between Image and hyperlink that's why, I used the 2 click user interactions instead of 1.
still writes "dangerous" URLs to the clipboard (in all browsers, you can update the URL being copied as you see fit, it doesn't make a difference), and requires less user interaction than what you propose (1 click instead of 2, and less transparency to the user as to what is actually happening). So in effect, I'm not sure what Chromium is trying to address.
Do you want to know why the Chrome team blocks such URIs/privileged URIs?
The reason is that Chrome has URIs to test for different crashes for example under the chrome://chrome-urls, you can find that there are example crashes of chrome://inducebrowsercrashforrealz/ etc. which are used for debug purpose bug some attackers can use it for the "nefarious" activities due to which Chromium team might be blocking the privileged URI. Another reason behind that can be of the NTFS corruption assume if a user clicks and paste into another tab if it is an NTFS path, it will end up in an NTFS corruption. Luckily, Firefox has a patch for the NTFS path also, Windows has patched it if I remember correctly from the top of my head but Chrome declined to patch it as it required users to enter the complete NTFS path to exploit the case so, in that case, such cases can be used. I hope this was helpful?
But it didn't, it opened a blank new tab (about:blank, which isn't privileged). The UX is clearly not great, but it's not a security vulnerability and we didn't open "a privileged scheme".
I haven't dug up into this completely yet it was just an observation that can be taken into consideration while patching this bug. So, I thought of adding it into this bug instead of creating a new case and making analysts jump between one or the other. :-)
Adding needinfo flag for Gij sir if in case I missed anything which is yet to be answered.
|
|
||
Comment 7•4 years ago
|
||
(In reply to Kirtikumar Anandrao Ramchandani from comment #6)
RE#5:
Due to this reason of URIs, I added Eric into the case as he has worked on URIs in the Chrome team and better idea why it is working in that manner. Anyways, answering the questions.
Either way, did you originally report the issues with the context menu to Chrome and Edge, and if so, can you provide links to them?
I have collaborated with a friend and he has sent the case to Chromium Team, the ID number is 1262959.
Is this still relating to the context menu "copy link" item? I assumed from comment #0 that the same approach you're using for Firefox was previously patched by Chrome, but the ticket you referenced is still not public.
I understand that trivial case and was going to use it but I wanted to differentiate between Image and hyperlink that's why, I used the 2 click user interactions instead of 1.
Why are you trying to "differentiate between image and hyperlink", and how is that relevant? Both images and links take 2 clicks, using navigator.clipboard takes 1...
Do you want to know why the Chrome team blocks such URIs/privileged URIs?
No, I know the answer to that question - I want to know why they blocked even "copy link address" in the context menu, which does not itself involve navigation. Perhaps this was an explicit choice, or an artifact of how they fixed the other bug, or something else; if it was an explicit choice, I want to know why they didn't also fix the clipboard API (it would be possible, for instance, to parse the copied text and replace problematic URLs).
|
|
||
Comment 8•4 years ago
|
||
Thanks for linking bug 1730236 - why do you think this is a different issue, rather than just a duplicate of that ticket?
|
||
Comment 9•4 years ago
|
||
I wonder if we may consider allowing Paste & Go only for http(s) and disable the option if the clipboard contains any other protocol. That would add a step where the url is visible to the user before further confirmation.
|
|
Reporter | |
Comment 10•4 years ago
|
||
RE#7:
Is this still relating to the context menu "copy link" item? I assumed from comment #0 that the same approach you're using for Firefox was previously patched by Chrome, but the ticket you referenced is still not public.
Yes. When we paste & go, the URI isn't shown which is even more dangerous the URI can have some particular cases where it can be problematic for example there was a case of Abdulrhman like this. So, you should either show the path where it will go when pasting or we should have behavior as we have for an image. The ticket isn't public because the case is created today.
Why are you trying to "differentiate between image and hyperlink", and how is that relevant? Both images and links take 2 clicks, using navigator.The clipboard takes 1...
Because drag-n-drop of image and hyperlink works same but not when we copy the URL. Please try below PoCs:
data:text/html,<img src="about:crashes">
data:text/html,<a href="about:crashes">test</a>
For the first, drag the image and drop it at the end of Tab1 from where we click + to open a new tab but it won't be opened and this has same behavior as hyperlink. But when you copy the link, it isn't the same and thus, I had to use an approach to tell how it should have acted.
No, I know the answer to that question - I want to know why they blocked even "copy link address" in the context menu, which does not itself involve navigation. Perhaps this was an explicit choice, or an artifact of how they fixed the other bug, or something else; if it was an explicit choice, I want to know why they didn't also fix the clipboard API (it would be possible, for instance, to parse the copied text and replace problematic URLs).
They blocked the "copy link address" because there can be problems like this where XSS can be triggered if present. And XSS on a privileged page is dangerous. That's why they are acting in that manner, there are multiple reasons why it should be blocked and not one. Everybody will have different POIs for example:
- They are blocking privileged URIs to stop XSS attacks like this
- They are blocking it because if a user isn't aware which path they are navigating to for example if they by mistake navigate to NTFS path, it will be problematic
- They are blocking such navigation because if there is a UXSS (with site-isolation bypass), an attacker executes JS over there and retrieves confidential information.
Again, there can be multiple reasons why you should either block it or show a path to navigation that will let the user know where he/she is going to end up at.
RE#9:
Exactly! We should block the path where the user will end up as chrome does. When we copy a URI in the chrome, open a new tab and after right-click, it shows "Paste & go to ....." which helps users to know where it is navigating.
@Gij sir, let me know if there are any questions yet to be answered from my side.
|
|
Reporter | |
Comment 11•4 years ago
|
||
RE#8:
Apologies as I forgot to write about this.
Thanks for linking bug 1730236 - why do you think this is a different issue, rather than just a duplicate of that ticket?
Because today while I was under the "My Dashboard" after multiple updates too, I didn't saw case of Privileged URI if there was one, it was duplicated and it didn't have helpful information like this case do. Furthermore, this case has better details than that one even in this case, we have one extra feature yet to be developed i.e. "Paste and go to ...." which is absent in it. Lastly, this case was opened because this is affecting Fenix as well as Firefox on Windows and if I remember correctly, that case was getting a play like cat and mouse due to which it was getting out-of-hand and most probably that was the reason it wasn't receiving update? Hopefully, this case will have sufficient information to track it. :-)
If there are any questions yet to be answered, let me know. Have a great day ahead!
Cheers!
|
|
||
Comment 12•4 years ago
|
||
(In reply to Kirtikumar Anandrao Ramchandani from comment #10)
RE#7:
Is this still relating to the context menu "copy link" item? I assumed from comment #0 that the same approach you're using for Firefox was previously patched by Chrome, but the ticket you referenced is still not public.
Yes. When we paste & go, the URI isn't shown which is even more dangerous the URI can have some particular cases where it can be problematic for example there was a case of Abdulrhman like [this].
Your report didn't talk about paste & go and I don't think we should delegate XSS detection to our users, so I don't think this is relevant. (ie even if users saw the URL they would probably struggle to determine if it's safe or not)
So, you should either show the path where it will go when pasting or we should have behavior as we have for an image.
I don't understand; pasting works when copying either a link or an image so this is very unclear.
The ticket isn't public because the case is created today.
OK, but my request was specifically about the same issue which you claim has been addressed in Chrome, so it can't have been created today... did you not file the older issue that they have already addressed?
Because drag-n-drop of image and hyperlink works same but not when we copy the URL. Please try below PoCs:
data:text/html,<img src="about:crashes"> data:text/html,<a href="about:crashes">test</a>For the first, drag the image and drop it at the end of Tab1 from where we click
+to open a new tab but it won't be opened and this has same behavior as hyperlink. But when you copy the link, it isn't the same
It's the same for me? Copying the link and copying the image link behaves the same for me.
They blocked the "copy link address" because there can be problems like [this] where XSS can be triggered if present. And XSS on a privileged page is dangerous. That's why they are acting in that manner, there are multiple reasons why it should be blocked and not one. Everybody will have different POIs for example:
- They are blocking privileged URIs to stop XSS attacks like [this]
- They are blocking it because if a user isn't aware which path they are navigating to for example if they by mistake navigate to NTFS path, it will be problematic
- They are blocking such navigation because if there is a UXSS (with site-isolation bypass), an attacker executes JS over there and retrieves confidential information.
This still doesn't answer the question - it says why the URLs are dangerous, and why navigation is blocked, and I know that part; I need to know whether the copy disabling was intentional. You're claiming it is but you provide no reference, and more examples of dangerous URLs don't help at all. I really need a reference to the Chromium / Blink team's thinking, not references to Firefox bugs. All 3 of your examples work just the same with my clipboard example, with fewer clicks, so they are orthogonal to the question I'm asking.
|
|
Reporter | |
Comment 13•4 years ago
|
||
Your report didn't talk about paste & go and I don't think we should delegate XSS detection to our users, so I don't think this is relevant. (ie even if users saw the URL they would probably struggle to determine if it's safe or not)
Yes, but we are always allowed to add further observations into the report, yes? Or are we restricted? May I know why you think so this is irrelevant?
OK, but my request was specifically about the same issue which you claim has been addressed in Chrome, so it can't have been created today... did you not file the older issue that they have already addressed?
That's why, I was adding Eric Lawrence who can throw light on the URI issues of Chromium but unfortunately when the reporter added. you removed him. So. I would request you to add Eric Lawrence from Microsoft again for helping me with this.
It's the same for me? Copying the link and copying the image link behaves the same for me.
Obviously, It will be the same and that's what I wanted to put before you. When you drag and drop hyperlinks or an IMG tag, they are behaving the same. But when it came to Copying/pasting, the hyperlink isn't behaving like the IMG tag which ended up in the report. Note: I requested for drag-n-drop and not copying/pasting.
This still doesn't answer the question - it says why the URLs are dangerous, and why navigation is blocked, and I know that part; I need to know whether the copy disabling was intentional. You're claiming it is but you provide no reference, and more examples of dangerous URLs don't help at all. I really need a reference to the Chromium / Blink team's thinking, not references to Firefox bugs. All 3 of your examples work just the same with my clipboard example, with fewer clicks, so they are orthogonal to the question I'm asking.
Would make below requests from my end so, it will be easier to answer:
- Please rephrase the question and ask them separately and what you actually want to know.
- Please add Eric into the report for helping in the discussion as it seems I am not able to make the point crystal clear even though trying it in multiple ways and sharing the testcases.
|
|
||
Comment 14•4 years ago
|
||
(In reply to Kirtikumar Anandrao Ramchandani from comment #13)
Your report didn't talk about paste & go and I don't think we should delegate XSS detection to our users, so I don't think this is relevant. (ie even if users saw the URL they would probably struggle to determine if it's safe or not)
I know why you think so this is irrelevant?
I already said why: I don't think we should expect that our users can tell whether a URL has an XSS embedded in them, so if we determine that allowing people to copy these URLs is a risk, then I don't think showing them the URL in "paste & go" is a "solution" to that problem (not least because in many cases we can't show the entire URL). Hence: it isn't relevant to this issue. You could file a separate issue suggesting we show the clipboard URL in the "paste & go" item (it might be a good idea for other reasons), but it's not relevant for this bug.
OK, but my request was specifically about the same issue which you claim has been addressed in Chrome, so it can't have been created today... did you not file the older issue that they have already addressed?
That's why, I was adding Eric Lawrence who can throw light on the URI issues of Chromium but unfortunately when the reporter added. you removed him. So. I would request you to add Eric Lawrence from Microsoft again for helping me with this.
You said you added him because of a 2-year old blogpost that didn't talk about copy/pasting URLs... but sure, I can add him back.
It's the same for me? Copying the link and copying the image link behaves the same for me.
Obviously, It will be the same and that's what I wanted to put before you. When you drag and drop hyperlinks or an IMG tag, they are behaving the same. But when it came to Copying/pasting, the hyperlink isn't behaving like the IMG tag which ended up in the report. Note: I requested for drag-n-drop and not copying/pasting.
This doesn't make any sense anymore. I do not see any behavioural difference between copying/pasting URLs from links or from images, and I also do not see any difference between dragging images and links to the tab strip. Comment #0 through to comment #9, nobody talks about drag/drop. In comment #10 you claim that copying images vs copying links behaves differently from each other, and that dragging images and links behaves the same, and I said I could not reproduce that. And now you're complaining that you "requested" (requested what?) for drag and drop. I don't understand what you mean.
(Putting it in bold font doesn't make it easier to understand, please stop doing that)
This still doesn't answer the question - it says why the URLs are dangerous, and why navigation is blocked, and I know that part; I need to know whether the copy disabling was intentional. You're claiming it is but you provide no reference, and more examples of dangerous URLs don't help at all. I really need a reference to the Chromium / Blink team's thinking, not references to Firefox bugs. All 3 of your examples work just the same with my clipboard example, with fewer clicks, so they are orthogonal to the question I'm asking.
Would make below requests from my end so, it will be easier to answer:
- Please rephrase the question and ask them separately and what you actually want to know.
Well, what I wanted was the chromium issue(s) where the copy link / copy image link menuitems were removed and/or changed to return about:blank#blocked for privileged URLs.
In the end I gave this up as a bad job and decided to just find things myself. This immediately revealed that I shouldn't have just believed you in comment #0 when you said that things work "correctly" in Chrome. After lots of searching I could not find any evidence that this behaviour was present in Chromium, just that they were replacing navigation attempts to privileged URLs in the parent process if they were not trusted (which makes a lot more sense). Loading https://jsbin.com/cisuqewini/edit?html,output in Chrome (tested on Windows) trivially shows that they too did not disable right click + copy link location, and pasting pastes an unmodified URL. I expect that like us, they decided it wasn't worth breaking that functionality. Same thing (as expected) in Edge. I also checked data URIs and macOS, same thing.
I can reproduce what you described only using images in Chrome. This is likely because the <img> tag attempts to actually load the URL passed to it, runs into security checks, and gets replaced with a safe URL, so when copying the image link that is what you get. Firefox's security implementation works differently and does not replace the URL. This ultimately makes no difference to what a malicious attacker can or cannot do (wrapping an actually loaded image in an <a href=...> is definitely going to work better when attempting to convince users to jump through weird hoops vs. a broken image item!).
I'm duping this over to 1730236 as it is really just the same thing, namely whether we should filter clipboard writes and/or pastes for privileged URLs.
|
|
Reporter | |
Comment 15•4 years ago
|
||
I already said why: I don't think we should expect that our users can tell whether a URL has an XSS embedded in them, so if we determine that allowing people to copy these URLs is a risk, then I don't think showing them the URL in "paste & go" is a "solution" to that problem (not least because in many cases we can't show the entire URL). Hence: it isn't relevant to this issue. You could file a separate issue suggesting we show the clipboard URL in the "paste & go" item (it might be a good idea for other reasons), but it's not relevant for this bug.
The about URIs arent't too big like of 50 chars, afaik. Even if you try to make one, it ends up into a problem URL, I will share one example of "about:" URI where you use any payload/bigger URL, it isn't loading at all or gives any error like chrome does. So, it is good if we can actually show a URL in the paste&go.
You said you added him because of a 2-year old blogpost that didn't talk about copy/pasting URLs... but sure, I can add him back.
Add ericlaw1979@hotmail.com into this bug and the bug you have just made duplicate with so, he can comment on any of them.
This doesn't make any sense anymore. I do not see any behavioural difference between copying/pasting URLs from links or from images, and I also do not see any difference between dragging images and links to the tab strip. Comment #0 through to comment #9, nobody talks about drag/drop. In comment #10 you claim that copying images vs copying links behaves differently from each other, and that dragging images and links behaves the same, and I said I could not reproduce that. And now you're complaining that you "requested" (requested what?) for drag and drop. I don't understand what you mean.
I don't know why you didn't understand the difference between hyperlink copy/paste and Image copy/paste, I tried to show differences in them with test cases for the same, please go to the comments and test cases once again.
Furthermore, the reason why Images block such URIs beforehand while copying privileged URIs in the Image in the Chrome is that images get loaded automatically on page load whereas links do not. That's why when you try:
data:text/html,<img src="chrome://crashes">
Now copy the image link and paste it in the chrome it is about:blank#blocked and I have mentioned the reason just now why they are doing so. I reported a similar case to the Brave team where they told me about this behavior.
When you try below PoC:
data:text/html,<img src="about:crashes">
Firefox doesn't block that privileged URI but Chrome will block this one URI too which is interesting and that point was being kept before you recursively. I hope this has made sense?
Well, what I wanted was the chromium issue(s) where the copy link / copy image link menuitems were removed and/or changed to return about:blank#blocked for privileged URLs.
For that purpose, I was adding Eric but you removed him. I was adding him because he might be aware of those cases better than me, I tried to search for similar cases in the chromium review but didn't find one. Once again, if you add him and if he finds the case, he will share it.
In the end I gave this up as a bad job and decided to just find things myself. This immediately revealed that I shouldn't have just believed you in comment #0 when you said that things work "correctly" in Chrome. After lots of searching I could not find any evidence that this behaviour was present in Chromium, just that they were replacing navigation attempts to privileged URLs in the parent process if they were not trusted (which makes a lot more sense). Loading https://jsbin.com/cisuqewini/edit?html,output in Chrome (tested on Windows) trivially shows that they too did not disable right click + copy link location, and pasting pastes an unmodified URL. I expect that like us, they decided it wasn't worth breaking that functionality. Same thing (as expected) in Edge. I also checked data URIs and macOS, same thing.
Highlighting: I shouldn't have just believed you in comment #0 when you said that things work "correctly" in Chrome. I have explained about why chrome is blocking
data:text/html,<img src="chrome://crashes">
but the Firefox isn't blocking
data:text/html,<img src="about:crashes">
I am mentioning that reason once again: Images get loaded on the page under that tag but the links don't. Now, before you say that one can try iframe, it also blocks them, so, telling beforehand what's difference between them.
I can reproduce what you described only using images in Chrome. This is likely because the <img> tag attempts to actually load the URL passed to it, runs into security checks, and gets replaced with a safe URL, so when copying the image link that is what you get. Firefox's security implementation works differently and does not replace the URL. This ultimately makes no difference to what a malicious attacker can or cannot do (wrapping an actually loaded image in an <a href=...> is definitely going to work better when attempting to convince users to jump through weird hoops vs. a broken image item!).
See. You're giving reason yourself that IMG tag attempts to actually load the URL passed to it. Yes, that's correct. The image gets loaded automatically whereas links don't load automatically on the page when in the hyperlink only.
|
|
||
Comment 16•4 years ago
|
||
(In reply to Kirtikumar Anandrao Ramchandani from comment #15)
Add ericlaw1979@hotmail.com into this bug and the bug you have just made duplicate with so, he can comment on any of them.
The duplicate is public, you don't need to be CC'd to comment on it.
This doesn't make any sense anymore. I do not see any behavioural difference between copying/pasting URLs from links or from images
I don't know why you didn't understand the difference between hyperlink copy/paste and Image copy/paste
There is no difference in behaviour in Firefox though... I guess you meant there is a difference in Chrome, but that wasn't clear in comment 10, or any of the subsequent comments (and even now in comment 15 you didn't clarify this!). You're just saying "load these two things and see the difference", but there is no difference [in Firefox] -- both cases write an unmodified URL to the clipboard. You're in the Mozilla/Firefox bug tracker, if you make any unqualified claims about behaviour, of course I'm going to interpret them as relating to Firefox. If you want to compare it to behaviour in other browsers, make it explicit to avoid sending people on wild goose chases.
|
||
Comment 17•4 years ago
|
||
(In reply to Kirtikumar Anandrao Ramchandani from comment #15)
The about URIs arent't too big like of 50 chars,
The short about: urls are not dangerous. They show content that in some cases runs with enhanced privileges, but simply loading them causes no harm. What would be harmful is if malicious content could influence the content that is opened. The obvious way is some kind of XSS, perhaps by passing parameters to the about: page parses -- but those aren't going to be short. See for example bug 1422467 -- and Gijs' point was that just showing the user a URL like that before loading it isn't much of a defense because most people can't be expected to notice. Another risk might be postMessage() to a privileged page that has a bug in validating the messages it listens to. For that you need a window reference, which you can't get if we don't let content open links like that. References aren't a worry if a user copies a URL and opens it themselves.
Not all about: urls are short, btw. Here's one that's valid on my system at the moment: about:cache-entry?storage=disk&context=O^userContextId=3&partitionKey=%28https%2Cmozilla.org%29,&eid=&uri=https://bugzilla.mozilla.org/static/v20211025.1/js/global.js
Comment 9 might help protect people from the dirty trick of getting someone to copy and then Paste-and-go about:crashparent, but that's more of an annoyance than actually exploitable.
We don't consider this issue to be a problem. "Dangerous to let web content open" is not the same thing as "dangerous to open", and we believe strongly in letting users have control and visibility into what their browser and web sites are doing.
|
|
Reporter | |
Comment 18•4 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #17)
Seems reasonable.
Not all about: urls are short, btw. Here's one that's valid on my system at the moment: about:cache-entry?storage=disk&context=O^userContextId=3&partitionKey=%28https%2Cmozilla.org%29,&eid=&uri=https://bugzilla.mozilla.org/static/v20211025.1/js/global.js
Interesting, thanks for sharing. :0
Comment 9 might help protect people from the dirty trick of getting someone to copy and then Paste-and-go about:crashparent, but that's more of an annoyance than actually exploitable.
True. But it would be interesting if Firefox too gets something like chrome for eg: chrome://inducebrowsercrashforrealz/ then it will also be annoying as well.
Thanks for clarying.
|
|
||
Updated•1 year ago
|
Description
•