2 ms·
You should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.
by sunaurus 4y ago
You should still protect against MITM attacks even with read-only websites - not all attacks are based on stealing user input.
- the8472 4y agoWhat's the threat model here?
- NovemberWhiskey 4y agoYour ISP inserts random javascript and pop-ups into HTTP sites to tell you that you're nearing your data cap and that you should go buy an additional-data-pack. Like Airtel used to (still does?) in India.
- sunaurus 4y agoRandom examples of MITM attacks I could do on a read-only website: * Inserting malicious JavaScript * Changing content on trusted websites in order to mislead people * Replacing downloadable application binaries with versions that contain malicious code
- the8472 4y agoMalicious JS can be served directly, e.g. via ad iframes. Injecting it into a low-stakes (read-only) site doesn't gain much, does it? Points 2 and 3 are the same, they're about integrity which could be had cheaper with content-addressing (hashes uniquely identifying the content) rather than pulling in the full TLS+CA machinery.
- pixl97 4y agoOk, you have a site with signed firmware downloads. I mean, they are signed securely right? A user messing with the stream can only send you another signed firmware the device takes, and not anything they attempt to create (unless they guess your signing key somehow). But, you make a mistake in firmware version XYZ and there is an RCE in it. So you pull it off your site and now XZZ is the latest version. Only problem is, anyone that can MITM you can serve version XYZ that the client will accept and make the machine exploitable by an RCE.