SQL injection, Kernel 4.7, Wire, Dependency Injection, Inversion of Control, Double Ratchet Algorithm

Post date: Jul 31, 2016 4:44:30 PM

• Some developers are so afraid of SQL injection, that they do interesting solutions. I tried to search for 'selection' but the search always turns out only for 'ion'. Also if looking dor deletion or insertion search also turns out only for 'ion'. So they're stripping the SQL commands from user input which they're so afraid of. Interesting way to deal with the issue. But doing that basically introduced usability issues which can be counted as bug. High five for your security team. This also reminds me from services which strip all ' from strings, just to be sure. They're not stripping drop or or create table commands, interesting logic there. Probably the user account doesn't have rights to drop or create tables, because those aren't being filtered.
• Briar - Is just something what I've envisioned and blogged about. Secure mesh networking for short range and / long range over the secure network (Tor) communications.
• Linux kernel 4.7 released - Release notes - Foo over UDP IPv6 made me laugh. It's one quite simple way to deal with things. Anything over anything can be always done, if there's any way to transmit data. - ARM64 NUMA support is nice. - Wow, there was just so much awesome stuff, that those are just two things that popped up and got my attention while checking the release notes. But most importantly Briar also hides meta data and communication patterns. At least to some degree, low latency always reveals some comm timing patterns, when collected statistically over time. That's also where Tor traffic confirmation & correlation attacks are, if there's global advisory which can monitor all traffic patterns, not data.
• After some testing, decided that wire.com is way too buggy. There are horrible fails which totally ruin user experience and user has to work hard to get around those fails. Yet the issues didn't seem too big, so I wonder why they haven't bothered to fix those. Most of issues were really basic fails, which just gives you impression of ad hock experimental code, which hasn't been actually designed to be used by normal users, but alpha testers who are able to figure out how to do things so that those work, instead of just expecting it to guide you so that everything works. - It's like they haven't used 5 minutes to test it. So fundamental, clear and obvious many of those flaws are. - Of course it's one way to work. We know it's broken, and we don't care. If you choose to use it, just do. If you whine, don't use it. There are plenty of other chat apps out there.
• Read bit more about Dependency Injection. It's so obvious that actually the first Java program I wrote for production used it. That's back in 1997. I just didn't use any hype stuff for it but standard Java. The program was written from the very beginning to support 'customer specific plugins' which would extend a few base classes. Which naturally leads to Inversion of Control in this case. Also the service which contained customer specific code module was then injected in the main program client which to do the customer specific tasks.
• Reminded my self about Double Ratchet Algorithm aka known as Axolotl. Most important stuff quoted from Wikipedia: "The protocol provides confidentiality, integrity, authentication, participant consistency, destination validation, forward secrecy, backward secrecy (aka future secrecy), causality preservation, message unlinkability, message repudiation, participation repudiation, and asynchronicity. It does not provide anonymity preservation, and requires servers for the relaying of messages and storing of public key material." - The constant DH operations are also the reason why it's so slow. Telegram does that kind of key renewal only weekly or between every 100 chat messages. Yet Telegram doesn't support secret chat session initialization unless the other party is also online to provide required keys.
• Finished my summer reading Data and Goliath by Bruce Schneier. Nothing new. But a good summary. Everyone is being watched, monitored, recorded and logged. As well as even if data is 'deleted' there's no guarantee of it ever going away.