Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Security: URL Spoof with http authentication dialog and pdf prompt dialog
Reported by, Apr 29 2015 Back to list
This bug can display a prompt dialog box through a pdf file, under a url of a different origin, which displays an http authentication dialog box.

Chrome Version: [42.0.2311.135 ] + [stable]
                [44.0.2384.0] + [trunk build]
Operating System: [Windows 8, Ubuntu 14.04]

Required software: Web server with support for php.
                   Web server should serve content from and
                   Enable chrome pdf plugin if it is disabled.

1. Download urlspoof3.html, auth.php, formsubmit.pdf, pdfForm.php and userresponse.php.
2. Host downloaded files on local web server's root folder.
3. Open chrome
4. Visit will load formsubmit.pdf.
5. formsubmit.pdf will display a prompt dialog which will ask user's age.
6. After 2 seconds page will be redirected to
7. But confirm dialog displayed from will remain.
   Authenitication dialog displayed from will be visible under confirm dialog.
8. Enter a number in prompt dialog and press OK.
9. Wait 5 seconds.
   formsubmit.pdf will submit number typed by user to
   But this form submission will be not visible through browser UI.
   This form submission request will be visible in web server's access log file.
10. Open a new tab and visit
    userresponse.php will display number typed by user.

* formsubmit.pdf contains javascript code to display Confirm message box and to submit form. You can view this code by opening formsubmit.pdf in a pdf editor and viewing code for Javascript OpenAction.

181 bytes View Download
167 bytes View Download
1.5 KB Download
81 bytes View Download
177 bytes View Download
This bug is separated from  issue 477278 .
Please see comment 13 of  issue 477278 .
Comment 2 by, Apr 29 2015
Labels: Cr-Internals-Plugins-PDF Security_Impact-Stable Security_Severity-Medium
Status: Assigned
Assigning labels based on the previous bug.

@raymes: Can you take a look?

@meacer: Do you think this should be medium or low severity?  In the similar  issue 295695 , comment 28 rated it as low because (1) it depends on the victim site showing an interstitial and (2) the prompt is a limited form of a spoof.  In this case, the spoof is a bit more effective against sites that use HTTP auth, since the user is already expecting a dialog for entering a password and they might put it into the wrong dialog.  Tentatively assigning medium severity.
Project Member Comment 3 by, Apr 29 2015
Labels: Pri-1
Status: Started
Comment 5 by, May 1 2015
Labels: M-44 Cr-Security-UX
Hmm it would be great if someone with more WebContentsImpl knowledge could chime in here. I'm seeing something quite interesting. WebContentsImpl::DidStartProvisionalLoad gets fired during the redirect but it doesn't seem to get further than that, and so I don't think there is anything in the code that will cause the dialogs to disappear by that stage. I guess that the modal credentials dialog prevents it from getting further.

As to why this doesn't happen in other circumstances (e.g. with iframes popping alerts, etc.) usually this jams up the renderer from being able to do anything else since everything is running in the same process. So the redirect will never get hit until the modal dialogs are clicked away. However in our case we have a BrowserPlugin running in a separate process from the embedder so the redirect is running in parallel with the alert dialog.

So my gut feeling is that we will actually see this problem occur with OOPIF as well. I tried to test this theory however it appears that modal dialogs don't work at all when coming from cross-process iframes at present.
creis: do you have any suggestions regarding #6? Thanks!
Comment 8 by, May 11 2015
Comment 9 by, May 18 2015
Sorry, I was out on vacation.  (Really wish there was a OOO setting for crbug.)

Can you point me to the code that puts up the dialog in the PDF case?  It doesn't seem to go through WebContentsImpl::RunJavaScriptMessage, and I don't know where to look.
Comment 11 by, May 19 2015
Thanks!  I'll try to catch that in a debugger to see what to suggest.
Comment 12 by, May 19 2015
Labels: Cr-Platform-Apps-BrowserTag
I think I see what's happening.  The inner (guest) WebContents is showing the dialog via WebContentsImpl::RunJavaScriptMessage (contrary to what I said in comment 9), which gives it a dialog_manager_.

Later, the *outer* (embedder) WebContents shows an interstitial page.  That gets to WebContentsImpl::AttachInterstitialPage, which would normally call dialog_manager_->CancelActiveAndPendingDialogs(this) to dismiss any modal dialogs once the interstitial is shown.  However, dialog_manager_ is still null in the outer (embedder) WebContents, so it doesn't call CancelActiveAndPendingDialogs.

This seems like a problem with BrowserPlugin.  The guest is maintaining dialog state, and the embedder is trying to clear it.  Ideally the guest would let the embedder handle the operation directly, but that seems unlikely in this case (e.g., because RunJavaScriptMessage is closely tied to the RenderFrameHost in the guest).  OOPIFs won't face this because they share the same WebContents.

