Thanks for the report, unfortunately there isn't enough information here for us to assess whether a vulnerability actually exists. The files you mention are indeed where Chrome stores sensitive information, but "simple Javascript" does not normally have access to your local disk. If script loaded from the web can indeed access that information then it would be a significant vulnerability.

Are you able to provide detailed instructions and a proof-of-concept exploit that achieves the data exfiltration that you are claiming? A video by itself is not useful if we can't reproduce the problem ourselves.

For future reference, the following page has good advice for security bug submissions:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

 I was actually having 2 method in my mind.In both methods,I am planning to extract the following files,whose average size for a regular user will definitely be less than 20 Mb.

The files extracted are Cookies, Favicons, Login Data, Web Data and if size doesn't exceed 20 MBs , History and Network Action Predictor  files also.all the journals are left out as they lack any data.

 In the first method , I am planning to use a combination of API and Ajax  upload style. As the basic location of all the above mentioned files is the same for all Chrome Browsers installed  in all Windows PCs.Hence the reference can be preset to the exact location (i.e local disk C- Users-USER-AppData-Local-Google-Chrome-User Data-Default),and then using the AJAX upload method to upload these files&send them to the set server.

In the second method, It is solely the User's fault that he may get hacked.In this method,the user is asked to attach the set files as attachment in the server website.This can be done by tricking him into believing that this files are need by some credential service provider.

In both the cases,Chrome has the fault that all user data is freely accessible at the PC storage without any encryption what so ever.All the data can be seen even with any ordinary word processing software. .

With the help of the internet ,even a child can now know the ways to write a java script to upload a file,and i used these 3 websites for reference

*https://www.nczonline.net/blog/2012/05/08/working-with-files-in-javascript-part-1/

*http://www.w3schools.com/jsref/prop_fileupload_files.asp

*https://www.tutorialspoint.com/jsp/jsp_file_uploading.htm

This code can be used for the first method. Here we  are directly passing the reference of the target files(which is always constant in windows),you are using ajax to upload them.

This is all possible due to the FormData object, which is defined in XMLHttpRequest Level 23. This object represents an HTML form and allows you to add key-value pairs to be submitted to the server via the append() method:

var form = new FormData();
form.append("name", "ssssss");

The great thing about the FormData object is that you can add a file directly to it, effectively mimicking a file upload by HTML form. All you have to do is add the File reference with a specific name, and the browser does the rest. For example:

// create a form with a couple of values
var form = new FormData();
form.append("name", "sssssss");
form.append("photo", control.files[0]);

// send via XHR - look ma, no headers being set!
var xhr = new XMLHttpRequest();
xhr.onload = function() {
    console.log("Upload complete.");
};
xhr.open("post", "/entrypoint", true);
xhr.send(form);

Once the FormData object is passed into send(), the proper HTTP headers are automatically set for you. You don’t have to worry about setting the correct form encoding when using files, so the server gets to act as if a regular HTML form has been submitted, reading file data from the “photo” key and text data from the “name” key. This gives you the freedom to write processing code on the backend that can easily work with both traditional HTML forms and Ajax forms of this nature.

The programs in this are in just examples and by setting proper references we are able to upload a file 

Using Drag and Drop method,which can be done only with user doing so himself,this code is required

<div id="your-files"></div>
<script>
var target = document.getElementById("your-files");

target.addEventListener("dragover", function(event) {
    event.preventDefault();
}, false);

target.addEventListener("drop", function(event) {

    // cancel default actions
    event.preventDefault();

    var i = 0,
        files = event.dataTransfer.files,
        len = files.length;

    for (; i < len; i++) {
        console.log("Filename: " + files[i].name);
        console.log("Type: " + files[i].type);
        console.log("Size: " + files[i].size + " bytes");
    }

}, false);
</script></code>

Well the Main Vulnerabilities in both the cases are,
1.The Important Files regarding a User are easily available in the PC to anyone,whether he is the owner or an online hacker,without any special software being installed in the PC.
2.All these data are kept in Unencrypted form,without any safety measures and can easily be read by any common word processing software as they are stored as text.
3.These files can be transported,via uploading to a website,knowingly or unknowingly.

> The great thing about the FormData object is that you can add a file 
> directly to it, effectively mimicking a file upload by HTML form.

Not quite. Yes, JavaScript can add data to a FormData object, but the script *must already have access to the file data* in question.

In order to steal a file off the user's PC, you must either:

1. Entice the user to select the file using a File Upload Input control, or
2. Entice the user to drag/drop the file from the file system into the webpage

>(which is always constant in windows)

If you found a bug whereby you could, given a file path in JavaScript, obtain JavaScript access to the data in that file without user-interaction, that would be a great vulnerability.

nevinkoshy2000@ -- We don't have an actionable vulnerability described here. 

The text in this bug describes how you might transmit stolen data after you've circumvented the browser security model and gotten access to the data from the local file system. However, it does not provide any way of circumventing the browser security model and accessing data from local files.

If you do find a way to access a file on the user's disk without their explicit action, please update this issue with that information.

