6 ms·

for each connecting user, serve malware javascript. For most web servers, this involves replacing a file. And since your attacker can just go to the page with

by adgar 15y ago

for each connecting user, serve malware javascript. For most web servers, this involves replacing a file. And since your attacker can just go to the page with crypto JS to receive the "clean" version, s/he can prepare the malware JS in advance. Overall, compromised server can be shut down in minutes during which only a fraction of user base will have been affected. How does this not add to security? Oh, it adds to security. For the length of time between compromise and a replaced JS file. As noted above, s/he can easily rewrite your JS appropriately before entry, in which case you've got about a minute or two of extra safety. If you assume you can detect any compromise of your system within 3 minutes, then yeah, 1 or 2 minutes out of 3 is great. If you miss it, then it's a whole lot of work for barely any benefit. And assuming you can detect any compromise within 3 minutes is highly optimistic.

donpark 15y ago
Any malware script served to users will also be served to monitors and compromise is just a matter of comparing hashes with originals. Re any compromise, only detection of compromise to content/script served to client is necessary in this approach. In extreme case, public read-access to most of the server might even be plausible (although not advisable) IMO.
- adgar 15y ago
  And when China hacks your server, takes a little bit longer, and inserts a rule that only serves the malware JS to Chinese-allocated IPs, will your monitor systems be checking from mainland China, too? Maybe they don't modify your app's code, but insert an iptables rule that achieves the same effect. When a scheme relies on perfect intrusion detection you are not discussing security, you're discussing damage control.
  - donpark 15y ago
    There are safety measures one has take to deploy stuff I describe to protect against subset attacks like you mentioned as well as hackers using sleepers or logs to identify monitors, etc. It's not easy stuff and definitely not something startups should take on w/o getting side-tracked. This is why I wrote "when applied appropriately" in my original comment.

by adgar 15y ago

donpark 15y ago

Any malware script served to users will also be served to monitors and compromise is just a matter of comparing hashes with originals. Re any compromise, only detection of compromise to content/script served to client is necessary in this approach. In extreme case, public read-access to most of the server might even be plausible (although not advisable) IMO.

adgar 15y ago
And when China hacks your server, takes a little bit longer, and inserts a rule that only serves the malware JS to Chinese-allocated IPs, will your monitor systems be checking from mainland China, too? Maybe they don't modify your app's code, but insert an iptables rule that achieves the same effect. When a scheme relies on perfect intrusion detection you are not discussing security, you're discussing damage control.
- donpark 15y ago
  There are safety measures one has take to deploy stuff I describe to protect against subset attacks like you mentioned as well as hackers using sleepers or logs to identify monitors, etc. It's not easy stuff and definitely not something startups should take on w/o getting side-tracked. This is why I wrote "when applied appropriately" in my original comment.