HttpOnly Cookie is nothing new, it was first introduced by Microsoft back in 2002 when it released IE 6 SP1. Of course I don't think HttpOnly alone can solve all XSS problems but I believe it is a useful feature if used correctly. And while I don't think we can set every cookie with HttpOnly flag, at least we should set it on all session cookies whenever possible. However, statistics [1] show that only about 9% of websites use HttpOnly cookies. I don't know exactly why the usage rate is so low, but I think it may be related to the following misunderstandings:

1) HttpOnly is only for IE

No.

According to Google's Browser Security Handbook ^[2] and OWASP ^[3], almost 99% of all browsers (the only exception is Android) support HttpOnly cookies.

2) On .NET platform, it's disabled by default

Yes and No.

For custom application cookies, you have to manually enable it, but for session cookies, it is enabled by default.

Starting from .NET 2.0 (which was released in 2005, three years after HttpOnly was introduced), all session cookies come with the HttpOnly flag, and you can't even disable it. When decompiling that part of .NET program code, you will see:

System.Web.SessionState.SessionIDManager
private static HttpCookie CreateSessionCookie(string id)
{
    HttpCookie cookie = new HttpCookie(Config.CookieName, id);
    cookie.Path = "/";
    cookie.HttpOnly = true; // <-- burned in, not configurable
    return cookie;
}

The <httpCookies httpOnlyCookies="true" …> in web.config is only for custom application cookies, not for session cookies.

3) Most Java Application Servers don't support HttpOnly cookies

No.

But it is true that Java's support for the HttpOnly flag is very slow. There was no setHttpOnly() method in javax.servlet.http.Cookie until Java EE 6 (Servlet API 3.0) which was just released in December 2009. However, this doesn't mean application servers can't support HttpOnly without Java EE 6.

Summary

As you can see, many application servers already support HttpOnly cookies, some even set the HttpOnly flag on session cookies by default. The risk of setting HttpOnly flag on session cookies should be pretty low, and the steps for enabling it are not difficult. Therefore, if your web application is running on a “supported but default false” application server, such as Tomcat 6.0, you should enable it.

Path manipulation is where a hacker injects a fake path into an application to trick it into reading something different than it would normally. Take for example this simple application:

import csv
import sys

filename = sys.argv[1]
user = sys.argv[2]
password = sys.argv[3]

csvfile = '%(file)s.csv' % { 'file': filename }
print 'Checking %(file)s' % { 'file': csvfile }

userReader = csv.reader( open(csvfile, 'rb'), delimiter=',' )
found = 0
for row in userReader:
	if user == row[0] and password == row[1]:
		found = 1
		print 'Logged in'
if found == 0:
		print 'Not logged in'

This is a simple application that reads user accounts and does a login check. The first parameter is supposed to be 'users' or 'administrators'. The second and third parameters are the user name and password. Because the coder (me) is lazy I'm just going to use that first parameter to point to a particular password file. And because I believe that the file system permissions for the directory prevent tampering all is well.

Not so fast. Sure the happy path works just fine:

$ python bad.py users user1 password
Checking users.csv
Logged in

But so does the hacker path:

$ python bad.py ../mydata/users hacker password
Checking ../mydata/users.csv
Logged in

Because of the way I construct the path a hack can easily point the application at a completely different users file in another directory which they control and, viola, they have access. Whoops.

There are some simple fixes for this. One would be to selectively sanitize the input.

password = sys.argv[3]

filename = filename.replace( '.', '' )
filename = filename.replace( '/', '' )

csvfile = '%(file)s.csv' % { 'file': filename }
print 'Checking %(file)s' % { 'file': csvfile }

In this case I'm using a string replace to remove any dots or slashes. That will kill any directory referencing on most operating systems.

The problem with this approach is that there is still too much to check to be guaranteed that there will never be an issue. So another, better, option is to just check the value against known goods:

password = sys.argv[3]

if filename != 'users' and filename != 'administrators':
	print 'Bad user type'
	exit( 0 )

