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.
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
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
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.
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?
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.
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."
@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.
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.
@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.