1774951 - Guessing the URL a cross-origin iframe was redirected to by listening to the load event

Status: RESOLVED DUPLICATE of bug 1741034

(Core :: DOM: Navigation, defect)

Description

[negibokken]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36

Steps to reproduce:

It's described on https://crbug.com/1248444 as a REPRODUCTION CASE. But I compliment the case for being easy to reproduce.

• Download 3 files(me.php, victimName.php, attack.html) on https://crbug.com/1248444
• Place these files in the same directory
• Replace http://localhost with http://example.com:3000 on attack.html
• Add 127.0.0.1 example.com on you /etc/hosts
• Serve by using php command: php -S 127.0.0.1:3000 -t .
• Access http://localhost:3000/attack.html (not example.com:3000)
• Then you will get two alerts (it may need to click in a window to get a second alert)
• And one of the alerts says, "The iframe was redirected to http://example.com:3000/victimName.php"
• So the attack.html can get the name of the path (victimName.php) that is sensitive information (username).

The information of a User-Agent is as below:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0

Actual results:

The cross-origin iframe onload event for the current URL won't be fired.

I quote the original issue.

This likely happens because a navigation to the current URL is treated as a soft reload and it doesn't trigger the load event (unlike a normal navigation).

Expected results:

The cross-origin iframe onload event for the current URL should be fired.

Comment 1

[Andrew McCreight [:mccr8]]

The same reporter of the Chrome issue reported some similar issues. I'm not sure if this is a dupe of them or not. I'd assume they'd report the same issue if we were affected by it but I haven't checked.