rurcliped
Joined 8 years ago
Joined 8 years ago
the idea is that "habitablets" are a type of "tablets" that (when widely adopted to reduce packaging waste and shipping waste) will ultimately make our planet more "habitable"
1. the attacker can see (but not decrypt) the victim's TLS traffic to example.com
2. an attacker-controlled website makes the victim send many different invalid requests to example.com, each of which gets an error message
3. some data in each request is attacker-controlled, but authentication data in headers is filled in by the victim's browser
4. example.com compresses response data before encrypting it
5. because repetitions affect compression, the response size is smallest when the authentication data matches part of the attacker-controlled data
6. after enough requests, the attacker knows the authentication data to login to example.com as the victim
One workaround for CVE-2012-4929 was to set up the server so that an error message never depended on the request data. Before CVE-2012-4929 was announced, people thought it was sufficient to sanitize the error message (i.e., avoid XSS) but CVE-2012-4929 prompted a shift toward producing exactly the same error message for all invalid requests. (Not sure, but I think this was the original motivation for Google's famous "That's an error. That's all we know." messages.)
There were better CVE-2012-4929 defenses later, but the cargo cult had already formed. (Some subset of) a generation of developers believed that customized error messages were Very Bad because they enabled account takeover.
https://www.eff.org/pages/list-printers-which-do-or-do-not-d...
"Some of the documents that we previously received through FOIA suggested that all major manufacturers of color laser printers entered a secret agreement with governments to ensure that the output of those printers is forensically traceable."
1. "NoSQL document database with MongoDB-like queries ... powered by the open source database engine RocksDB" doesn't give me enough confidence that my application will work. Some limitations are unstated. For example:
(easy question) MongoDB documents are limited to 16 MB. Facebook's RocksDB Overview says "There is no limit to the size of a key or a value." Your insertOne documentation doesn't state a limit. Is it 16 MB?
(harder question) Your getMany documentation doesn't describe its interaction with the RocksDB "snapshot" concept (one of the big advantages of RocksDB over other NoSQL products). Facebook's Iterator documentation says "If ReadOptions.snapshot is given, the iterator will return data as of the snapshot. If it is nullptr, the iterator will read from an implicit snapshot as of the time the iterator is created. ... be aware that in case an iterator getting stale, it can block resource from being released. So make sure you destroy or refresh them if they are not used after some time, e.g. one second." Does this imply that each call to getMany operates on a unique snapshot? If so, do you plan to add an API in which the user can specify that multiple getMany calls must operate on the same snapshot?
2. The name of a space (e.g., "dev") is part of the URL used by clients. Is this avoidable? It can interfere with migration of applications to codehooks from other platforms.
3. Your story about unanticipated use (or abuse) seems to be 'We've got you covered by creating a price "ceiling", which reduces the price with 90%.' That's good but I would probably also need billing alerts. I would probably also want request rate limits similar to AWS WAF (e.g., 100 requests per IP address in a 5-minute period) without writing my own auth hooks.
4. I didn't find a discussion of runtime secrets (e.g., something like "flyctl secrets").
The so-called "safeguards" preventing this, on balance, probably do more harm than good. The best argument in favor of these safeguards is perhaps the temporary one: today, there is simply too much deployed critical software that was developed in a more carefree age. Therefore, one might favor a tradeoff: try to introduce artificial friction against exploit development targeting old software (during the process of patching all of it), with the side effect that new software ends up less resilient than it could have been.
But in the steady state (which may be a very small number of years from now), every practical capability for exploit development should be a routine part of the software creation and maintenance lifecycle.