If you are looking to boost your career in application security, there is no better place to start than by reading a copy of Tanya Janca’s new book Alice and Bob Learn Application Security. Janca has been doing security education and consulting for years and is the founder of We Hack Purple, an online learning academy, community and weekly podcast that revolves around teaching everyone to create secure software. She lives in Victoria BC, one of my favorite places on the planet, and is one of my go-to resources to explain stuff that I don’t understand. She is a natural-born educator, with a deep well of resources that comes not just from being a practitioner, but someone who just oozes tips and tools to help you secure your stuff.
Take these two examples:
The book is both a crash course for newbies as well as a refresher for those that have been doing the job for a few years. I learned quite a few things and I have been writing about appsec for more than a decade. The audience is primarily for application developers, but it can be a useful organizing tool for IT managers that are looking to improve their infosec posture, especially these days when just about every business has been penetrated with malware, had various data leaks, and could become a target from the latest Internet-based threat. Everyone needs to review their application portfolio carefully for any potential vulnerabilities since many of us are working from home on insecure networks and laptops.
Her rough organizing framework for the book has to do with the classic system development lifecycle that has been used for decades. Even as the nature of software coding has changed to more agile and containerized sprints, this concept is still worth using, if security is thought of as early in the cycle as possible. My one quibble with the book is that this framework is fine but there are many developers who don’t want to deal with this — at their own peril, sadly. For the vast majority of folks, though, this is a great place to start.
Alice and Bob are that dynamic duo of infosec that are often foils for good and bad practices, are used as teaching examples that reek of events drawn from Janca’s previous employers and consulting gigs.
For example, you’ll learn the differences between pepper and salt: not the condiments but their security implications. “No person or application should ever be able to speak directly to your database,” she writes. The only exceptions are your apps or your database admins. What about applications that make use of variables placed in a URL string? Not a good idea, she says, because a user could see someone else’s account, or leave your app open to a potential injection attack. “Never hard code anything, ever” is another suggestion because by doing so you can’t trust the application’s output, and the values that are present in your code could compromise sensitive data and secrets.
“When data is sensitive, you need to find out how long your app is required to store it and create a plan for disposing of it at the end of its life.” Another great suggestion for testing the security of your design is to look for places where there is implied trust, and then remove that trust and see what breaks in your app.
Never write your own security code if you can make use of ones that are part of your app dev framework. And spend time on improving your “soft skills” as a developer: meaning learning how to communicate with your less-technical colleagues. “This is especially true, when you feel that the sky is falling and you aren’t getting any management buy-in for your ideas.”
One topic that she returns to frequently is what she calls technical debt. This is a sadly too-often situation, whereby programmers make quick and dirty development decisions. It reflects the implied costs of reworking the code in your program due to taking shortcuts, shortcuts that eventually will catch up with you and have major security implications. She talks about how to be on the lookout and how to avoid this style of thinking.
The original idea behind honeypot security was to place a server on some random Internet link and sit back and wait until some hacker happened by. The server’s sole purpose would be to record the break-in attempt — it would not be part of a normal applications infrastructure. Then a researcher would observe what happened to the server and what exploit was being used. A honeypot is essentially bait (passwords, vulnerabilities, fake sensitive data) that’s intentionally made very tempting and accessible. The goal is to deceive and attract a hacker who attempts to gain unauthorized access to your network.
