The basics of web browser security: an introduction



  • @tarquin: Well, that was certainly easy to find:
    https://imgur.com/a/vgnK2



  • @gt500: VirusTotal report on the URL used in testing:
    https://www.virustotal.com/#/url-analysis/u-2384dc8f31dad438b9a2d2809a1ed4b82c747cdf7ccac01fcee32e455da81af0-1521934109

    Viewing the report is safe, but please leave the testing up to the QA team and security experts.


  • Moderator

    @gt500 This is not the notification UI being manipulated, it's just an HTML in the page trying to fool people, the Vivaldi UI for notifications is totally different.



  • @an_dz: So you're saying it's a social engineering attack intended to fool people into clicking "Allow" twice without re-reading the notification?


  • Moderator

    @gt500: As a reply to each topic.

    1. That's impossible, what sites do is create an HTML that imitates the Chrome UI (or other browsers) to make people think it's Chrome. When IE was the king this also happened with download messages, popup messages and plugin installs.

    2. Any site is free to request things from users, for example Vivaldi requires users to register and to be logged in to post in this forum/blog. It's up to the users to boycott sites that request things that they consider stupid, like having to accept notifications.

    3. I Agree, and that's why I've created and grouped bugs to expose those Chromium settings in our UI a while back. I really hope they add it.

    4. Also agree, and it's the same reason as point 3. With our own UI we can have a better UI/UX with better wording.



  • @an_dz: So you're saying it's a social engineering attack intended to fool people into clicking "Allow" twice without re-reading the notification?

    Upon further testing that does appear to be the case. When you click "Allow", they open a popup window that's too small for the notification asking for permission to allow web notifications to be fully visible, so it is partially cut off by the right side of the browser window, obscuring what it says.

    It's still an effective demonstration as to how easy it is to abuse the feature. We all know that when it comes to the average user, there are two kinds of people: Those who always click "Yes" on every popup, and those who always click "No" on every popup.

    Besides, why does this feature even exist? Since when were RSS and ATOM not enough?


  • Moderator

    @gt500 There's nothing one can do, it's impossible to "block" a website from doing this. The thing is that you are responsible for your actions, whatever you do will have its consequences.

    Besides, why does this feature even exist? Since when were RSS and ATOM not enough?

    1. RSS/Atom are extra standards. Notifications API is part of JS.
      Since they are extras basically only Presto Opera ever adopted as a default feature of the browser. Notifications API is a part of ECMAScript/JavaScript, which is an essential part of every browser and so must be implemented by all JS engines.

    2. RSS/Atom is static, Notifications API is dynamic.
      RSS/Atom is a webpage with some "news" which the browser downloads whenever they wish to, you can configure the interval of update in your RSS/Atom reader. You can't edit older messages because they become different and so become "new".
      The Notification API is a notification popup that fires whenever the site wishes, so they fire when the action occurs and not when you decide to download the "news" as in RSS. It's also JavaScript and so the notification can be modified on the fly to match inputs the user has made even without this data going to any servers.

    Examples

    RSS/Atom is for getting the latest Blog posts in the Vivaldi forum. It doesn't matter if you see this now or some hours later.

    Notifications is for getting a popup when someone sends you a message, for example in Telegram or WhatsApp. You want those to be instantaneous, right after you receive the message.



  • @an_dz: Internet Explorer has had a built-in RSS reader for years, and Firefox used to have one as well (sadly they removed it at some point).

    RSS/Atom is static, Notifications API is dynamic.

    Feeds are dynamically generated by some sort of script each time they are loaded by an RSS reader, that way they always show the latest content. They would be of no use if they were just static pages.


  • Moderator

    @gt500 IE is officially dead since Win10 and I think they only added support for RSS and not Atom. Firefox had RSS only briefly. And my point still applies, it's a different standard and browsers either did not add it or removed it.

    Feeds are dynamically generated by some sort of script each time they are loaded by an RSS reader, that way they always show the latest content. They would be of no use if they were just static pages.

    Obviously, I've developed a feed with PHP, I know how it works.

    I guess I should have said that the Notification API is "Client-sided dynamic", while RSS is "Server-sided". After all there's no "real" static page because the owner can change it any time. But I thought the explanation below the "title" was enough to show that.

    Edit:
    To clarify, server-sided dynamic vs. static is actually how the implementation is done. If the feed XML is generated when the user requests the page that's dynamic. If the XML is generated beforehand – when the blog post is created – and the user request only downloads this already made XML file then it's static.


  • Vivaldi Team

    @gt500 said:

    scripts have a way to tell if a user has interacted with the notification that asks users for permission to allow web notifications. Scripts should not have access to this sort of information.

    Interestingly, a script doesn't need to know. It can just keep asking anyway, just in case, and the browser will ask for permission until the user interacts with a dialog. As a result, it really makes no difference to the interaction with the page, and it may as well therefore be told. With other permissions cases, the page can absolutely know, and there is no way to prevent it, since it never gets any callbacks called, and never gets access to the information it asked for.

    I will see if I can find you an example.

    A quick note about why it is always best to file it as a bug report instead of discussing it here. In order to protect users from abuse, we ask that you file potential security issues in the bug tracking system, so that investigations can take place in private, and fixes can be prepared - if needed - before the details are made available for malicious persons to see. That way, any potential attacker does not get to know about an issue and attack someone before they can be protected. Our BTS is here:
    https://vivaldi.com/bugreport/

    Other users have responded to your post already with the correct answer though, so I will leave the discussion in place here 🙂

    Browser makers can't simply blame standards organizations for poor implementation of features, or for poor security precautions when implementing features.

    Trust me, nobody is blaming anybody. Browsers and the standards bodies are not enemies. They work together, discuss things together. The implementors are often the same people as the standards authors. Just look at the W3C specs, and see how many specs are edited by someone who works for a browser vendor.

    What I am saying is that in addition, security researchers and regular people are also allowed to take part in all of this process, and we absolutely do (I have been doing this sort of thing for many years myself). Specs are not just blindly produced and followed without some serious thought about potential security implications - we really do try to make sure everyone is as safe as possible. You yourself could choose to take part too, since you clearly are interested in making sure that implementations cover the possible corner cases. That's great, by the way!

    During the production of a specification, if anyone thinks of a possible line of abuse, they discuss it with the other specification editors. Together, everyone comes up with a solution that prevents that particular case, and the solution gets put into the specification. This also protects future implementations from falling into the same trap.

    If we - as a browser vendor - realise that there are security implications of a standard that we are implementing, or have implemented in the past, we often come up with our own solution, and propose that solution to the standards bodies. In most cases (if the details are not already public), we also share our proposed solutions with other browser vendors, allowing everyone to benefit. This is a community where we help each other.


  • Vivaldi Translator

    Browsers may check and show the domain when downloading, but without a reverse lookup or validation, you can only assume that the domain matches the correct IP address.

    DNS poisoning, man-in-the-middle attacks, and even punycode can mask a domain.
    Simply looking for a valid certificate can be misleading if you are not paying attention, especially in a world where some certificate authorities and 3rd party vendors will happily spew 1000s of bad but valid certs into the system, and then stay quiet until they are caught.

    How well a site you visit has protected itself against spoofing is a part of the picture that is being ignored by most browser makers.
    Cross-referencing a domain you land on is not enough anymore.

    Bare in mind that many sites serve their downloads from a different domain, and this adds to confusion, as the cert the user can see, may not cover the domain where the file comes from.
    Unless the download window has a way to fetch and display the cert from the other domain, looking in the address bar is often pointless.
    Think back to the Linux Mint distro that was swapped on one of the official repos.
    Those using p2p or the hash keys (which only nerds use) listed at the main site were protected because they had an extra validation system.
    A proposed HTTP extension "Trusted Linker Download Redirection" has been published which solves 2 problems;
    a) is the download via HTTPS?
    b) is it the file you expected?
    https://www.bennish.net/tldr/
    Unfortunately, the acronym TLDR has doomed it to obscurity.

    Vivaldi is a feature driven browser, but however not taking the lead in adding security / privacy features.
    Old Opera added security features before anyone else did, and for example even gave the users an easy way to give manual feedback to phishtank.
    User reporting of bad sites in any form should be a feature of all browsers. Relying on googles naughty list and their problematic cert cancellation process is not enough.

    Avira Scout has HTTPS Everywhere and Privacy Badger built in.
    Yandex browser has DNSCrypt built in.

    There are existing open source systems that can add useful validation systems into all browsers.

    Let us use Vivaldi.com and net as examples of not being able to truly validate the site or the files they serve.
    As a visitor I know what domain name I expect to see, but not what IP address it should be attached to.
    The certificates are tied to domains not IP addresses, and the correct IP address is very important.
    Vivaldi sites are not using DNSSec, so DANE validation cannot be done, and the site can be spoofed, even though you may be using a secure DNS.
    alt text
    alt text
    Cloudflare supports DNSSec so sites behind it do not have an excuse.
    https://dnssec-name-and-shame.com (test vivaldi domains here)
    https://www.dnssec-validator.cz

    When downloading the browser from a Vivaldi sub-domain, the user will be getting the file from a different IP, and with no DNSSec or way to cross reference a hash, there is no way to guarantee for sure that the file is the correct one, even if the installer contains a vivaldi cert.
    Maybe 1% of all internet users will be using DNSSec through choice, and a little more by accident.
    99% of those is because speed is the reason to swap, unless they are Yandex users, in which case it will be 99% of users are using authenticated DNSSec via the browser.

    Wikileaks releases showed that the NSA interfered with DNS or engaged in man in the middle attacks to distribute their own versions of several AV packages, as AV is a good place to get into someones system.
    So are web browsers, which are a major part of daily life.
    Fake builds of Vivaldi have already turned up, though thankfully not from Vivaldi itself.
    .....or have they ?

    Vivaldi HQ has a local (Iceland) private (no logging) Open DNS resolver that uses DNSSec and DNSCrypt (secure and authenticated).

    Vivaldi should lead by example and secure their own domains, and add more robust validation and authenticity features to the browser.



  • When you connect to a secure (https) website, Vivaldi and other browsers use various protocols to establish a secure connection with the website. All data is encrypted so that only the browser and the website can see what is being sent over the connection. Anyone else who can monitor what is being sent over the network would be unable to decrypt the data, at least not within a reasonable timespan.

    That is misleading. If a site uses https, that only does make the data encrypted after the handshake, and the hostname of the site is being sent cleartext during DNS lookup and initial connection. So anyone who can monitor the network still sees what sites a user visits. You even have this info in the article about VPNs.

    Please add this info in the paragraph about https with the link to the VPN article, so that readers unfamiliar with this do not think that https fully secures privacy.


 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.