Potential phishing with the url parameter

[smoretti]

Hi

Our institute web security officer found a potential security issue with the url parameter that can be used with any URL such as https://google.com

An attacker could use this vulnerability to deceive end users by redirecting them to replica sites (and hide his malicious URL by using google short URL, for example) or cause misleading pop-ups to appear in order to harvest personal details. This attack variant is commonly known as “phishing”. In a phishing attack, users redirected to a replica website could be tricked into downloading Trojans, key loggers and other malware. These scenarios could result in reputational or regulatory damage through identity theft. Furthermore, an attacker could also potentially inject malicious “fas” and “nhx” files to, maybe, compromise your application.

Is there a configuration option to limit the url usage to the same/only domain that runs wasabi?

Thanks

[veidenberg]

Hi,

Sure, it’s easy to add a line of code to filter the url param value, but the whole purpose of url param is to import external data (from other domains/servers). Can you give an example of potential url param phishing? Wasabi uses the url source only for downloading plain text files, without redirecting or execution. Anything else than sequence/tree data will give “unknown file format” error.

Andres

[smoretti]

I don't have example of potential phishing url, this comes from our a bit paranoid security guy. But I could imagine than something like Cross-Site Scripting (XSS) could be possible, or something more damaging. So an option to filter the url would be great.

Then it will be up to the wasabi administrator to activate it or not.

[veidenberg]

I can add the configuration option for url param but I'm not sure it is a good idea since 1) it is not a fix 2) it disables the purpose of url param (maybe the url param should to be removed instead). I still need an example test case (e.g. redirection to google.com/pop-up using the url param) or at least a detailed explanation how the security flaw would work.

Security hole is a serious issue but I cannot fix what I don't understand (there is no test case). The domain filter configuration option is not a fix since I cannot verify wether it actually works (no test case) and more importantly, the fix needs to be permanent (in all Wasabi instances), not dependant on wether a user/admin enables a configuration option.

Please ask the security officer for a test case (url param value that redirects/causes a popup in Wasabi).

BR,

Andres

[smoretti]

I asked for a test case. Will let you know.

[smoretti]

In the meantime I tried to play with this in script.js because a solution on the apache side is maybe not applicable as wasabi JavaScript runs client-side.

I have added around

                if(model.offline()){ //direct download (maybe cross-domain)
                    getfile({fileurl:file.url, name:file.name, error:showerror, success:loadfile});
                } else { //through Wasabi server
                    ajaxcalls.push(communicate('geturl', {fileurl:file.url}, {retry:true, error:showerror, success:loadfile}));
                }

            var localDomain = location.protocol+'//'+location.hostname+(location.port ? ':'+location.port: '');
            if(file.url.includes(localDomain)) {
                ...
            }
            else {
                return showerror('Restricted to ' + localDomain + ' only');
            }

It prevents opening an URL that is not from the domain hosting wasabi. But it does not close the import window and does not display the error message I put.

[smoretti]

Our security officer has no test case, it was just a general remark about potential phishing with the "url" parameter.

The url parameter is very useful but maybe not secure enough.

• It does not complain when the URL does not exist. The "importing data" box stays open for ever. This is also what I got with the code I tried to add.
• It accepts any kind of URL/files. I tried with a zip file, wasabi opened it but the alignment and tree rendering is full of ?

[veidenberg]

Web browsers restrict file downloads to the local domain (own server) because of the same-origin policy, unless the datafile server supports workarounds (jsonp or CORS) or the local server downloads and directs the file (browser gets the file via local domain URL). The Wasabi backend server has "geturl" call for downloading/directing remote files. I added "settingsmodel.urldomain" option but since anyone can overwrite javacript variables from the browser javacsript console, the domain restriction should to be enforced server-side. For Wasabi server, the "urldomain" settings can be added to the server settings (default_settings.cfg) for that purpose. If Wasabi server is not present (model.offline()==true) then the urldomain restriction is only in place for users on the Javascript side (if you set it in the script.js).