Mark non-secure origins as non-secure
Disabled
121–130 of 268 posts
Mark non-secure origins as non-secure
Disabled
When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…
Earlier quoted context omitted.
> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. I would argue this model of application is substantially m…
No. https://en.wikipedia.org/wiki/Same-origin_policy
Also, the attacker could inject tags with a src attribute pointing to "https://evil.com?userdata=...".
Also, if the attacker is already man-in-the-middle attacking yoursite.com, they could make the site's code make ajax calls to "yoursite.com/nothing-to-see-here". Users looking at the network requests may not notice anything is going on.
How can I go about securing a server without a domain? Just a static IP? Let's Encrypt doesn't allow IPs and the owner doesn't care for a domain. Context: small business with a web based application in a local server, all they need is to be able to access reports from their phone.
Let's Encrypt is one of the best things that happened to the web recently. I wish we had more choices though. Relying so much on a single party is unnerving.
Now they can just use Let's Encrypt.
Earlier quoted context omitted.
I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it. It won't stop a modified code from pushing data to anywhere in the web either. > More fortunately still the application is a diff tool, so it can perform self validation Yes, if the…
Also if the attack did take place at the router then HTTPS certainly is irrelevant regardless of what the browser is doing. HTTP and HTTPS ride over TCP. If you can modify code at the router then you can change the TCP packets to spoof the page address or HTTP response and sidestep HTTPS or the requested domain entirely. https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transi…
Earlier quoted context omitted.
> A MITM attack on a static site is definitely possible, maybe even easy, but I'm not going to worry about it unless I have something important to protect. HTTPS doesn't protect the content of your site from being stolen, it protects your users from hostile third-party content masquerading as yours.
>it protects your users from hostile third-party content masquerading as yours Exactly. What does anyone lose if my anonymous untrusted blog does something untrustworthy for that one reader who has an infected router? Should I encrypt messages I write on post cards, because I'm afraid a disgruntled postal worker will write "you suck" on the bottom? The worst case scenario here is temporary vandalism.
There is one static webpage that I won't put HTTPS on; the dashboard of my pi.hole. Though it's more of an architectural decision as it enables the DNS server to blackhole HTTPS more effectively (since it just gets a CONNREFUSED back). Really, it's an exception to the rule and only because I can't ask my guests to install my pihole CA on their devices (many of which don't support that stuff anyway). Well and there is…
Here's the truth about security: people are clueless about it and so corporations and governments abuse that by pushing their own agendas, not related to security. Same corporations that tell you to "secure" your unimportant static website with https also want to force you to run random javascript in your browser from unknown parties, identify you at all times, link everything to your phone number, etc. In the end we…
If your site isn't using HTTPS it will always be "not secure", but always accessible.
If it is, then it's accessible until someone decides to revoke your certificate for whatever reason.
The old quote is relevant again: "Those who give up freedom for security deserve neither."
When I read things like that, I always think of the paper "The Rational Rejection of Security Advice by Users". [1] Yes, content injection is bad, but the chance of it happening multiplied by the damage it could cause to your users is probably less than the the effort required to shift a static blog site to HTTPS. (Do not underestimate the leap in difficulty from copy-pasting from an Nginx tutorial to understanding h…
This is important. Because the discussion around HTTPS tends to train users into think that HTTPS = Web Security. I totally agree that it's important, and I understand the attack vectors. But what about your outdated WordPress/Joomla installation? What about your default password on your admin site? Those I think are more serious issues, but of course harder to tackle. To exploit a MiTM you need to be on the same net…
Or, say, your ISP injecting ads and tracking scripts into unencrypted pages your browser requests.