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.
For the second year in a row Jim Bird and I have helped SANS put together a "Survey on Application Security Programs and Practices". We asked some of the same questions as the previous year, just in a different way. Some interesting trends this year, as taken from the executive summary of the soon to be published paper, include the following:
- There was a significant improvement in the number of organizations implementing application security programs and practices. The percentage of organizations that have an active Appsec program increased from 66% last year to 83% this yearand many of the organizations that do not have a program in place yet are at least following some kind of ad hoc security practices.
- Organizations are testing more frequently. In this year's survey, more than one-third are doing continuous, ongoing security testing of their applications, whereas only 23% indicated doing so in our ...
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
Stephen J, who is a member of our software security mailing list, asked a while back, "Do you have any recommendations on static source code scanners?" James Jardine and I started talking and came up with the following tips.
There are so many commercial static analysis tools from vendors like Armorize, Checkmarx, Coverity, Fortify (HP), Klocwork, IBM, and Veracode that it's hard to recommend a specific product. Instead we'd like to focus on seven tips that can help you maximize your selection.
1) Test before you buy
This probably sounds obvious but, assuming you haven't purchased anything yet, definitely do a bake off and have the vendor run the code against your actual apps. Do *not* simply run the tool on a vendor supplied sample app as the quality of the results, surprisingly, can vary quite a bit across different tools and code bases. Just keep in mind that some vendors will try to avoid this so they can ...
Backgrounding and Snapshots
In iOS when an application moves to the background the system takes a screen shot of the application's main window. This screen shot is used to animate transitions when the app is reopened. For example, pressing the home button while using the logon screen of the Chase App results in the following screen shot being saved to the application's Library/Caches/Snapshots/com.chase directory.
Figure 1: Snapshot showing cached information
To further illustrate this point take the following profile page from a fictitious bank app which displays sensitive information like the user's account number, balance, and secret question/answer.