csvfile = '%(file)s.csv' % { 'file': filename }
print 'Checking %(file)s' % { 'file': csvfile }

This way we can give the user some informative response if their input is invalid, and we can check all of the possible input variations without worrying about patterns we hadn't yet come up with.

Scott Charney of Microsoft advocates a public health model for malware and botnets. I found Charney's paper worth the time to read. He offers some fine definitions of individual defence, collective defense, active defense, and offense as means to combat cyber crime, and compares these to their physical conuterparts.

That said, I'm not getting in line for a laptop health certificate. I do not find the public health model valid. It's an old saw in cyber threat modeling. I object to it as a false analogy. Measures like vaccination and quarantine are weighed carefully against civil liberties because in public health concerns, we deal with people and populations. Computers, ISPs, and the like do not have such advocates. My ISP can choke off my traffic, and no one would blink.

Furthermore Charney acknowledges that his proposal sacrifices privacy at the intent of security. Using his health model, he further blunders in his discussion on anti-smoking regulations as a comparative privacy loss for the public good. We must acknowledge that smoking in public is a willful act, unlike my computer's infection. Downloading software doesn't compare to lighting up.

It's time that security researchers shelve our copies of Outbreak and The Hot Zone. We need a model for the spread of software threats that applies to software threats.

As an intern at Fortify this past summer, I researched analysis techniques for Objective-C and potential security vulnerabilities in iOS (iPhone, iPod Touch, iPad) applications. In this blog post I discuss recent attacks against the iOS platform and note some parallels to older attacks. In my next post, I'll discuss what a attack at the application layer of iOS might look like.

First, I'd like to discuss some articles I've been seeing in the news recently regarding mobile security. There have been a number of articles about "new mobile threats" and "mobile malware," but the attacks described are simply applications that have additional malicious functionality beyond the purpose they claim to the user. This is the exact same type of attack as 10 years ago when downloading a dancing smiley cursor would also give you pop-up ads. When you download a program, whether it be to your desktop or to your phone, there's a possibility that it may have malicious functionality. This type of problem is as old as computers.

Most public attacks aimed at iOS focus on attacking the platform itself or on stealing private data, with the former representing a vast majority. For a glimpse into attacks on the iOS platform, you can get an idea by reviewing the bugs fixed in iOS 4.0. Many of the bugs are from libraries used by iOS, with a large number being in Safari and Webkit. As for privacy, the main public attacks have been from malicious apps that actively steal personal data or legitimate apps that accidentally leave sensitive information in places where unintended agents may access it.

What interests me about these attack trends on iOS so far is that almost no (public) attack has been at the application layer - they've all been attacking the underlying OS or attacking the storage of sensitive data. It's like everyone has been attacking Apache or other programs running on a web server, but no one's been trying to hack the website itself. I think we can expect to see more attacks aimed at iOS applications themselves.

For the first time, Fortify's Security Research Group investigated platforms and applications in the mobile space. In an upcoming post, SRG summer intern turned Ph.D. candidate Clint Gibler will detail his foray into iOS. Here we consider general security issues with mobile. We will go on to discuss how these vulnerabilities manifest in Google's Android operating system and applications.

The foremost security flaw with mobile is that you will lose your hardware. You may lose it to theft, you may hand your phone to a nefarious airport personnel for a few minutes as you walk through the metal detector. Moving away from the sinister side of the spectrum, you may inadvertently leave your phone in a bar. You may innocently recycle your phone when you upgrade to the newer model. Regardless of scenario, losing control of your multi-hundred dollar hardware hands over access to gigabytes of your valuable data: your contacts, your stored passwords, sensitive documents riding along as e-mail attachments.

We acknowledge this problem is endemic to mobile. Any data storage platform is a target for theft: a desktop machine, a laptop, thumb drive, or smartphone; even a manila folder. The risk of loss grows as the device size shrinks. Also, the target's value increases in proportion to its capacity. Thirdly, as a device performs more functions, there exist more types of information on it. A mobile phone contains a list of phone numbers, but a web-enabled mobile computing platform can contain this and bank account information and sensitive documents. Hence we believe that a mobile device like an Android-enabled phone lives in an attacker's sweet spot.

No software solution will prevent losing your phone. Fortify's Security Research Group addressed the resultant data loss by ensuring that sensitive data is not written to an unprotected location in Android. As your phone gains more of the functionality of you computer, you must protect it as such. For example, Android provides full support for SQLite databases that an application may use for structured storage. Mostly full, that is; SQLite mostly mitigates your fears of SQL injection, mostly. Analogous to your desktop, your mobile platform opens itself to attack through its software. These security issues - data loss and malware - exist for the Android platform.

On Sunday September 5, the New York Times printed an article about password strength. I have mixed feelings about this article. On the one hand, publication in a widely-circulated periodical brings application security issues to general audience. However the analysis in the NYT piece lacks the depth of a security publication. Security professionals are obliged to provide that depth. Consider the theses of the Times' piece, their destructive implications, and how we can guide the conversation to the benefit of users.

By referring to Amazon, PayPal, and Fidelity's websites, the Times insinuates that since a simple password policy is good enough for these guys, it ought to be for everyone. But this obscures the fact that these corporations' simple password policies are just one element of multi-faceted information security infrastructure. If your information security policy is no more than your password policy, your system is in danger. Effective security policy is multi-layered; no single factor will adequately harden the target.

Most of us do not set security policy in the organization; we merely abide. In 2009, Slate Magazine offered salient password creation guidance. Create your password out of a memorable pass-phrase. You might know that I'm a rabid Abba fan, but that won't help you or your password-cracking software deduce Dqy&so17
Dancing queen, young and sweet only seventeen...

2. Complicated password policies do not provide security. A second thesis of the NYT piece avers that password policies provide a false sense of security. False because a password will not protect against some more onerous threats. To evaluate this claim, one must consider the threat highlighted by the Times: a key-logger. Key-logging software on your machine will take your password, your bank account number, your mother's maiden name, and your best friend's e-mail address. Perhaps anti-virus software can detect this malicious program, though I've not found a security expert willing to risk her social security number on an anti-virus suite.

I acknowledge that this is a damning, damaging attack; as such it makes for good copy. A strong password would not stop a key-logger, nor would a dictionary password. Then again, multi-factor authentication, identity-based cryptography, and military-grade command and control would be ineffective. A key-logger is an infallible scribe recording each tap and click. Mentioning this omniscient, omnipresent demon obscures the discussion of passwords entirely. Security policy should prevent a key-logger from landing. A most conservative approach would restrict software downloads. But this circles back to Don Norman's criticism that security policy hampers usability to the point that users ignore the policy.

The Security Research Group released its Q3 update to the Fortify Secure Coding Rulepacks and the Fortify RTA Rulepack Kits last week and I wanted to take a chance to update you on the latest and greatest from SRG.

As of this release, the Fortify Secure Coding Rulepacks detect 459 unique categories of vulnerabilities across 18 programming languages and over 680,000 individual APIs. Please see the attached PDF document for the full release details, but in summary, our latest updates include the following exciting features:

Fortify RTA Rulepack Kits for Java and .NET
Tuning Capabilities – This update includes enhanced rules for SQL Injection and Cross-Site Scripting that allow users to easily and accurately tune the rules to produce the highest fidelity results.

Premium Content
Cloud Security Process Template – As a complement to the project template released last quarter, this update includes a process template that highlights ways to reduce risk during the SDLC when migrating a program from an internal data center to a cloud provider. Compliance and Standards Report – Expanding on the reporting capabilities of Fortify 360 Server, this release includes an updated compliance report for DISA STIG Version 3 Release 1.

ITWorld has just published a short Q&A with Richard Clarke focusing on Cyberwarfare and how companies can prepare.

The guys at Python Security are doing an awesome job not only categorizing types of security attacks, but also specific vulnerabilities in Python packages. If you are involved in security and work in Python I hope you will help out their site and contribute your expertise on the Wiki.