Opera 21 for Windows and Mac is now out on the Stable channel. As with most major releases, the main focus is on the new features, which are discussed over on the Desktop Team blog. In addition, we have included a reworking of the Address field, to cope with some situations which could have caused confusion.

The address field has always been a mix of editable input and status field, and this mix presents some areas that need special attention. The address field is supposed to let the user know which page they are really looking at. When a link is clicked, it needs to update to show the new address, including following redirects. When a user begins editing it, it can no longer show that page address, and now shows the address the user is typing. However, there are some cases where the user may not be aware that they are putting the address field into edit state.

If a user drags and drops a new URL into the address field, this edits the address, leaving the address field in edit state. If the page now redirects to a new page while the address field is still in edit state, should it show the new address, erasing what the user was editing, or should it remain in edit state? The answer is that it should only remain in edit state if the user has indicated that they really are editing it, such as by typing in it.

If the window is redirected to a download, should the address field show the download address, or the address of the page that remains visible? The answer is that it should always show the address of the page that is visible, so that the user realises what page is visible.

What about if the page loads a resource such as an image or inline frame that requires HTTP authentication; should the address field show the address of the parent page, or the resource? Again, the address field should show the address of the overall page, not the address of a resource in it.

These are all corner cases where Opera had problems. A number of security issues were fixed in this release, which affected how the address field displays the Web page address under various circumstances. Normally, we would give only a summary, but since the impact of these bugs is relatively minimal, we will go into some detail so you can see the sort of work that has taken place:

  • DNA-17861; Low severity: Address bar spoofing with downloads, reported by Keita Haga.
    This bug occurred when a download was started in a popup which had inherited the security context of the opening page. In such a case, the address field should show either the about:blank address, or the address of the page that opened the popup. Opera would previously show the address of the download.
     
  • DNA-18354; Low severity: Address bar spoofing with downloads, reported by Jordi Chancel.
    This unrelated bug only occurred when the user dragged and dropped a URL into the address bar, which started a download. The address bar would then be right aligned, showing the wrong end of the address. This could allow a specially crafted URL to show what appeared to be a domain name, but which was actually path data. It would be missing the domain highlight, but may be enough to fool some users.
    Simultaneously, it would leave the address bar in edit state, showing the download address instead of the address of the currently displayed page. Since the user may not realise that they had changed the address and put the address bar into edit state, we have now changed this to show the address of the displayed page. We’ll go into more details about this issue in a future blog post.
     
  • DNA-19280; Low severity: Address bar spoofing with Data URIs, reported by Jordi Chancel.
    When a user chooses to open a link in a new tab, this should still display the address as normal. However, with Data URIs, Opera would accidentally right-align the address field, showing the wrong end of the address. Again, this could allow a specially crafted URL to show what appeared to be a domain name, but which was actually path data. As with the previous bug, it would be missing the domain highlight, but may be enough to fool some users.
     
  • DNA-15733; Low severity: Address bar spoofing on Mac platform with dialogs.
    When a page opened a popup, the popup address should show either about:blank for popups without a displayable address, or the true address of the popup if it has one. In cases where there is no address, if the popup loads a resource that uses HTTP authentication, Opera would become confused, and show the address of the resource in the address field. Although this is relatively harmless while the dialog is showing since the user cannot interact with the page, Opera would continue to show it after the user cancels the dialog.

In almost all cases, some amount of user interaction was required to produce a working spoof, which would make them a little more difficult or less reliable to abuse. Nonetheless, we don’t like it to be possible, with or without user interaction, to produce confusing or spoofed addresses, so we are eager to fix such issues. We will be continuing our work on the address field in Opera 21, so it is possible that other fixes will follow, if new corner cases are uncovered.

During the development phase, the Developer and Next channels also had some additional issues which are fixed in Opera 21 Stable. These did not affect any releases on the Stable channel:

  • DNA-19841; Low severity: Address bar spoofing on Mac platform with dialogs.
    This is the same as DNA-15733, but for different types of non-displayable address.
     
  • DNA-19829; Low severity: wrong security status shown for plug-in data.
    When securely loaded plug-ins on secure pages loaded data from an insecure server, Opera would forget to downgrade the displayed security state of the parent page, and would continue to show it as secure.

A huge thank you to the researchers who found and reported issues to us. If you uncover any exploitable security issues in Opera, please report them to us confidentially, like the bug reports listed above, so we can fix them and protect users before the details are made public. We’ll be happy to credit you in a blog post like this as well. Happy bug hunting.

Back to top
  • Thanks for detailed info.

  • John

    Perhaps slightly off-topic, but also security related. I used the mixed content Flag in Opera 21 to disable insecure content. SSL labs client test still shows some types of Active content allowed: XMLHttpRequest and Websockets.

  • Nekomajin42

    Thanks guys!

  • Sidney Moraes

    It is good to know Opera is getting safer! Thanks Opera devs 🙂