3 ms·

Is denial of service from an attacker who has your source something you actually consider when building a product? I can see trying to prevent data breaches an

Is denial of service from an attacker who has your source something you actually consider when building a product? I can see trying to prevent data breaches and such, but going so far as to be wary of denial of service attacks from people who have your source code might be wasted effort.

dllthomas 13y ago
You should code as if any attacker has your source. If denial of service attacks are something you need to consider, you need to consider them from someone who has your source.
- fragsworth 13y ago
  Denial of service attacks are usually not devastating (they've happened to many large services multiple times) and there's a very real engineering cost in being absolutely certain that you are immune to such attacks. I think most people here don't fall under the umbrella of those who need to consider denial-of-service attacks. When your primary goal should be to launch your product (which you aren't even sure will take off) I would think trying to prevent denial-of-service attacks is a waste of time.
  - dllthomas 13y ago
    I'm not sure I disagree with any of that. I simply said that if you need to consider DoS you should consider DoS with the assumption your attacker has access to your source.
bcoates 13y ago
The prevalence of frameworks means attackers probably have your source, or at least enough of it to be interesting. This specific denial of service attack hit a lot of systems in 2012, and all you needed to know was which framework they were using (or just try all of them, as the attack has incredible leverage) It's as simple as crafting a query-string that results in an O(n²) hashtable building, and allows you to burn minutes of server CPU with each request.
- fragsworth 13y ago
  Coming from the perspective of a startup that is building a product, future risk/estimated damage from DOS attacks is not worth any of today's efforts to prevent. I mean, weren't they all able to fix it after the fact and not suffer much in the end? These are problems you only run into if you've got a successful product (which happens very rarely) - and solving these problems before you have users might not be a good allocation of engineering resources for startups. I liken it to making a system that scales in advance to millions of concurrent users when you haven't even got one.
  - jameshart 13y ago
    The thing is that anywhere in your code where you are doing something which involves hashing data to create a digest for some purpose you are almost certainly attempting to do something a bit clever (I'm going to map the problem from the domain of entities to a domain of proxies for entities that are smaller and easier to deal with. I'll just deal with the special cases...). And if you're making a decision to use Murmur2 in that role, you're probably trying to be very clever. Whenever a programmer tries to do something clever, in my experience, there is something they haven't thought about. Often the something they haven't thought about leads to a security vulnerability. The fact is it's often difficult to tell the difference between a place where the security properties of the digest algorithm you use are irrelevant, and a place where it might be critical. For example, a zip file uses a CRC32 checksum to validate each file; git uses SHA1 to uniquely identify objects; CouchDB shard mapping uses a strategy based on CRC32... if git had used murmur, would that cause problems for it? Is CouchDB being clever by using a fast hash for sharding at the expense of being secure? Now, quick, make a decision which algorithm to use to generate Etag headers for your web API HTTP response entities: are you going to go with SHA256 or Murmur2? Murmur2 is much faster, and it's certainly a clever solution... but are you sure you didn't create a security hole? I'm not saying "nobody ever got fired for choosing SHA256," but I am kind of saying that you have to be very sure you know the security model you're operating in before you build on a hash algorithm that doesn't provide strong extension and preimage resistance.

dllthomas 13y ago

You should code as if any attacker has your source. If denial of service attacks are something you need to consider, you need to consider them from someone who has your source.

fragsworth 13y ago
Denial of service attacks are usually not devastating (they've happened to many large services multiple times) and there's a very real engineering cost in being absolutely certain that you are immune to such attacks. I think most people here don't fall under the umbrella of those who need to consider denial-of-service attacks. When your primary goal should be to launch your product (which you aren't even sure will take off) I would think trying to prevent denial-of-service attacks is a waste of time.
- dllthomas 13y ago
  I'm not sure I disagree with any of that. I simply said that if you need to consider DoS you should consider DoS with the assumption your attacker has access to your source.

bcoates 13y ago

The prevalence of frameworks means attackers probably have your source, or at least enough of it to be interesting. This specific denial of service attack hit a lot of systems in 2012, and all you needed to know was which framework they were using (or just try all of them, as the attack has incredible leverage) It's as simple as crafting a query-string that results in an O(n²) hashtable building, and allows you to burn minutes of server CPU with each request.

fragsworth 13y ago
Coming from the perspective of a startup that is building a product, future risk/estimated damage from DOS attacks is not worth any of today's efforts to prevent. I mean, weren't they all able to fix it after the fact and not suffer much in the end? These are problems you only run into if you've got a successful product (which happens very rarely) - and solving these problems before you have users might not be a good allocation of engineering resources for startups. I liken it to making a system that scales in advance to millions of concurrent users when you haven't even got one.
- jameshart 13y ago
  The thing is that anywhere in your code where you are doing something which involves hashing data to create a digest for some purpose you are almost certainly attempting to do something a bit clever (I'm going to map the problem from the domain of entities to a domain of proxies for entities that are smaller and easier to deal with. I'll just deal with the special cases...). And if you're making a decision to use Murmur2 in that role, you're probably trying to be very clever. Whenever a programmer tries to do something clever, in my experience, there is something they haven't thought about. Often the something they haven't thought about leads to a security vulnerability. The fact is it's often difficult to tell the difference between a place where the security properties of the digest algorithm you use are irrelevant, and a place where it might be critical. For example, a zip file uses a CRC32 checksum to validate each file; git uses SHA1 to uniquely identify objects; CouchDB shard mapping uses a strategy based on CRC32... if git had used murmur, would that cause problems for it? Is CouchDB being clever by using a fast hash for sharding at the expense of being secure? Now, quick, make a decision which algorithm to use to generate Etag headers for your web API HTTP response entities: are you going to go with SHA256 or Murmur2? Murmur2 is much faster, and it's certainly a clever solution... but are you sure you didn't create a security hole? I'm not saying "nobody ever got fired for choosing SHA256," but I am kind of saying that you have to be very sure you know the security model you're operating in before you build on a hash algorithm that doesn't provide strong extension and preimage resistance.