lazyboy@/fsamuel@: How do you usually handle this type of problem with BrowserPlugin?  Should the embedder tell all of its guests to CancelActiveAndPendingDialogs (in all the places it would normally do that itself)?  Is it even possible to iterate over all of its guests?
@12, Yes, we do have "broadcast to all guests" pattern:
For example we broadcast when system's screen info changes:
WebContentsImpl::ScreenInfoChanged() ->
BrowserPluginEmbedder::ScreenInfoChanged() ->
GetBrowserPluginGuestManager()->ForEachGuest(web_contents(), base::Bind(
It seems like having the embedder broadcast to all guests to CancelActiveAndPendingDialogs() is sensible, though I've just started to read this thread and it's possible I'm missing something.

Are there other places where we have duplicate state across embedder/guest that we should be concerned about? Maybe unrelated, but I recently noticed that opening a PDF inside another WebView (e.g. in BrowserSample) allows the PDF inside the webview to generate a context-navigation menu, and open a tab in the main browser context ... that also seems like a potential problem (I've filed this issue as:
wjmaclean/paulmeyer - is it ok if I assign to one of you since it's more generally BrowserPlugin related?
Please do let me know if you won't have time for this though. Thanks!
Comment 18 by, May 20 2015
Comment 15: Yeah, I'd be concerned about this type of bug happening in other parts of WebContents.  It could probably happen anywhere that the inner guest WebContents has some state that the user interacts with via the outer embedder WebContents...

For this bug, I'm ok with having the embedder tell its guests in all the places that WebContentsImpl calls CancelActiveAndPendingDialogs.  We should think about ways to generalize this to work better for other (and future) cases, though.
Comment 19 by, May 20 2015
Exploring a possible solution here:

Also CC'ing Avi for context on dialogs and interstitials.
Labels: Cr-Internals-Network-Auth
Comment 22 by, May 27 2015
Status: Fixed
Should be fixed in r331584.  We should be able to verify in tomorrow's canary to decide whether to merge the fix.
Project Member Comment 23 by, May 27 2015
Labels: -Restrict-View-SecurityTeam M-43 Restrict-View-SecurityNotify Merge-Triage
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on

- Your friendly ClusterFuzz
Labels: Merge-Request-44
Verified the fix.  This has been live since 45.0.2415.0 and is looking safe to merge.  (I had a brief scare from issue 495214, which was a crash involving extension dialogs that started in the same timeframe as this CL, but there's another CL responsible for that one.)

Ok to merge this to M44?
Labels: -Merge-Request-44 Merge-Approved-44 Hotlist-Merge-Approved
Approved for M44 (branch: 2403)
Project Member Comment 26 by, Jun 2 2015
Labels: -Merge-Approved-44 merge-merged-2403
The following revision refers to this bug:

commit 0fc455a3b21e2a6ac68771641c2a4b04008349c0
Author: creis <>
Date: Tue Jun 02 01:15:13 2015

Dismiss browser plugin modal dialogs when the embedder needs to.

Test from wjmaclean@.  PDF simply shows an alert dialog using script.

BUG= 482380 
TEST=See bug for repro steps.

Review URL:

Cr-Commit-Position: refs/heads/master@{#331584}
(cherry picked from commit 89a0f782193755ad7a0b93c58dbcc1b96528405f)

Review URL:

Cr-Commit-Position: refs/branch-heads/2403@{#165}
Cr-Branched-From: f54b8097a9c45ed4ad308133d49f05325d6c5070-refs/heads/master@{#330231}


Labels: Merge-Request-43
Shall I merge this to M43 as well?
Labels: -Merge-Request-43 Merge-Review-43 Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M43), manual review required.
Project Member Comment 29 by, Jun 3 2015
The following revision refers to this bug:

commit 0fc455a3b21e2a6ac68771641c2a4b04008349c0
Author: creis <>
Date: Tue Jun 02 01:15:13 2015

@dxie: Friendly ping: should I merge this to M43?
laforge is the release manager for M43, not dxie.
Comment 32 by, Jun 12 2015
Labels: -M-43 -Merge-Review-43
We'll stick with M44 for this one.
Labels: -Merge-Triage reward-topanel Release-0-M44
Labels: CVE-2015-1278
Labels: -reward-topanel reward-500 reward-unpaid
As mentioned in the release notes, $500 for this report as well. We'll be in contact to collect details, though please contact me at timwillis@ if you haven't heard from our finance department in a week.
Labels: -reward-unpaid reward-inprocess
Project Member Comment 37 by, Sep 2 2015
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Labels: -reward-inprocess
Processing via our e-payment system takes ~7 days, but the reward should be on its way to you. Thanks again for your help!
Project Member Comment 39 by, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member Comment 40 by, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label
Sign in to add a comment