AppSec Blog

AppSec Blog

Developer Security Awareness: Why Do We Care?

Laying a foundation for developer security training is not an easy task. Those of us that have worked in the information security world long enough have seen the roadblocks:

  • Development teams do not have enough time

  • The project does not provide enough funding

  • The organization does not have the expertise to create a training program

  • It's more important to release new features.

Anyone reading this post has likely heard reasons similar to this for not taking action. In this multi-part blog post, we will show you how to get started and what developer security awareness training could look like inside your organization.

What have we learned from the past?

The headlines from the past year alone should be more than enough ammo to convince anyone in your organization that you NEED an application security program.

  • The Heartbleed OpenSSL bug affected web

Demystifying Cross-Site Request Forgery

Continuously ranked in the OWASP Top Ten, a large majority of the development community still doesn't understand Cross-Site Request Forgery (CSRF). After years of penetration tests and code reviews, my experiences show that a high percentage of applications, especially new applications, do not have proper CSRF protections in place. This post provides a refresher on CSRF and provides a common defense for this issue.

The Exploit

CSRF occurs when an application trusts that all requests originating from the user's browser are user-directed actions. Imagine that you are logged into your bank's online portal. The application requires users to authenticate and passes a session cookie back to the browser. Subsequent requests made to the banking site must contain the session cookie, allowing the site to identify the user and perform the requested action.

What if an attacker could send a fake request using the victim's browser?

Suppose an attacker wants to


How to Prevent XSS Without Changing Code

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.

One of the most common XSS attacks is the theft of cookies (especially session ids). The HttpOnly flag was created to mitigate this threat by ensuring that Cookie values cannot be accessed by client side scripts like JavaScript. This is accomplished by simply appending "; HttpOnly" to a cookie value. All modern browsers support this flag and will enforce that the cookie cannot be accessed by


WhatWorks in Application Security Poster

We are excited to announce the new WhatWorks in Application Security Poster!

The front side of the poster focuses on why application security is important to any organization and the critical steps needed to make an application security program successful, including:

  • Design: Review security requirements, security architecture, secure coding standards, and the tools your team can use to create secure software design from the beginning
  • Test: Methods for testing your applications including dynamic analysis and static analysis tools, plus checklists for evaluating commercial tools and third-party penetration testing firms
  • Fix: Covers code remediation and identifies some products that can be used for virtual patching
  • Govern: Secure SDLC processes, metrics and reporting, and evaluating application security training

On the reverse side, the Securing Web Application Technologies (SWAT) checklist provides an


Password Storage Mistakes

Steve Kosten is an instructor with the SANS Institute for DEV541: Secure Coding in Java/JEE.

Password Storage Mistakes

I was visiting a web site recently that I haven't visited in many, many years. I tried a few old passwords I used to use before I started using a password storage system, but no luck. I was defeated. Barred from entry into this site. But wait, they have a "Forgot Password" link; knowing I will soon have entry into the site, I confidently click on that link (after entering what I believe my username is). Boom, a few seconds later, I have an email from this web site that I will not name. Opening the email, there it was. The password I had created from ages ago. Head-slap.

The head slap wasn't for me forgetting my password; what were the developers of this site doing storing MY PASSWORD in clear text??!! Where anyone with