Closed Bug 1535289 Opened 5 years ago Closed 5 years ago

[Safe Browsing] If the provider has no update triggered, warnings are not displayed for harmful websites using a Latin non ascii character profile

Categories

(Toolkit :: Safe Browsing, defect, P1)

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox-esr60 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix

People

(Reporter: obotisan, Assigned: dlee)

Details

Attachments

(2 files)

Attached file test.html

Affected versions

  • ESR 60.6.0
  • Latest Nightly 67.0a1
  • Firefox 66.0

Affected platforms

  • Ubuntu 18.04 x64
  • Windows 10 x64

Steps to reproduce

  1. Create a profile with Latin non ascii characters (" ÝÙá ") or any other Latin characters from this link: https://terpconnect.umd.edu/~zben/Web/CharSet/htmlchars.html.
  2. Go to this link: http://testsafebrowsing.appspot.com/s/malware.html or download and open the attached hmtl with Firefox.

Expected result

  • A warning page is displayed.

Actual result

  • The page is opened without any warning.
  • In the html case, the left iframe is opened without any warning.

Regression range

  • I am not sure if this is a regression, but I will try to find it as soon as possible.

Additional notes

  • This happens if the google, google4 and mozilla (about:url-classifier) updates are not triggered.
  • If you go to about:url-classifier and trigger the updates, then this issue is not reproducing.
Component: DOM: Security → Safe Browsing
Product: Core → Toolkit

Dimi, any thoughts on this?

I don't think this is a regression. I can reproduce the issue on a build from 2014-06-01 and before that, the warning page is not displayed for the right iframe either.

Assignee: nobody → dlee
Status: NEW → ASSIGNED
Flags: needinfo?(dlee)
Priority: -- → P1
Has STR: --- → yes

Hi Oana,
I tried to reproduce this but I don't really see a problem.
This is how I tested:

  1. open firefox with profile manager
  2. create a new profile with Latin non ASCII characters
  3. Go to this link: http://testsafebrowsing.appspot.com/s/malware.html
  4. No warning message is shown
  5. Wait for a few minutes(should be less than 1 min actually)
  6. refresh the page http://testsafebrowsing.appspot.com/s/malware.html
  7. warning message is shown

I am not sure if the problem you encountered is the step 4, which means if you wait for around 1 min and then refresh, the warning should show up. If it is, it is the expected result because we are waiting for the SafeBorwsing database to be downloaded. (no matter if the profile name has Latin non ascii characters or not).

If this is not the case, could you tell me more detail about how you reproduce this bug? Thanks!

Flags: needinfo?(oana.botisan)

Sorry it took me so much time to answer, but I had a lot of work.
I tried using the steps you left in comment 3 and you are right the bug is not reproducing, but then I opened both the site and the test page I attached to this bug in the same profile in two different tabs. I waited and refreshed the two pages. One of them (the site usually) had the warning displayed and the other didn't. Only after a browser refresh the page showed the warning.

Flags: needinfo?(oana.botisan) → needinfo?(dlee)

(In reply to Oana Botisan, Desktop Release QA from comment #4)

Sorry it took me so much time to answer, but I had a lot of work.
I tried using the steps you left in comment 3 and you are right the bug is not reproducing, but then I opened both the site and the test page I attached to this bug in the same profile in two different tabs. I waited and refreshed the two pages. One of them (the site usually) had the warning displayed and the other didn't. Only after a browser refresh the page showed the warning.

Hi Oana, Thank you for helping check this.
When you said you open the site and test page in two different tabs, is that after step 7 in Comment 3?(or after step 3?)
Is it possible to record a video?
Sorry, I can't reproduce this one so I need some help, thank you!

Flags: needinfo?(dlee) → needinfo?(oana.botisan)

I think this bug might be reproducing by managing to open two potentially dangerous sites almost at the same time.
I came over this issue while running the test for Safe Browsing and in those tests we open site after site with content that might be dangerous(like the ones from the description).

I hope this helps. Please don't hesitate to ask me if you have more questions that I can help you with.

Flags: needinfo?(oana.botisan)

(In reply to Oana Botisan, Desktop Release QA from comment #6)

Created attachment 9056126 [details]
safe browing not triggered.gif

I think this bug might be reproducing by managing to open two potentially dangerous sites almost at the same time.
I came over this issue while running the test for Safe Browsing and in those tests we open site after site with content that might be dangerous(like the ones from the description).

I hope this helps. Please don't hesitate to ask me if you have more questions that I can help you with.

The video helps, thank you! I can reproduce this now :)

Hi Oana,
Here is the reason why sometimes the site(phishing.html) doesn't show a warning:

In the test.html, there are two iframes

  1. "https://testsafebrowsing.appspot.com/s/phishing.html"
  2. "https://itisatrap.org/firefox/its-a-trap.html"

The itisatrap.org site always shows a warning because the URL is hard-coded in the codebase for test purpose, no matter an update is triggered or not.

The reason that the site(phishing.html) still doesn't show a warning after triggering an update manually via about:url-classifier, is that the webpage is cached by necko. So when you refresh the webpage, it doesn't send any HTTP request, it just reuses the content.

If you are ok with this, I think we can close this bug.

Flags: needinfo?(oana.botisan)

So this issue is related to the page. I understand.
If that is the only reason this bug happens, then, yes, I think we should close the issue.

Flags: needinfo?(oana.botisan)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: