Quite simply, the goal of this book is to make your web applications more difficult to hack. Web applications—or any software, for that matter—will never be completely secure and free from defects. It is only a matter of time before a determined attacker will find some vulnerability or misconfiguration to exploit and compromise either your site or one of its users. You should take a moment to come to terms with this truth before progressing. Many people wrongly assume that hiring “smart” developers or deploying commercial security products will magically make their sites “hacker proof.” Sadly, this is not reality. A more realistic goal for web application security is to gain visibility into your web transactions and to make your web applications more hacker resistant. If you can force any would-be attackers to spend a significant amount of time probing your site, looking for vulnerabilities, you will widen the window of opportunity for operational security personnel to initiate proper response methods.
This book arms you with information that will help you increase your web applications’ resistance to attacks. You will be able to perform the following critical web defensive techniques:
- Implement full HTTP auditing for incident response.
- Utilize a process to mitigate identified vulnerabilities.
- Deploy web tripwires (honeytraps) to identify malicious users.
- Detect when uses are acting abnormally.
- Analyze uploaded files and web content for malware.
- Recognize when web applications leak sensitive user or technical data.
- Respond to attacks with varying levels of force.
Here is the Foreword from the book which was written by my friend Jeremiah Grossman:
A defender, the person responsible for protecting IT systems from being compro- mised, could just as easily be the first line of defense as the last line. In fact, a defender working for an average organization might be the only line of defense—the only thing standing between the bad guy and a headline-making data breach. Worse yet, perhaps the incident doesn’t make headlines, and no one, including the defender, is the wiser.
Either way, when whatever crazy new Web 2.0 Ajax-laced HTML5-laden application has traversed the software development life cycle and successfully made it past the QA gate, when the third-party penetration testers are long gone, after management has signed off on all the security exceptions, and the application has been released to production, with or without the defender’s knowledge or consent, “security” then becomes entirely the defender’s responsibility. Rest assured that vulnerabilities will remain or will be introduced eventually. So, when all is said and done, a defender’s mission is to secure the insecure, to identify incoming attacks and thwart them, and to detect and contain breaches.
That’s why there should be no doubt about the importance of the role of a defender. Defenders often safeguard the personal data of millions of people. They may protect mil- lions, perhaps billions, of dollars in online transactions and the core intellectual property of the entire business. You can bet that with so much on the line, with so much valuable information being stored, someone will want to steal it. And the bigger and more high profile the system, the more sustained and targeted the incoming attacks will be.
Making matters even more challenging, the bad guys have the luxury of picking their shots. They may attack a system whenever they want to, or not. A Defender’s job is 24/7/365, holidays, weekends, vacation days. The system must be ready, and the defender must be ready, at all times.
A defender’s job description could read much like Ernest Shackleton’s famous advertisement when he was looking for men to accompany him on his next Antarctic expedition:
Men wanted for hazardous journey. Low wages, bitter cold, long hours of complete darkness. Safe return doubtful. Honour and recognition in event of success.
A defender’s success really comes down to understanding a few key points about the operational environment in which he or she works:
- Web sites are often deployed in such a way that they cannot be adequately mirrored in development, QA, or even staging. This means that the real and true security posture, the real and true risk to the business, can be fully grasped only when it hits production and becomes an actual risk. As such, defenders must be able to think on their feet, be nimble, and react quickly.
- Defenders will find themselves responsible for protecting web sites they did not create and have little or no insight into or control over. Management may not respect security and may be unwilling to fix identified vulnerabilities in a timely fashion, and that could be the long-term standard operating procedure. And maybe this is the right call, depending on business risk and the estimated cost of software security. Whatever the case may be, defenders must be able to identify incoming attacks, block as many exploits as they can, and contain breaches.
- Fighting fires and responding to daily threats must be an expected part of the role. Whether the business is fully committed to software security is immaterial, because software will always have vulnerabilities. Furthermore, everyone gets attacked eventually. A defender never wants to be late in seeing an attack and the last one to know about a breach. For a defender, attack identification and response time are crucial.
Putting these practices to use requires specialized skills and experience. Normally, aspiring defenders don’t get this type of how-to instruction from product README files or FAQs. Historically, the knowledge came from conversations with peers, blog posts, and mailing list conversations. Information scattered around the Internet is hard to cobble together into anything actionable. By the time you do, you might already have been hacked. Maybe that’s why you picked up this book. Clearly web-based attackers are becoming more active and brazen every day, with no signs of slowing.
- Defenders, because they are on the front lines, learn a tremendous amount about the application’s risk profile and the necessary security readiness required to thwart attackers. This intelligence is like gold when communicated to developers who are interested in creating ever more resilient systems. This intelligence is also like gold when informing the security assessment teams abount what types of vulnerabilities they should focus on first when testing systems in either QA or production. Everyone needs actionable data. The best defenders have it.
For a Defender to be successful, there is simply no substitute for experience. And this kind of experience comes only from hour after hour, day after day, and year after year of being on the battlefield, learning what strategies and tactics work in a given situation. This kind of experience certainly doesn’t come quickly or easily. At the same time, this kind of information and the lessons learned can be documented, codified, and shared. This is what Ryan Barnett offers in this book: recipes for defense—recipes for success.
To all defenders, I leave you in Ryan’s accomplished and capable hands. His reputation speaks for itself. Ryan is one of the original defenders. He has contributed more than anyone else in web security to define the role of the defender. And he’s one of the best field practitioners I’ve ever seen. Good luck out there!
Jeremiah Grossman
Chief Technology Officer WhiteHat Security, Inc.
