Weweb DANGEROUS website notification on google chrome

Hello,
Today I got multiple notifications from google chrome I usually use to learn weweb.
It always happened when I try to upload media (images) to weweb.
the result, the image success uploaded but not showing on the uploaded list and when I use my editor it shows broken image icons.

did anyone find this problem? any suggestion?

thank All

Screenshot 2023-04-07 010111

I’m also suddenly getting this warning which is very concerning. Assuming it’s not an issue that’s my fault, would very much appreciate getting this resolved. thanks all

1 Like

This have been handle on our side, things should get back to normal
(People were using Weweb for scam)
In the meantime, you can just click on the detail button to continue

1 Like

Hello :wave:

Thanks for flagging up the issue @alvhyz. It should be fixed now but rest assured you and the users of your app were not at risk.

To give you a bit more context:

  • A user used one of our domains to scam people.
  • Google tagged this domain as malicious which is why you were seing this warning.
  • We removed the user and Google removed the malicious tag but it took almost a day.
  • There was nothing malicious for our users and they did not risk anything by bypassing the red page.
  • We took mesures and released some limitations to prevent this from happening again.
  • We will continue to work on this issue in the following weeks to ensure it does not happen again.

I hope that clarifies things. Please don’t hesitate to ask if you have any further questions.

Best,
Joyce

1 Like

Hello Joyce,
It’s really nice to get a replay from you, especially after I watch all of your Youtube videos for the last 2 months to learn how to use weweb.
big hope this community will be bigger and weweb can help people like me to make the idea come true.

thank again

2 Likes

Glad I could help! I hope so too :slight_smile:

Hi @Joyce, a client recently informed us that there users are receiving this notification when opening up emails with a link to their project. Is it possible this is related?

Mmm no idea. Will report it immediately so the tech team can look into it. Could you DM me the link to the WeWeb project so we can have a good starting point?

1 Like

I want to followup here in the case this is happening to others. I believe there is a security vulnerability and/or issue with using custom CSS that causes a “Not Secure” message on browsers.

  • We have had a spike of complaints over the last few weeks that our client’s app is “not secure”.
  • This is not long after we implemented some custom CSS on the project.
  • The above screenshot is from a user of theirs. They had the message pop up as they were reviewing our website.
  • The only link to weweb-production.s3.amazonaws.com in production was this specific CSS file.
  • After scanning the CSS link with one tool, we got this response: " No redirect from HTTP to HTTPS found. You should redirect your website visitors to the HTTPS version to avoid the “Not Secure” browser warning."
  • Another security software, BitDefender, classifed the weweb-production.s3.amazonaws.com website as a fishing site.

@aurelie @Joyce or someone else, it looks like weweb-production.s3.amazonaws.com does not force HTTPS, which is causing the Not Secure warning. Is this a known configuration (or known bug), or is this unintentional?

The HTTP/HTTPS thing is probably not the issue - though, like @caffeinatedwes says, it’s not perfect.

This reads like a “one rotten apple spoils the barrel” problem that you also run into with shared email servers. Sharing one domain among customers means that if one user (or a rogue agent accessing that bucket) uses it untowardly, everyone suffers the reputational effect when that domain goes on a “bad actor” list by these vendors. Like someone getting access to that bucket and putting malware on it that one of these systems learned about and then recorded the domain as unsafe. Getting the domain off a blacklist like that is hard - for good reason.

I would try using a different domain for the file in question. If you can, maybe host it on your own CDN away from the (at least previously) compromised bucket. I find Digital Ocean Spaces cheap and super-easy to use. I have a hard time breaking my $5/mo minimum with them, even serving all the video on Statechange

I’m sure the weweb team will look into it and release a solution as soon as they can- they’re world-class and care a lot about being good (web) hosts. The above is about solving this edge case for ourselves and our customers in the meantime.

2 Likes

Hello :wave:

The tech team is looking into it. Thanks a lot for providing that additional information @caffeinatedwes, really appreciate it :pray:

1 Like

Hey @raydeck, thank you so much for the response.

If I’m understanding this correctly, it sounds like it’s possible someone was using WeWeb’s file storage (using the upload file UI in the editor which stores the file in http://weweb-production.s3.amazonaws.com/)—the same storage we use for this CSS file—in a way that got it reported or placed on a blacklist, and that’s what’s causing the “not secure” and other flags.

I would try using a different domain for the file in question. If you can, maybe host it on your own CDN away from the (at least previously) compromised bucket. I find Digital Ocean Spaces cheap and super-easy to use. I have a hard time breaking my $5/mo minimum with them, even serving all the video on Statechange

I appreciate the suggestion. I’m going to bring this to our team.

@Joyce, if it helps provide more context, we uploaded that CSS file referenced previously to WeWeb in the editor via the file upload UI. Then, we added this custom code to load that CSS.

2 Likes

Hi @caffeinatedwes :wave:

The tech team investigated further but didn’t find any issues on our side or on the domain name used to host the CSS file.

Can you try replacing the domain in the old URL with the cdn.weweb.io and let us know if that helps?

OLD : https://weweb-production.s3.amazonaws.com /designs/5a93f020-f163-4cab-8e9f-06febbed6445/files/gradients.css

NEW : https://cdn.weweb.io /designs/5a93f020-f163-4cab-8e9f-06febbed6445/files/gradients.css

@Joyce Thank you! We went ahead and solved this per @raydeck’s recommendations, but I’ll leave some notes for others so they don’t necessarily have to go that route.

In summary, Bitdefender was the only anti-virus software that 1) reported that our site was malicious and 2) also has tools to let you know if a site is on it. Here you can see that the old WeWeb CDN was flagged by Bitdefender, but when we tested it with the Digital Ocean URL, we don’t have any issues. However, the new CDN url doesn’t have any flags or warnings as well, making me think the fix Joyce suggested should work.

2 Likes

Ok, that’s great news! Thanks for taking the time to share the fix

1 Like