In the recent Opera 21 Stable release, we fixed a number of bugs relating to the address field. Normally, we would not want to give away too much about a security issue, as it would give a potential attacker the instructions for how to abuse it. However, the exploit for DNA-18354 requires the user to be tricked into following the attacker’s instructions, and it is good for users to remain vigilant, so we wanted to take this opportunity to go into some details, and let users see what sort of tricks an attacker might use against a complicit user.

Most text-based inputs (form inputs, textareas, or the address field) support drag and drop. Text selections or links can be dropped into the input using the mouse. When dropped into an input, it edits the value of the input, inserting the text wherever it was dropped. This makes quick and easy editing possible, and is a behaviour expected on most graphical systems. In the case of an address field, there are two options when the text is dropped: should it edit the address, or simply cause the browser to visit the address that was dropped (like it would when dropped on a tab)?

Opera’s answer was to visit the address immediately. However, the address field would become confused when that happened, and would remain in edit state. This caused the address to become right-aligned, as the editing caret would be positioned at the right side of the address during editing. Normally, visiting the address would load a new page, and cause the address field to immediately return to left-alignment. When the newly loaded address started a download, however, this would leave the address field in edit state, causing the address to remain right-aligned. If the attacker carefully measured the browser window size, they could then generate the dropped address the perfect length so that the part that remained visible in the address field looked like a complete address instead of the right side of it:

http://evil.example.com/this_text_is_hidden_to_the_left/www.opera.com/this/is/not/really/opera.com

Opera highlights the domain portion of an address in the address field, and this attack relied on the user not noticing that it was missing. It also relied on the user being tricked into dragging an address into the address field – there are many ways that a page can make a user think they are dragging a picture or other object, but the attack relied on them dropping it in the right place. Users need to remain vigilant, and not blindly follow such instructions from a page. Why is a page asking you to drag something onto the address field or tab bar? Why is a page asking you to click and press a series of keyboard shortcuts without giving you any feedback? Sometimes it’s innocent. Sometimes it’s not.

There was an unrelated but seemingly similar issue fixed in Opera 19 for Mac. That issue relied on users dropping another type of link onto the tab bar. The new tab’s address field would then fail to show the link address properly, and would re-use an old address instead. This could be used to make the user think they were visiting one site, but the page would actually be controlled by a different site.

The good news is that because of automatic updates, users will have been protected from these issues as soon as the automatic update happened. Silent updates make this much easier – users are protected automatically – which is why we use this approach in Opera. The Desktop Team are working on ways to make silent updates even more easy for users who do not normally use an administrator account on their computer.

Back to top
  • NoName

    How about changing the look of the address bar when in edit-mode as well as not selected? Loosing the highlighting on the domain is not something you would instantly notice.

    As it is now, a person could go to his own phising site and replace the URL with the real site, then ask me to login. I would have a hard time noticing it. An exception is sites with SSL, which looses the padlock icon.

  • tarquinwj

    “How about changing the look of the address bar when in edit-mode as well as not selected?”

    It does in fact normally change the badge when you edit it, to show a “search with…” icon. However, when this particular bug was triggered, part of the address field confusion was that the badge and address field highlighting would show the “web page loaded” state, while the address field was actually still half-way stuck in edit state.

    • NoName

      It only change if the text in edit-mode is not an URL. If you type in “http://example.com” on this site, it shows the same icon.

      • tarquinwj

        Oh, quite right. Thanks for the correction. I have passed this to the interaction designers to see if they can make it show an “editing” icon in cases where you are typing a valid URL.

        Note again though, that would not have made any difference in the case of this bug, because the badge would have acted like the address field was not in editing state, even though it was.

        • NoName

          Great!
          And thanks for the clarification.

  • :up:

    “Opera highlights the domain portion of an address in the address field” It is not very noticeable