API Security SANS, Networking, ESB, e-receipts, Eddystone, Python JSON vs Pickle

Post date: Dec 25, 2015 7:15:00 AM

Once again wondered gaping security holes. Like the infamous goatse security said. It's just incredibly common that security is the thing that is completely forgotten when doing things. Lack of authentication, encryption and checking if operation is authorized at right points. Many times people see it as burden to verify things. Like when using client server, why server would verify if something is authorized, the client already got rules limiting access. Yeah right. 99,5% of programmers seem to completely forget and do not understand that there are also other people who are able to modify the client than the developers alone. This common scheme has been repeated over and over gain in different kind of client server scenarios as well as with multiple APIs. There has been major systems having these problems and smaller systems and implementations are absolutely full of these flaws. I think I've written about these things several times, but it's just so common that it's unlikely to change in future. It's time to check the SANS top list and laugh hard. Programmers are just so clueless about these commonly known 'features'. Yet as I've said in earlier posts, it's nice to have 'powerful system', where any client application can send any SQL commands to server as 'sa'. It's very very neat, you can do anything on the client side without modifying or maintaining any burden on server side. Yet nobody thought about the possibility of intercepting, reverse engineering and modifying or generating new commands to the server. I've done some play with stuff like that earlier several times, and it's always so fun. Especially when writing your own client, you can bypass all the measures usually limited by the access restrictions incorrectly implemented in the client.
Daily networking joy. Customers network is down, because unnamed people have blocked SMB / NetBIOS name resolution on firewall and all the installed systems refer to other computers on local network using local SMB / NetBIOS name resolution. They use several hours trying troubleshoot that even if it's absolutely clear that name resolution isn't working and ping and other services fail, because name can't be resolved. Naturally they do not try to ping or use network with IPs only, because well, we've always used names. Therefore completely missing the the name resolution issue and so on.
Finnish National Service Bus (Channel) is now open. It's utilizes X-road type of ESB for secure inter system communication and authentication. The security gateway uses Ubuntu for securing communications and checking access authorization. - Oops, this was already in previous post. Well, I'm tracking the project closely, so it doesn't matter if I mention it twice.
Discussed with a few people currently processing paper e-receipt how annoying that is, especially when all receipts are more or less different. Shouldn't there also be formal standard for paper receipts? The e-receipts project in Finland is progressing. There's supposed to be one more workshop where things should get hopefully finalized. All I can say at this point that it's and extension to existing Finvoice electronic invoicing standard.
Found relatively reasonably priced store for Eddystone Physical Web Beacons and ordered a few. AltBeacon, iBeacon, Flybell are related. Technically a small Bluetooth Low Energy BLE beacon / transmitter. Gotta experiment with software and use cases. Should be pretty simple and straight forward. - This is out of sync, I've already received those and written a review, but yeah. Mentioning twice or more doesn't really matter.
Interesting observations with json vs pickle in Python. We had a long discussion with friends about this and there was no simple answer. Yep, when we decided to test those out, we also noted that it's really hard to give a clear answer because there isn't one. When encoding list of integers, JSON produces 100% larger file than pickle. As well as pickle is much faster when loading than JSON. That's clear. Pickle is better, right? Not so fast. Let's do exactly the same test, but encode those integers as string. Shouldn't make a big difference right? Yet now JSON encode and load is more than 50% faster than pickle. Also the pickle output is almost twice as larger than JSON. What does this mean? Well, only solution is a great fight, because there's no clear winner.