From the trenches—thoughts on security practices.
There is an old joke which tells about three monkeys put into a cage, a banana hanging on the roof, and a chair put into the middle of the cage, so that climbing into it gives access to the banana. Most likely, sooner than later, one of the monkeys tries to get the banana—in which case cold water is sprayed on the other two, essentially punishing others for what the one did.
Eventually they learn to not reach for the banana. When this happens, one of the monkeys is replaced with a new one, which most likely will go after the banana, again leading to spraying cold water on the other two. This continues until all of the monkeys are replaced and none of the originals resides in the cage, yet none of the monkeys will go and try to get the banana. In this case, they have reached the situ-ation of “nobody knows why we are working like this, but this is the way we always have done things.”
That comes to mind when thinking of how to approach learning to prevent security-related problems introduced to the applications during design or implementa-tion of it (programming). After all, there are so many books, thoughts, blogs, papers, tweets, and mailing lists full of relatively good guidance and opinions. Guidelines concentrating on the technical knowledge of “what” needs to be done are lacking in an explanation of “why.” This leads into a situation where it might be more difficult to adapt to the task at hand, since knowledge might be from a different task, and thus might prevent seeing the commonalities, or not benefiting from standing on the shoulders of giants. This is where “why” the “what” works comes into play—by know-ing what is, and what has been tried, one does have an easier job adaptknow-ing to the task not covered in the specific knowledge sharing of “what” earlier. The pure knowledge for a task can be thought to force a rule-based approach, that is, everything that comes in front of you must be covered. Another angle is information integration, where you
know the patterns from the examples, and can potentially create the rules for a task not seen before.
The above brings up a couple of important points—adaptability, and the under-standing of “why,” which is what J.D. brings up when talking about security anti-patterns, pointing out the mindset. This is also introduced via a change of thinking from “clean, safe, and done” to “reducing attack vectors,” “reduced threats,” “less vul-nerable,” and “higher degrees of protection”—the latter ones pointing out the goals, which then, when followed on the different points of handling data input can prevent even currently unknown attack attempts—the “whats”—from working.
Naturally when the application is done, or during the development rather, it is a very good habit to test it. Testing can be done from a functionality point of view, but also a security point of view—which can be thought to be negative testing; what the application is not supposed to do and failing safely. On this, it helps to think of the application as being only a front-end to the database and the information in it.
Testing can be done in multiple ways, simple browser-based—or otherwise going through code—manual attempts which can be time-consuming when full coverage is wanted, but which can give initial indicators, toward automated testing for find-ing known problems, attempts to exploit problems everyone else knows from that application, be it a library or otherwise known file. Important also is to try to test currently unknown vulnerabilities which can be attempted by testing the application, which is unknown code, to testing tools, with automation to figure out classes of vulnerabilities. These can be, but are not limited to SQL injection attempts, Cross-Site Scripting, etc., but also random inputs via fuzzing—which with best effort can find those known problems. But it can also be based on coverage of all unknown vulnerabilities combined into total vulnerability finding and—management. Manual attempts are based on the skills and persistence of the testers, while automation always tries to cover what it has been instructed to cover.
Testing can be thought to be application of a systems theory—where a human can also be a system, either by itself or combined with automation which is the ideal way.
Preferably over time this part shows a reduced amount of vulnerabilities based on both initial learning, such from this book, but also from the application which can be thought to be an iterative loop for learning entity. Similarly, automation in a form of tested, proven, updated libraries is a good approach to use instead of implementing always new, potentially more difficult to use methods. All of these together are good seat belts for the application when it is put “naked” on the net.
Incidents might happen, and even in those cases, it is good if the application is made so that the attacker needs to spend time, so that an attack is harder with mini-mal impact. When an attacker needs to spend time, this means the window of detec-tion and prevendetec-tion for defenders gets longer overall. A good mindset approach is an example from the British Navy during the First World War.
Admiral of the fleet, John Arbuthnot “Jacky” Fisher, was known for his efforts to reform the British Navy. The reform paid off during the First World War by
having a modern and powerful fleet in use. The Admiral made his most important contributions without firing a shot. His example shows that having nothing to do does not mean doing nothing. It is cheaper to secure the application and keep data safe than responding to an incident—even when thinking they are rare.
After reading this book, a good habit is to get back to it occasionally, not necessar-ily reading it fully, but as a reference material—sometimes when knowing more, one might be able to learn more from things in the past, such as books.
It is better to be prepared than surprised.
Jussi Jaakonaho Codenomicon Ltd. and Toolcrypt Group Former Chief Security Specialist, Nokia
x x iii
Preface
I grew up in the country and we never locked the doors to our house or our cars.
In school, no one broke into someone else’s car or locker. If you put something down, you could pretty much rely on it being there when you got back. Family entered without knocking, and non-family never tried. This is no longer the case.
Now, even though my house and car are locked, the virtual windows to my life, as well as a basement door I didn’t even know existed, are open and under attack thanks to the Internet. Family needs to knock several times before using the secret handshake thingy, and strangers enter anonymously and unannounced into my whatever.
Security is something I wish I could do without. The business of building cool things as fast as possible without regard to consequence of theft is far more interest-ing. Out of necessity, security has become a priority. What follows is some of what I’ve learned along the way. If any of these bits and bytes end up helping to protect your next application, then a battle has been won. I hope you enjoy the book.
Example Code Requirements
The examples in this book were written using PHP 5.4 and MySQL 5.5 on a Linux web server. Social APIs used are Twitter’s v1.1 API, Facebook PHP API v3.2, Facebook’s JavaScript API, and Facebook’s new RealTime Update API. Also used are jQuery v1.10.1 and jQuery Mobile v1.3.
A valid SSL certificate active on the web server is a requirement for many of these code samples to function properly.
Most code works on PHP 5.2 and PHP 5.3 if the encryption modules are compiled in. PHP 5.2 is end of life and use should be discontinued. PHP 5.4 is the current standard. PHP 5.5 has just been introduced, and is the way forward with better security.
Additional material is available from the CRC Press web site: http//www.crcpress.
com/product/isbn/9781482209037.
x x v
Acknowledgments
I’d like to thank the people who helped make this book possible. The first is Shreeraj Shah, who opened the door. The second is Rich O’Hanley, my editor, who believed in the project and took a chance on me. Also at CRC Press, is Amy Rodriguez and the editing staff, who caught many errors. Thank you. The third is Rex, “the Unlikely,”
who did the work of examining all the details for things I missed. The fourth is my good friend Jussi Jaakonaho, who always encourages, and always says really great things, and introduced me to Evernote.
I’d also like to thank Jeff Williams, the CEO of Aspect Security and OWASP contributor who also believed in the project, provided a critical viewpoint on several topics, and graciously allowed part of his reference work on OWASP to be reprinted in the book as a development guide. Tim Keanini and Jeremiah Grossman deserve thanks for their support of this project as well. Their many contributions to the world of web security have given them unique insights of which I am the beneficiary.
Especially deserving is my family who endured the time I spent working on this book. To my father, who gave me the love of writing, my mother, who bought me my first motorcycle, my wife, who loves me, my son, who thinks I’m the greatest, and my brother, the chef, thank you all very much.
Thanks to the Lord God, through whom all things are possible. I am a flawed human being, saved by the grace of God, through the sacrifice of His son, Jesus, who died on the cross for my sin and was resurrected because he was without sin. “For God so loved the world, that he gave his only begotten son, that whosoever believes in him shall not perish but have everlasting life” (John 3: 16).
x x v ii
Biography
J.D. Glaser is a software developer who loves building things. Circumstance led to a career in developing Windows security software and speaking all over the world on Windows forensic matters. He has trained government agencies in forensic issues and the U.S. Department of Justice has used his tools to capture and convict cyber criminals. He now specializes in building large social games in PHP and keeping players secure in cyber space.
Part I
3