As someone who spends half of their year teaching web application security, I tend to give a lot of presentations that include live demonstrations, mitigation techniques, and exploits. When preparing for a quality assurance presentation earlier this year, I decided to show the group a demonstration of Cross-Site Request Forgery (CSRF) and how to fix the vulnerability.
A CSRF Refresher
If you're not familiar with Cross-Site Request Forgery (CSRF), check out the article Steve Kosten wrote earlier this year about the attack, how it works, and how to defend your applications using synchronization tokens:
My favorite way to demonstrate the power of CSRF is by exploiting a vulnerable change ...
To address security defects developers typically resort to fixing design flaws and security bugs directly in their code. Finding and fixing security defects can be a slow, painstaking, and expensive process. While development teams work to incorporate security into their development processes, issues like Cross-Site Scripting (XSS) continue to plague many commonly used applications.
In this post we'll discuss two HTTP header related protections that can be used to mitigate the risk of XSS without having to make large code changes.
Help!!! Developers are going blind from Log Files!
This is a post by Sri Mallur, an instructor with the SANS Institute for SANS DEV541: Secure Coding in Java EE: Developing Defensible Applications.Sri is a security consultant at a major healthcare provider who has over 15 years of experience in software development and information security. He has designed and developed applications for large companies in the insurance, chemical, and healthcare industries. He has extensive consulting experience from working with one of the big 5. Sri currently focuses on security in SDLC by working with developers, performing security code reviews and consulting on projects. Sri holds a Masters in industrial engineering from Texas Tech University, Lubbock, TX and an
That's about how much developers care about security.
Starting last year I made a concerted effort to speak at developer conferences. The idea was to go directly to people who write actual code and help spread the word about application security. By speaking at technical conferences that appeal to top developers the goal was to reach out to people who really care about development and want to learn and apply everything they can. By getting these developers interested in security my hope was that they would, in some small way, lead by example since many of them are the ones that build the tools and frameworks that other developers rely upon.
It started last year at
There's lots of advice on designing and building secure software. All you need to do is: Think like an attacker. Minimize the Attack Surface. Apply the principles of Least Privilege and Defense in Depth and Economy of Mechanism. Canonicalize and validate all input. Encode and escape output within the correct context. Use encryption properly. Manage sessions in a secure way.
But how are development teams actually supposed to do all of this? How do they know what's important, and what's not? What frameworks and libraries should they use? Where are code samples that they can review and follow? How can they test the software to see if they did everything correctly?
There aren't as many resources to help developers answer these questions. Here are the best that I have found so far.
First, there are the OWASP Prevention Cheat Sheets, which provide clear, practical advice