Thanks!

No sir,I guess we had a confusion over here.The user's disk is accessed with their help in ONLY the drag and drop method.My actual focus is one the first method.

In the first method,I am using AJAX to upload a preset file,where the Attacker provides the  victims FILE's PATH and the target files NAME only(no size and last modified information ) using java script.The victim does not have any commendable role over here.I am using 2 variables,one to initialize the path and the other to initialize the file name.As these 2 are initialized earlier,there is Nothing to be done by the victim .

The second method (i.e drag and drop),was provided as just a backup.

And I believe I have listed out the main stored data vulnerabilities in comment 6.Kindly Please do refer it .

This is the basic idea of the hack exploit.

*Initialize a variable with path and some others with JUST the name of the item to be uploaded.

*1 variable has the common path,other have just the name of the item to be uploaded.

*The code is executed in the browser and the data is collected and uploaded using AJAX.

Re #9 and #10-- If you can create a webpage which does this ("Use AJAX to upload a preset file") then this would be a serious vulnerability. However, you have not provided an example of this, and to the best of our knowledge, it is not possible. 

Can you please provide an example?

I should further clarify what I mean by "preset file" in item #11-- Yes, you can easily send to the server any text you like as if it were a "file". 

This is not a vulnerability.

A vulnerability would be if the data you could send to the server were from an *actual file* off the user's disk. For instance, say I've got a file C:\Secrets.txt. If you could build a webpage that uploads the contents of the Secrets.txt file to the server without user-interaction, *that* would be an interesting vulnerability. 

Well,First of all,I am terribly sorry I took so long too respond.
In this time,I actually did some research into how usual file upload system of many websites works.

In most cases ,the method employed to get the files is using a function docyment.getElementsById("files"), where the USER selects the files to be uploaded.

Here basically ,all that is done is the user is initializing the name, type and path of the desired file unknowingly.The size too might be obtained in the subsequent statements.

The idea that I had previously submitted also said the same thing,but in a different way.The basic core of my idea ,is that instead of letting the user provide these details,the Hacker is just initializing them (name,type and path of the object).This is not an easily rectifiable flaw.

The flaw of chrome is that all the sensitive user data is stored without any encryption and can be freely transported from one PC to another.This flaw can be exploited and used to target chrome users and thus compromising their security and privacy.Their personal data could be stolen.So basically all that chrome has to do,to rectify the error is that the personal data should be encrypted in some form.

> the Hacker is just initializing them (name,type and path of the object)

Yes, if the hacker can specify the path of a file to upload and have that file upload, *that* would be a security bug.

> the personal data should be encrypted in some form

Users have to be able to interact with their own data, which means that any encryption you do would require that the key to decrypt that data be kept on the computer (unless you required the user to type a password every time they opened or saved or moved a file). 

Well,sir as I mentioned in my previous comments (,#10) and the main report,the path is always the same in various computers with chrome browser.

Always,the personal data of the user lies in  files in the folder Default of the google chrome,all these being present inside the Users tab.The general way  to reach these files is following the path given below: 
C:/Users/USER/App Data/Local/Google/Chrome/User Data/Default.
Here in the default folder,you can find the necessary files.

To initialize the path, a variable should be initialized as:
"C:/Users/USER/AppData/Local/Google/Chrome/User%20Data/Default/",
because this is the general path.

Each variable that is to be extracted has to added to this path,by adding its name as a continuation to the path given above.

For example,if you want to upload the file Login Data of the victim ,then
to the existing path of "C:/Users/USER/AppData/Local/Google/Chrome/User%20Data/Default/",
an additional line for "Login%20Data" ,should be added.
The final path becomes:
"C:/Users/USER/AppData/Local/Google/Chrome/User%20Data/Default/Login%20Data"
Hence the last part changes with the name of the file.

The name of the file is a constant in every machine running on windows,and so is the file's type.So the same path can be used again and again.


   

As noted in Comment #7, knowing the path to the file is *not* sufficient to steal any data from the user, because the browser does not have the ability to load arbitrary local files without user interaction, even if the script knows the file path. 

The attacker must to entice *the user* to expose the file's data to the webpage using the file upload control or via drag/drop. 

Sir,what you mean by "load arbitrary local  files without user interaction"?
If you are mentioning an upload button,then it is possible to upload files by just selecting them.If you are meaning ,something like the file name and file type,we are initializing those too .Hence there is amble information for an upload.

I'm not sure what you mean by 'just selecting them'.

Rather than repeating ourselves like this, instead please supply a HTML page that reproduces the problem that you believe you've found. This will either convince you that you cannot do so, or startle me and result in this bug being reopened. 

Thanks!

By selecting them , I mean you are choosing those files as in the case of a regular upload. IN this case, I would like to convey the meaning that I am passing the reference to the file.

Please supply a HTML page that reproduces the problem that you believe you've found. This will either convince you that you cannot do so, or startle me and result in this bug being reopened. Thanks!

i got a way in which people who use active X can be at risk,can i post that?

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot