Saturday, 30 April 2016

Click It or Ticket — For The Web

buckle_upBy now, everyone is probably familiar with the “Click it or ticket” campaign, by the National Highway Traffic Safety Administration, with slogans like “Buckle up. It’s the law.”

We need something like that for the web…

It’s crazy how often I run across rather large sites not using HTTPS to protect sensitive data. Most recently, I was on the website of a rather popular vision care company, who is famous for the… crafting of lenses… if you know what I mean… The credentials were served by a page over HTTP and then passed to HTTPS for the actual account management portion. Not good…

Even though the actual account interactions are all happening within their HTTP-based web app, the initial login/registration was on an HTTP page. A simple man-in-the-middle attack would let you inject whatever extra content you want into that main page. At that point, harvesting the login credentials for yourself is quite simple. Though the site is fairly basic and (annoyingly, to me as a customer) doesn’t even offer basic features like checking the status of pending orders, there is still enough there for it to — at the very least — fall under the umbrella of HIPAA.

Thankfully, I won’t need to include screenshots demonstrating how this can be abused… The company in question (and its also-popular sister company) has now moved the website to full HTTPS. That’s good. But there are still countless sites out there that — for whatever reason — still don’t seem to see the need in making the switch to HTTPS. I don’t get it.

At this point, there’s almost no reason not to switch. Thanks to efforts like Let’s Encrypt, it’s now super-easy and free to get a certificate for your site. It’s a no-brainer, really. I just wish there was a better way of getting sites on board without having to resort to HTTP-shaming…

Thursday, 31 March 2016

Sheet’s Getting Real

excelFor the past few years, all of my finances have been managed through spreadsheets. Before I spend even one cent of my paycheck, I have every last bit alloted into various categories. As I spend, I update the budget. I know it sounds like a lot of work, but it pretty much manages itself, really.

As some of you might know already, I like to automate, well, just about everything. Anything that can be offloaded to a scheduled job or whatever will free up extra resources for me to devote to other — more enjoyable — tasks.

My latest goal is to do some integration with Google Sheets, a bit of coding, and a cheap wifi-enabled digital picture frame.

The idea is to display an image of the spreadsheet, for quick and easy reference, in the picture frame. And then I would also include a “Last Modified” date and maybe a color-coded visual indicator to show when I am overdue on updating my budget.

If I am able to get that working, I would then get super-ambitious and try to also integrate with my bank, since I utilize my current balance in my budgets to always ensure I haven’t missed any transactions.

I know this project has limited appeal to most folks, but… Who cares? It should be fun.

Monday, 14 March 2016

Barcodes Are Input, Too…

barcodeLately I’ve been collecting barcodes. Not the ones off of cereal boxes, soda bottles, or that sort of thing… I’m not a weirdo! ;) But I have been collecting the store-generated barcodes from grocery stores, gas stations, etc. It’s interesting to see how what does or doesn’t get encoded and trying to think of ways to abuse it.

At one location — a grocery store — I noticed their barcodes encode a somewhat generic department/category identifier, followed by a price, and then a Luhn check-digit. Very simple. So, of course, I began wondering how easy it would be to take advantage of this. Barcode swapping is obviously nothing new. I just think it’s kind of neat that with just a tiny change to a few lines of the barcode, something can go from $8.79 to $3.79…

Since I obviously don’t want to go to jail for defrauding a store, though, I probably wouldn’t ever try such a thing. Or, if I did, it would be more along the lines of changing the price from $3.79 to $3.80, just to serve as a proof of concept. Does it still count as fraud if I pay them more…? ( #NotALawyer )

Think of how much trust is put into, say, membership IDs, identity bracelets at hospitals, etc. If it scans, it must be legitimate, right? And are they just checking for a valid-looking barcode and logging it somewhere or is it actually doing look-ups in a database?

There real fun, though is with sending unexpected input. After all, barcodes are typically just a quick and fast replacement for hand-keying values on a keyboard… So what happens if my coupon, membership card, etc. gets scanned and instead of a numeric-only barcode, I’ve encoded the message “KevinWasHere”? Or maybe encode some SQL-Injection commands in there? What if the encoded price is changed from 3.79 to -3.79…?

I would assume that most POS systems have safeguards in place to limit access to the system via traditional means. Maybe it’s all just a touch-screen and no physical keyboard. That might help stop a cashier from using the register to check Facebook, for example, but who needs a keyboard when you’ve got a barcode scanner…? What happens if the barcode scanner is tricked into sending the Escape key? Even if the barcode scanner is programmed in a way that would generally make abusing it difficult, it’s very common for the barcode scanners themselves to be programmed and reprogrammed purely by scanning certain barcoded commands in a certain order. If someone gets access to your company’s “price checker” kiosk, what damage could be done?

None of this stuff is worth jail time, of course. People should only consider messing around with this sort of thing if you have legitimate access to a system and want to ensure proper input validation is being enforced for barcode scans.

That being said, there’s nothing stopping you from using apps on your phone or whatever to scan barcodes given to you on receipts, confirmations, etc. and getting a better idea for what makes them tick. Does it have your account number, DOB, or other potentially sensitive information encoded? How else would you know unless you check?

Monday, 29 February 2016

Client Side Validation

Trust No OneIt cracks me up when I stumble upon an application that trusts anything coming from the user. Especially when that user is me :)

If given the opportunity, my browser will happily send your application whatever I tell it to. It’s up to you to actually make sure I’m not lying…

If I’m making calls to a webservice that only admins would be calling from you app, make sure I’m an admin before performing the action… Or instead of relying on client-side javascript to calculate the order’s total, for example, maybe do that on the backend instead…

Remember devs…. Trust No One.

Sunday, 31 January 2016

The Way of the Developer

samurai

Recently, I’ve been reading Musashi: An Epic Novel of Samurai Era. I actually found it quite inspiring.

Though largely self-taught in his use of swordsmanship and fighting, the main character strives to constantly hone his craft and to follow what he sees as the Way of the Warrior. He learns by watching other warriors, nature, and by following teachings of Sun Tzu and later from Buddhism.

Maybe it’s because I’m also largely self-taught and learn mostly through interacting with other developers and from the code I work with every day, but this story resonated with me. As a developer, I feel like it’s important to cultivate one’s own Way of the Developer.