Manicode

Financial Responsibility and OWASP

2011-06-12T16:58:00.003-10:00

OWASP Leaders,

I recently took a trip across Europe where I gave a vendor-neutral talk on Advanced XSS mitigation strategies in three countries. I also attended a conference as an OWASP representative and gave a talk there. Before this trip, several chapters agreed to compensate me for travel and I applied for OTM funds.

But I can't do it. I can't charge OWASP thousands for 3-10 hours of work. So OWASP Netherlands, France and Brussels - I'm going to donate my travel expenses back to you chapters and not bill OWASP. I'm only making this public because I'd really like to see more of this happen in the community. I'm taking this hit out of pocket and am happy to do so. It's the right thing to do.

I'd also like to make a few *recommendations* to the community for us all to consider. As we grow we constantly need to revisit financial ethics.

If you are running an event and need to pay for human help, please make this public and let folks from the community apply for such a position
Instead of hiring folks to help run events, consider seeking volunteers and compensate them with free conference admission!
Be careful if you hire a family member or friend in a paid position where you have not offered others in the community a chance to apply. DANGER!
If you are a providing services to OWASP - it's critical that no-bid contracts are avoided. Make sure you make such contracts and services public and give other folks a chance to bid or apply.
In general, if you are a leader of OWASP please try to avoid any kind of compensation from OWASP when possible. It's better for us to bring in third-party providers so leaders can remain objective.

These recommendations are not directed at any company or individual. I just want to make sure that every penny in OWASP is, as much as possible, spent in honoring our mission, which is the responsibility of all of us who love this 501c3 not-for-profit charitable organization.

Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks.

Respectfully,
Jim Manico

Taming the Beast

2011-02-13T09:34:00.012-10:00

The recent cross-platform numerical parsing DOS bug has been named the "Mark of the Beast". Some claim that this bug was first reported as early as 2001.

This is a significant bug in (at least) PHP and Java. Similar issues have effected Ruby in the past. This bug has left a number of servers, web frameworks and custom web applications vulnerable to easily exploitable Denial of Service.

Oracle has patched this vuln but there are several non-Oracle JVM's that have yet to release a patch. Tactical patching may be prudent for environment.

Here are three filters that may help you tame this beast of a bug.

1) Ryan Barnett deployed a series of mod security rules and documented several options here http://blog.spiderlabs.com/2011/02/java-floating-point-dos-attack-protection.html

2) Bryan Sullivan from Adobe came up with the following Java-based blacklist filter. This rule is actually quite accurate in *rejecting input* in the DOSable JVM numeric range. This fix, while simple, does indeed reject a series of normally good values.

public static boolean containsMagicDoSNumber(String s) {

return s.replace(".", "").contains("2225073858507201");

}

3) The following data sanitization code came from Brian Chess at HP/Fortify. This approach detects the evil range before trying to call parseDouble and returns the IEEE official value for any double in this most evil range ( 2.2250738585072014E-308 ).

private static BigDecimal bigBad;

private static BigDecimal smallBad;

static {

BigDecimal one = new BigDecimal(1);

BigDecimal two = new BigDecimal(2);

BigDecimal tiny = one.divide(two.pow(1022));

// 2^(-1022) 2^(-1076)

bigBad = tiny.subtract(one.divide(two.pow(1076)));

//2^(-1022) 2^(-1075)

smallBad = tiny.subtract(one.divide(two.pow(1075)));

}

public static Double parseSafeDouble(String input) throws InvalidParameterException {

if (input == null) throw new InvalidParameterException("input is null");

BigDecimal bd;
try {
bd = new BigDecimal(input);
} catch (NumberFormatException e) {
throw new InvalidParameterException("cant parse number");
}

if (bd.compareTo(smallBad) >= 0 && bd.compareTo(bigBad) <= 0) {
// if you get here you know you're looking at a bad value. The final
// value for any double in this range is supposed to be the following safe #
//return safe number
System.out.println("BAD NUMBER DETECTED - returning 2.2250738585072014E-308");
return new Double("2.2250738585072014E-308");
}

//safe number, return double value
return bd.doubleValue();
}

Touchpoints and BSIMM hurt AppSec

2011-01-09T08:14:00.002-10:00

Conjecture: BSIMM and Touchpoints are harmful to developers and organizations seeking cost effective application security based risk reduction.

Let’s start with the flaws of Touchpoints:

1. Touchpoints make security separate from development
2. Touchpoints are all verification, not build secure apps
3. Touchpoints are only SDLC (one app), not full boar appsec program planning across an entire application portfolio
4. Touchpoints makes security a cost, not an opportunity for improvement in other aspects of software dev
5. Touchpoints are negative vulnerability focused, not positive controls centric thinking
6. Touchpoints are basically hacking ourselves secure, not assurance evidence based
7. Touchpoints are trivial in the sense that they are just a concept with no backing... just a picture and a book. No meat!
8. Touchpoints are designed to sell tools - not totally, but somewhat
9. Touchpoints are not free and open (creative commons anyone?)

BSIMM continues with this tradition.

Does your organization really care if the software you are writing is secure, or is it a burden and a chore? No amount of process will fix not caring. BSIMM does almost nothing to create a culture of good security practices for developers. It’s again, 80% verification activities. It extends the tradition of the Touchpoints model which was 100% verification.

BSIMM and touchpoints do not go down and dirty to figure out how to actually make software secure.

And frankly, that’s what the entire world really needs right now.

Injection-safe templating languages

2010-06-30T16:44:00.004-10:00

The state of the art for Cross Site Scripting (XSS) software engineering defense is, of course, contextual output encoding. This involves manually escaping/encoding each piece of user data within the right context of a HTML document. The best programmer-centric OWASP resource around XSS defense can be found here: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

However, manually escaping user data can be a complex, error prone and time consuming process - especially if you are battling DOM based XSS vulns. We need a more efficient way. We need our frameworks to automatically defend against XSS so programmers can focus on innovation and functionality.

The future of XSS defense is HTML templating languages that are injection-safe by default.

Thanks to Mike Samuel from Google's AppSec team for pointing these projects out to me.

First we have GXP : http://code.google.com/p/gxp/ . It's an older Google offering that is much closer structurally to JSP and so possibly a better option for someone who has a bunch of broken JSPs and wants to migrate piecemeal to a better system.

There are also Java libraries like http://gxp.googlecode.com/svn/trunk/javadoc/com/google/gxp/html/HtmlClosure.html - this Library throws exceptions that are captured in the java type system which makes auditing them and logging and assertions around them fairly easy. They've done a really bad job documenting and advocating GXP but it's very well thought out, easy to use, and feature complete. https://docs.google.com/a/google.com/present/view?id=dcbpz3ck_8gphq8bdt is the best intro.

Another angle on the problem of generating safe HTML is http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html which talks about ways to redefine string interpolation in languages like perl and PHP.

Marcel Laverdet from Facebook is trying another tack for PHP with his XHP scheme : http://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919 . Rasmus has publicly been very skeptical of XHP, but I think a lot of his criticisms were a result of conflating XHP with other Facebook PHP schemes, such as precompilation to C and the like.

And course, there is the Google Auto-Escape project to keep a close eye on. It was first announced on March 31st of 2009. http://googleonlinesecurity.blogspot.com/2009/03/reducing-xss-by-way-of-automatic.html

Today, we need to manually output encode each piece of user driven data that we display. Perhaps tomorrow, our frameworks will do that work for us.

Shure SM-7B

2010-03-30T16:03:00.003-10:00

Thank you to OWASP for this new studio-quality microphone, a Shure SM-7B. It's an incredible piece of equipment that makes my life a lot easier - and takes up a lot less space in my very crowded computer area.

I have quite a few podcasts on deck - including a 5 show batch to be released in sync with the Top Ten release!

Thanks all.

Aloha,

Jim

How bad is it?

2010-01-21T13:07:00.014-10:00

Thank you to John Menerick and Ben Nagy for entertaining my questions on the Daily Dave list.

Q: Is the recent ie6 0-day anything special?

John: Not really. Not as special as the NT <-> Win 7 issue recently highlighted.

Q: How many similar 0-days are for sale on the black market?

John: Quite a few.

Ben: I'd love to see your basis for this assertion. I'm not saying that in the "I don't believe you" sense, only in the "everyone always says that but nobody ever puts up any facts" sense.

Q: What is the rate/difficulty for discovery of new windows-based 0-days for the common MS and Adobe products that are installed on almost every corporate client? (I heard Dave mention that discovery is getting more difficult)?

John: Not terribly difficult for someone who is dedicated. Then again, my idea of difficult is much different from the avg. person

Ben: I think that while finding 0-days might be 'not terribly difficult', selecting and properly weaponising useful 0-days from the masses of dreck your fuzzer spits out IS difficult - at least in my experience. There was some discussion of the 'too many bugs' problem on this list previously and I know several of the other fuzzing guys are currently researching the same area. Of course you'd explain this to your 'avg. person', as well as explaining that the skillset for finding bugs is not necessarily the same as the skillset for writing reliable exploits for them, and that 'dedication' may not sufficiently substitute for either.

Lurene Grenier: I really feel that the "selecting good crashes" problem is not that hard to overcome if you have a proper bucketing system, and the ability to do just a bit of auto-triage at crash time. For example, the fuzzer I use now both separates crashes by what it perceives to be the base issue at hand, and provides a brief notes file with some information about the crash and what is controlled. This requires just a bit of sense in providing fuzzed input, and very little smarts on the part of the debugger. I really think the next step is automating that brain-jutsu; much of it is hard to keep in your head, but not hard to do in code.

Using this output, it's pretty easy to spend a lazy morning with your coffee grepping the notes files for the sorts of things you usually find to be reliably exploitable. From there you can call in your 30 ninjas and have at.

Creating reliable exploits is for sure the hardest part, but once you've done the initial work on a program, the next few exploits in it are of course more quickly and easily done.

As for the thought experiment, I think that the benefit of the top four researchers is that they've trained themselves over a long period of time (and with passion) to have a very good set of pattern-recognition tools which they call instincts. They know how to get crashes, and they know having seen one crash what's likely to find more. They know how to think about a process to get proper execution, and they're rewarded by success emotionally which makes the lesson learned this time around stick for when they need it again.

I honestly think that there is more pattern recognition "muscle-memory" type skill involved in RE, bug hunting, and exploit dev than pure mechanical process, which is why the numbers are so

skewed. It's like taking 4 native speakers of a language (who love to read!) and 100 students of general linguistics with a zillion dollars. Who will read a book in the language faster?

Q: How easy is discovery for someone with resources like the Chinese government?

John: Much simpler.

Ben: Setting aside the previous point that discovery is only the start, I think it's instructive to consider which elements of the process scale well with money.

Finding the bugs: You need a fuzzing infrastructure that scales - running peach on one laptop with 30 ninjas standing around it with IDA Pro open is not going to work. Also consider tracking what you've already tested, tracking the results, storing all the crashes, blah blah blah. This does scale well with money, but it's an area that not as many people have looked at as I would like.

Seeing which bugs are exploitable: Using a naive approach, this scales horribly poorly with money - non-linearly, to put it mildly. There are only so many analysts you will be able to hire that have enough smarts to look at a non-trivial bug and correctly determine its exploitability. You only have to look at some of the Immunity guys' (hi Kostya) records with turning bugs that other people had discarded as DoS or "Just Too Hard" into tight exploits. Even for ninjas, it's slow. There is research being done into doing 'some' of this process automatically (well, I'm doing some, and I know a couple of other guys are too, so that counts), but I don't know of anyone that has a great result in the area yet - I'd love to be corrected.

Creating nice, reliable exploits: I'd assert that this is like the previous point, but even harder. To be honest, it's not really my thing, so probably one of the people that write exploits for a living would be better to comment, but from talking to those kind of guys, it's often a very long road from 'woo we control ebx' to reliable exploitation, especially against modern OSes and modern software that has lots of stuff built in to make your life harder. I don't know how much of the process can really be automated - I mean there are some nice things like the (old now) EEREAP and newer windbg extensions from the Metasploit guys that will find you jump targets according to parameters and so forth, but up until now I was labouring under the impression that a lot of it remains brain-jitsu, which is hard to scale linearly with money.

So, while I think that 'simpler' is certainly unassailable, I would need more than a two word assertion to be convinced that it is 'much' simpler. If you give one team a million dollars and 100 people selected at random from the top 10% graduating computer science and you give the other team their pick of any 4 researchers in the world and 3 imacs, whom does the smart money think will produce more weapons grade 0day after 6 months?

(No it's not a fair comparison. It's a thought experiment.)

Food for thought, perhaps, since sound bites need little care and feeding.

Q: How bad is it really?

John: Look at the CVSSv2 score and adjust it to the environments where you determine "how bad it is." It could be much worse.

Q: I suspect we are just looking at one grain of sand in a beach of 0-days....

John: Correct. No one wants to let everyone else know what cards they hold in their hand, the tools in their toolbox, etc....

If I were cyberczar

2009-12-23T12:57:00.004-10:00

(Read to the tune of "Rage Against the Machine : Killing in the Name")

1) I would defeat SQL Injection. This would be a multi-phased plan focusing on programmer tools and programmer training. The main use of any Federal funding I could secure would be to build the worlds best open source SQL Escaping library so legacy code could be retrofitted.

2) I would lobby the Fed's to create a new branch of the military. ARMY - NAVY - AIRFORCE - CYBERFORCE - MARINES. The problem is that big, and we are losing the game.

3) I would take copious notes from day 1. This is a thankless job with heaps of responsibility and absolutely no power. Might as well get a good book deal out of the experience.

OWASP Top 5 rc1 released!

2009-11-22T00:30:00.006-10:00

I'm very impressed with the latest OWASP Top 10 2010 release candidate . But if a 10 item list is to long for you in this era of 140 character tweets, I present to you the unauthorized reductionistic OWASP Top 5.

And the OWASP Top 5 is:

1) Injection Flaws

2) Broken Authentication

3) Broken Access Control

4) Broken Encryption

5) Security Misconfiguration

The OWASP Top 5 team felt that A2 (XSS) could be considered to be another kind of injection problem. Like most injection flaws, XSS is controlled by contextual encoding.

A4 (Direct Object Reference), A5 (CSRF), A6 (Failure to Restrict URL Access) and A8 (Unvalidated Redirects and Forwards) could be considered to be classes of access control/authorization flaws. I think that A4/A6/A8 all easily fit into the access control category. But CSRF as just an access control problem? Yes! Authentication validates WHO you are. Authorization/Access Control validates WHAT can you do. CSRF tokens are just a piece of that task/activity validation.

A9 (Insecure Cryptographic Storage) and A10 (Insufficient Transport Layer Security) are 2 sides of the same data-encryption-lifecycle.

Hat's off to the OWASP Top Ten team. This brief reductionism is just a form of OWASP Top 10 flattery! :)

Hardware Security

2009-11-14T23:58:00.002-10:00

A recent article in "Foreign Affairs" magazine titled "Securing the Information Highway" (co-authored by General Clarke and Peter Levin) caught my attention. Interesting stuff. Focuses on hardware security.

http://www.foreignaffairs.com/articles/65499/wesley-k-clark-and-peter-l-levin/securing-the-information-highway

Their basic thesis is that there is just no way possible to stop the threat of "electronic infiltration, data theft, and hardware sabotage" and that securing the nation infrastructure is "neither cost effective or technically feasible".

They suggest:

1) Risk Management : "US must develop an integrated strategy that addresses ... the sprawling communications network to the individual chips inside computers"
2) Diversification of the country's digital infrastructure
3) Secure the hardware supply chain

Worthwhile read.

justifying the focus on insider threat

2009-08-17T13:47:00.003-10:00

Thank you to Mat Caughron at mat@phpconsulting.com for authoring this most excellent blog entry.

It is common to have the insider threat dismissed as a scare tactic or
worst-case-scenario and I believe this is a mistake.

We are all about the business value of risk.

Most enterprise companies have to protect themselves from malicious
insiders at all times and this affects the design of their software,
specifically the need for least privilege and generally all
requirements surrounding logging and internal controls. My thinking
is that if you want to have a seat at the table during the beginning
phases of the software development life cycle, it is best to master
the concerns and business needs imposed by this type of risk.

Granted, our industry seems to generate snake oil by the barrel, which
is all the more reason for us to take these threats seriously and
calmly seek publicly documented data on real cases.

Indeed, one would hope the information security professional is
someone who helps to establish the boundaries of trust in systems
being built, not someone who vacuums up the pieces of broken projects,
however well such housekeeping pays.

Some references not yet mentioned in this thread:

Report from 1999 by NSTISSAM:
http://www.cnss.gov/Assets/pdf/nstissam_infosec_1-99.pdf
Focus is on mechanisms more than specific incidents though a few are mentioned.

U^S3 report with Carnegie Mellon on insider threat, focus on
infrastructure and financial services industries, dated 2004/05/08:
http://www.secretservice.gov/ntac/its_report_050516.pdf
http://www.secretservice.gov/ntac/its_report_040820.pdf
http://www.treasury.gov/usss/ntac/gov%20ExecSummary%202008_0108.pdf
Each sampling set is around 50 incidents or less.

Department of Energy is grappling with this as the disruptions from
insiders could be high impact:
http://www.cio.energy.gov/documents/Tues_1400_SalonII_Randall.pdf

Belani / Wilson web application incident response and forensics
considers insider threats with two great examples:
www.blackhat.com/presentations/bh-usa-06/BH-US-06-Willis.pdf
Also presented in Seattle at an OWASP chapter meeting.

None of these reports, however, can compare in detail to the data set
of the Privacy Rights Clearinghouse' chronological list of data
breaches.
http://www.privacyrights.org/ar/ChronDataBreaches.htm

Until about 2006, the PRC list identified inside threat incidents as
"Dishonest insider." After that, the number of employee instigated
events is described with greater detail but is therefore harder to
search. A quick look here should be enough to convince most on this
webappsec list that the impact from insider threats is not
insignificant.

As software security professionals, we can help to mitigate insider
threat problems and our value in doing so should not be
underestimated.

The commonplace nature of OWASP-top-ten type flaws should not prevent
us from acknowledging their utility in the hands of a malicious
employee, developer, manager, etc.

Mat Caughron CISSP
(408) 910-1266

mat@phpconsulting.com

When to use OWASP AntiSamy?

2009-08-09T11:41:00.003-10:00

OWASP AntiSamy is a software engineering tool that allows a programmer to verify user-driven HTML/CSS input against a whitelist policy to ensure that is does not contain XSS.

But when do you use it?

1) If you accept "normal text data" from a user, then

a) (input validation) Use the ESAPI validator for input valiation (functions OTHER than getValidSafeHTML)

b) (output encoding) Use the ESAPI encoding library for contextual output encoding when displaying dynamic data in a web browser

1. encodeForHTML

2. encodeForJavascript

3. encodeForHTMLEntity

4. encodeForCSS

2) If you accept HTML from a user, you need to use AntiSamy

a) (input validation) You must validate and CHANGE (make it safer) HTML that you accept from a user with AntiSamy (which can be called via ESAPI - getValidSafeHTML)

b) (output translation) You can optionally use AntySamy for output translation (it does not encode; it only makes HTML "safer")

1. This is crucial when you have legacy HTML in your data storage mechanism that may still contain XSS

Real world cookie length limits

2009-08-08T21:56:00.001-10:00

Daniel Stenberg recently posted some interesting test code and browser results to http-state@ietf.org describing the maximum amount of data that can be stored in a cookie:

****

... I just went ahead and wrote a CGI script that redirects to itself and grows a
cookie and stores its length in a URL field like "cookie.cgi?len=200" until
the length in the URL and the actual cookie length no longer matches.

Here's a few results from various browsers:

Firefox 3.0.12: 4000
Firefox 3.5: 4000
curl 7.19.5: 4999
IE 8: 5000
Opera 10.00 beta: 4000
Android 1.5 browser: 4000
Chrome 3.0.195.6: 4000
Wget 1.11.4: 7000[*]
mobile safari (iphone): 8000
lynx 2.8.7dev.9: 4000

I think we can safely say that most browsers support at least 4000 characters
cookie contents.

[*] = this reports "500 Internal Server Error" on 8000, which I don't
understand why but haven't bothered much more about.

The test is live here: http://daniel.haxx.se/test/longcookie.cgi Feel free to
use it if you want to try out other browsers, without torturing it of course!

And the perl script that runs it looks like this:

require "CGI.pm";

$len = CGI::param('len');
$c = CGI::cookie('data');

print "Content-Type: text/html\n";

if($len == length($c)) {
$c .= "A" x 1000;
$len += 1000;
print "Set-Cookie: data=$c\n";

print "Location: longcookie.cgi?len=$len\n";
print "\nmoo\n";
}
else {
printf "\nMax cookie length: %d\n", length($c);
}

Open letter to the Struts 1.x team on AUTOCOMPLETE

2009-07-18T12:33:00.006-10:00

I'm a big fan of Struts 1.3.x. I currently use Struts 1.3.10, the latest release of the 1.x Struts line.

I would like the ability to disable autocomplete in an HTML form. Sadly (from a security perspective), most every browser enables autocomplete by default. We need to explicitly attribute our form html with autocomplete="off" - in both the form and form element tags of HTML 4.01+ pages. This is a very basic security protection. Wanting to prevent the browser from caching credit card numbers, PII and other critical user data is a no-brainier; appsec 101.

Now, the recent 1.3.10 release made a great stride in this direction. Finally for the first time the main Struts 1.3.x branch supports the autocomplete tag (which defensive coders need - just to disable this feature via html!). But it's still not enabled by default in Struts! I need to modify the struts tld xml file in order to enable the autocomplete form and form element attribute; which takes me off the main branch of Struts 1.3.x.

I implore you to consider enabling autocomplete by default, so we can turn it off - without having to customize our version of struts 1.3.x! The best security is "secured by default", and this request moves us in that direction.

Jim Manico

OWASP, Intrinsic Security Working Group

ESAPI Logging

2009-06-28T22:54:00.009-10:00

The OWASP ESAPI Logging interface is a security-centric but thin abstraction on top of traditional high-performance logging API's. There are both Log4j and native Java Logging default ESAPI logging implementations. The Log4j implementation is especially mature.

The logging interface of the OWASP ESAPI library pre-defines 4 types of log files entries specific to the glory of security monitoring.

public static final EventType ....

SECURITY_SUCCESS = new EventType( "SECURITY SUCCESS", true);

SECURITY_FAILURE = new EventType( "SECURITY FAILURE", false);

EVENT_SUCCESS = new EventType( "EVENT SUCCESS", true);

EVENT_FAILURE = new EventType( "EVENT FAILURE", false);

Attributing every log entry with a security type is fundamental to ESAPI. Your implementation of ESAPI can extend or change this list if desired.

ESAPI also supports a hierarchy of logging levels which can be configured at runtime to determine the severity of events that are logged, so that those log entries below the current threshold that are discarded. This is a common logging API feature and includes the following severity levels (fatal, error, warning, info, debug, trace).

The ESAPI team considered simply adding a security severity level to Log4J, but decided that was not enough. We wanted to force a programmer to tag every log entry as a security event (or not), regardless of severity level. We did not add yet another logging abstraction to your life lightly.

The reference implementations also includes the following protections:

encodes any CRLF characters included in log data in order to prevent log injection attacks
optionally encodes HTML characters into the HTML entity to protect web based log viewing software
provides a mechanism to log session ids referentially so that sessions can be tracked in log files without exposing real session identifiers that could be used to hijack active sessions
provides a mechanism to automatically log HTTP post/get variables while allowing for masking of passwords and other security-critical information that should not be logged

Much of this is configurable in ESAPI.properties

ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
#ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory
Specify your application name if you wish to log it.
Logger.ApplicationName=ARMS
# If you use an HTML log viewer that does not properly HTML escape
# log data, you can set LogEncodingRequired to true
Logger.LogEncodingRequired=false
Logger.LogApplicationName=false
Logger.LogServerIP=false
# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you
# want to place it in a specific directory.
Logger.LogFileName=ARMS_ESAPI_LOGFILE
# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)
Logger.MaxLogFileSize=10000000

So now you want to (securely) log. Right on. Simply specify a logger in each class that requires logging:

private final Logger logger = ESAPI.getLogger(SimpleESAPIFilter.class.getName());

And log away!

logger.error(Logger.SECURITY_FAILURE, "session has expired, log out user");

Here is an example of a log entry from one of my projects at Aspect. I'm not deploying on a cluster, yet, so I supressed the server IP, port and appName via ESAPI.properties.

2009-06-29 05:48:25,281 WARN IntrusionDetector SECURITY FAILURE Anonymous:0@unknown:unknown Incorrect password provided for dave
org.owasp.esapi.errors.ValidationException: Login failed
at com.aspectsecurity.arms.web.SimpleESAPIFilter.doFilter(SimpleESAPIFilter.java:149)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.web.actions.ARMSBaseAction EVENT SUCCESS Anonymous:0@unknown:270186 ENTRY POINT FOR ALL ACTIONS: 1246268905281
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 START assertAuthorizedForAction : action=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction
2009-06-29 05:48:25,281 ERROR com.aspectsecurity.arms.service.HibernateAccessController SECURITY SUCCESS Anonymous:0@unknown:270186 ACCESS GRANTED assertAuthorizedForAction completeActionName=com.aspectsecurity.arms.web.actions.user.LoginSubmitAction IS NOT MANAGED, SO ALLOW GLOBAL ACCESS

One file to secure them all

2009-06-25T00:00:00.003-10:00

Can you imagine having a WebAppSec program for your company that standardized on a open source secure code library, which was vetted by many smart people, and had several supporting tools available that could be used to ensure its use? I can....

Jeff is getting close to releasing ESAPI 2.0. I was checking out the new ESAPI default configuration file, checking in a little bit of cleanup, and was very taken aback by all of the rich appsec defense categories that it covers.

# Properties file for OWASP Enterprise Security API (ESAPI)

# You can find more information about ESAPI

# http://www.owasp.org/index.php/ESAPI

# WARNING: Operating system protection should be used to lock down the .esapi

# resources directory and all the files inside. Note that if you are using file-based

# implementations that some files may need to be read-write as they get

# updated dynamically.

# Before using, be sure to update the MasterKey and MasterSalt as described below.

#===========================================================================

# ESAPI Configuration

# ESAPI is designed to be easily extensible. You can use the reference implementation

# or implement your own providers to take advantage of your enterprise's security

# infrastructure. The functions in ESAPI are referenced using the ESAPI locator, like:

# ESAPI.encryptor().encrypt( "Secret message" );

# Below you can specify the classname for the provider that you wish to use in your

# application. The only requirement is that it implement the appropriate ESAPI interface.

# This allows you to switch security implementations in the future without rewriting the

# entire application.

# DefaultAccessController requires ESAPI-AccessControlPolicy.xml in .esapi directory

ESAPI.AccessControl=org.owasp.esapi.reference.accesscontrol.DefaultAccessController

# FileBasedAuthenticator requires users.txt file in .esapi directory

ESAPI.Authenticator=org.owasp.esapi.reference.FileBasedAuthenticator

ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder

ESAPI.Encryptor=org.owasp.esapi.reference.JavaEncryptor

ESAPI.Executor=org.owasp.esapi.reference.DefaultExecutor

ESAPI.HTTPUtilities=org.owasp.esapi.reference.DefaultHTTPUtilities

ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector

# Log4JFactory Requires log4j.xml or log4j.properties in classpath - http://www.laliluna.de/log4j-tutorial.html

ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory

#ESAPI.Logger=org.owasp.esapi.reference.JavaLogFactory

ESAPI.Randomizer=org.owasp.esapi.reference.DefaultRandomizer

ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator

#===========================================================================

# ESAPI Authenticator

Authenticator.AllowedLoginAttempts=3

Authenticator.MaxOldPasswordHashes=13

Authenticator.UsernameParameterName=username

Authenticator.PasswordParameterName=password

# RememberTokenDuration (in days)

Authenticator.RememberTokenDuration=14

# Session Timeouts (in minutes)

Authenticator.IdleTimeoutDuration=20

Authenticator.AbsoluteTimeoutDuration=120

#===========================================================================

# ESAPI Encryption

# The ESAPI Encryptor provides basic cryptographic functions with a simplified API.

# To get started, generate a new key using java -classpath esapi.jar org.owasp.esapi.reference.JavaEncryptor

# There is not currently any support for key rotation, so be careful when changing your key and salt as it

# will invalidate all signed, encrypted, and hashed data.

# WARNING: Not all combinations of algorithms and key lengths are supported.

# If you choose to use a key length greater than 128 (and you should), you must download the

# unlimited strength policy files and install in the lib directory of your JRE/JDK.

# See http://java.sun.com/javase/downloads/index.jsp for more information.

Encryptor.MasterKey=pJhlri8JbuFYDgkqtHmm9s0Ziug2PE7ovZDyEPm4j14=

Encryptor.MasterSalt=SbftnvmEWD5ZHHP+pX3fqugNysc=

# AES is the most widely used and strongest encryption algorithm

Encryptor.EncryptionKeyLength=256

Encryptor.EncryptionAlgorithm=AES

# Do not use DES except in a legacy situation

#Encryptor.EncryptionKeyLength=56

#Encryptor.EncryptionAlgorithm=DES

# TripleDES is considered strong enough for most purposes

#Encryptor.EncryptionKeyLength=168

#Encryptor.EncryptionAlgorithm=DESede

Encryptor.HashAlgorithm=SHA-512

Encryptor.HashIterations=1024

Encryptor.DigitalSignatureAlgorithm=DSA

Encryptor.DigitalSignatureKeyLength=1024

Encryptor.RandomAlgorithm=SHA1PRNG

Encryptor.CharacterEncoding=UTF-8

#===========================================================================

# ESAPI HttpUtilties

# The HttpUtilities provide basic protections to HTTP requests and responses. Primarily these methods

# protect against malicious data from attackers, such as unprintable characters, escaped characters,

# and other simple attacks. The HttpUtilities also provides utility methods for dealing with cookies,

# headers, and CSRF tokens.

# Default file upload location (remember to escape backslashes with \\)

HttpUtilities.UploadDir=C:\\ESAPI\\testUpload

# Force HTTP only on all cookies in ESAPI SafeRequest

HttpUtilities.ForceHTTPOnly=false

# File upload configuration

HttpUtilities.ApprovedUploadExtensions=.zip,.pdf,.doc,.docx,.ppt,.pptx,.tar,.gz,.tgz,.rar,.war,.jar,.ear,.xls,.rtf,.properties,.java,.class,.txt,.xml,.jsp,.jsf,.exe,.dll

HttpUtilities.MaxUploadFileBytes=500000000

# Using UTF-8 throughout your stack is highly recommended. That includes your database driver,

# container, and any other technologies you may be using. Failure to do this may expose you

# to Unicode transcoding injection attacks. Use of UTF-8 does not hinder internationalization.

HttpUtilities.ResponseContentType=text/html; charset=UTF-8

#===========================================================================

# ESAPI Executor

Executor.WorkingDirectory=C:\\Windows\\Temp

Executor.ApprovedExecutables=C:\\Windows\\System32\\cmd.exe,C:\\Windows\\System32\\runas.exe

#===========================================================================

# ESAPI Logging

# Set the application name if these logs are combined with other applications

Logger.ApplicationName=ESAPITest

# If you use an HTML log viewer that does not properly HTML escape log data, you can set LogEncodingRequired to true

Logger.LogEncodingRequired=false

# LogFileName, the name of the logging file. Provide a full directory path (e.g., C:\\ESAPI\\ESAPI_logging_file) if you

# want to place it in a specific directory.

Logger.LogFileName=ESAPI_logging_file

# MaxLogFileSize, the max size (in bytes) of a single log file before it cuts over to a new one (default is 10,000,000)

Logger.MaxLogFileSize=10000000

#===========================================================================

# ESAPI Intrusion Detection

# Each event has a base to which .count, .interval, and .action are added

# The IntrusionException will fire if we receive "count" events within "interval" seconds

# The IntrusionDetector is configurable to take the following actions: log, logout, and disable

# (multiple actions separated by commas are allowed e.g. event.test.actions=log,disable

# Custom Events

# Names must start with "event." as the base

# Use IntrusionDetector.addEvent( "test" ) in your code to trigger "event.test" here

IntrusionDetector.event.test.count=2

IntrusionDetector.event.test.interval=10

IntrusionDetector.event.test.actions=disable,log

# Exception Events

# All EnterpriseSecurityExceptions are registered automatically

# Call IntrusionDetector.getInstance().addException(e) for Exceptions that do not extend EnterpriseSecurityException

# Use the fully qualified classname of the exception as the base

# any intrusion is an attack

IntrusionDetector.org.owasp.esapi.errors.IntrusionException.count=1

IntrusionDetector.org.owasp.esapi.errors.IntrusionException.interval=1

IntrusionDetector.org.owasp.esapi.errors.IntrusionException.actions=log,disable,logout

# for test purposes

IntrusionDetector.org.owasp.esapi.errors.IntegrityException.count=10

IntrusionDetector.org.owasp.esapi.errors.IntegrityException.interval=5

IntrusionDetector.org.owasp.esapi.errors.IntegrityException.actions=log,disable,logout

# rapid validation errors indicate scans or attacks in progress

# org.owasp.esapi.errors.ValidationException.count=10

# org.owasp.esapi.errors.ValidationException.interval=10

# org.owasp.esapi.errors.ValidationException.actions=log,logout

# sessions jumping between hosts indicates session hijacking

IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.count=2

IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.interval=10

IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.actions=log,logout

#===========================================================================

# ESAPI Validation

# The ESAPI validator does many security checks on input, such as canonicalization

# and whitelist validation. Note that all of these validation rules are applied *after*

# canonicalization. Double-encoded characters (even with different encodings involved,

# are never allowed.

# To use:

# First set up a pattern below. You can choose any name you want, prefixed by the word

# "Validation." For example:

# Validation.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$

# Then you can validate in your code against the pattern like this:

# Validator.getInstance().getValidDataFromBrowser( "Email", input );

# Validator.getInstance().isValidDataFromBrowser( "Email", input );

Validator.SafeString=^[\p{L}\p{N}.]{0,1024}$

Validator.Email=^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\\.[a-zA-Z]{2,4}$

Validator.IPAddress=^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$

Validator.URL=^(ht|f)tp(s?)\\:\\/\\/[0-9a-zA-Z]([-.\\w]*[0-9a-zA-Z])*(:(0-9)*)*(\\/?)([a-zA-Z0-9\\-\\.\\?\\,\\:\\'\\/\\\\\\+=&%\\$#_]*)?$

Validator.CreditCard=^(\\d{4}[- ]?){3}\\d{4}$

Validator.SSN=^(?!000)([0-6]\\d{2}|7([0-6]\\d|7[012]))([ -]?)(?!00)\\d\\d\\3(?!0000)\\d{4}$

# Validators used by ESAPI

Validator.AccountName=^[a-zA-Z0-9]{3,20}$

Validator.SystemCommand=^[a-zA-Z\\-\\/]{0,64}$

Validator.RoleName=^[a-z]{1,20}$

Validator.Redirect=^\\/test.*$

# Global HTTP Validation Rules

# Values with Base64 encoded data (e.g. encrypted state) will need at least [a-zA-Z0-9\/+=]

Validator.HTTPScheme=^(http|https)$

Validator.HTTPServerName=^[a-zA-Z0-9_.\\-]*$

Validator.HTTPParameterName=^[a-zA-Z0-9_]{0,32}$

Validator.HTTPParameterValue=^[a-zA-Z0-9.\\-\\/+=_ ]*$

Validator.HTTPCookieName=^[a-zA-Z0-9\\-_]{0,32}$

Validator.HTTPCookieValue=^[a-zA-Z0-9\\-\\/+=_ ]*$

Validator.HTTPHeaderName=^[a-zA-Z0-9\\-_]{0,32}$

Validator.HTTPHeaderValue=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$

Validator.HTTPContextPath=^[a-zA-Z0-9.\\-_]*$

Validator.HTTPPath=^[a-zA-Z0-9.\\-_]*$

Validator.HTTPQueryString=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ](1,50)$

Validator.HTTPURI=^[a-zA-Z0-9()\\-=\\*\\.\\?;,+\\/:&_ ]*$

Validator.HTTPURL=^.*$

Validator.HTTPJSESSIONID=^[A-Z0-9]{10,30}$

# Validation of file related input

Validator.FileName=^[a-zA-Z0-9!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{0,255}$

Validator.DirectoryName=^[a-zA-Z0-9:\\\\!@#$%^&{}\\[\\]()_+\\-=,.~'` ]{0,255}$

OWASP Podcast #26 - April News part 2

2009-06-17T13:18:00.004-10:00

I just pushed OWASP Podcast #26 live. We had Tom Brennan (White Hat Security), Alex Smolen (Foundstone), Jeff Williams (Aspect) and Andre Gironda (The "House" of AppSec) on the show - a very mixed group with different perspectives.

Download options and show notes are here http://www.owasp.org/index.php/Podcast_26 or just grab the mp3 http://www.owasp.org/download/jmanico/owasp_podcast_26.mp3

PS : We discussed the following articles:

4/16 http://www.informit.com/articles/article.aspx?p=1338343: http://www.cigital.com/justiceleague/2009/04/16/software-security-2008/ Gary McGraw uses statistics to show that Software (Application) Security has come of age
4/17 http://research.zscaler.com/2009/04/we-used-to-laugh-at-xss.html: Michael Sutton discusses history of XSS from Defcon 10 (2002) to the present day (Twitter worm)
4/17 http://jeremiahgrossman.blogspot.com/2009/04/software-security-grew-to-nearly-500m.html: Jeremiah uses McDonalds and Mortons as comparatives for black-box vs. white-box security testing
4/17 http://jeremiahgrossman.blogspot.com/2009/04/website-threats-and-their-capabilities.html: OWASP Catalyst announced
4/20 http://paco.to/?p=305: Paco lists 5 reasons for software certifications
4/20 http://labs.securitycompass.com/index.php/2009/04/20/security-analysis-of-core-j2ee-design-patterns/: Rohit Sethi of SecurityCompass posts a blog post on a new Security Compass Labs blog about "Security Analysis of Core Java Enterprise Patterns"
4/21 http://docs.google.com/Doc?id=dd7x5smw_16hdd34ggz: mario heiderich posts some results of browser fuzzing on extraneous characters in tags
4/22 http://plynt.com/blog/2009/04/how-frequently-should-an-appli/: The Plynt blog asks the question, "How frequently shoud Applications be Tested?"
4/24 http://www.troopers09.org/content/e3/e445/index_eng.html: Wendel Guglielmetti Henrique from Trustwave and Sandro Gauchi of EnableSecurity spoke at TROOPERS09 in Munch about "The Truth of Web Application Firewalls: what the vendors do NOT want you to know"
4/27 http://tacticalwebappsec.blogspot.com/2009/04/scanner-and-waf-data-sharing.html: Ryan Barnett gives guidance on how best to make VA+WAF work together
4/27 http://www.owasp.org/index.php/Category:OWASP_PCI_Project: Ed Bellis and Trey Ford start a PCI effort to ensure their activities uniformly meet PCI requirements, and for those getting started - to aid in building a website security strategy that also ensures sustainable PCI compliance.

OWASP Podcast #24 - April News part 1

2009-06-12T02:23:00.005-10:00

OWASP Podcast #24 - Part 1 of the OWASP Newscast for April 2009 - is now live!

OWASP Podcast #24 features Alex Smolen, Andre Gironda and Jeff Williams. Andre did all of the extensive copy editor work. We cover a variety of Web App Sec articles found here. The show lasts about 40 minutes.

To listen to OWASP Podcast #24 you can download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes!

Has WHS jumped the shark?

2009-06-08T12:11:00.007-10:00

Does the "WhiteHat Website Security Certification Program" demonstrate that WHS has jumped the proverbial shark?

25% or more of WHS's customers demanded a logo program of this nature, says Jeremiah Grossman, CTO of WHS. Customer demand is not something to ignore lightly.

By the same token, website logo programs of this nature have a dubious past, at best.

Take McAfee's "Hack Safe" program as an obvious example. The level of negative press that the "Hacker Safe" program has generated to date is outstanding.

McAfee 'Hacker Safe' cert sheds more cred. Rubber stamp factory exposed
http://www.theregister.co.uk/2008/04/29/mcafee_hacker_safe_sites_vulnerable/

More bad news for McAfee, HackerSafe certification
http://blogs.zdnet.com/security/?p=1068

Hackersafe? Not so much.
http://holisticinfosec.org/video/HS_ISSA/ISSA_Regional_HackerSafe.html

Russ McGee had a very interesting blog post that was favorable to WHS's new website cert program.

http://holisticinfosec.blogspot.com/2009/05/whitehats-trustmark-program-as-game.html. In the comment section, Jeremiah states:

I think it's also fair to say that what we're offering is more of a "Trust mark" than "Security mark." We do not want lay claim as to the implied security of a website, or the lack thereof. Doing so is a very slippery slope. If our mark does that it is not our intent and we are open to ideas on how best to clarify its true meaning.

To answer your question, only Sentinel customers may display our mark -- which does not come cheaply as compared to others. Organizations who use the Sentinel Service are those who really care about security and the mark should represent that.

and http://www.whitehatsec.com/home/services/certified.html states:

The “website security by WhiteHat Security” mark allows Sentinel subscribers to assure their site visitors that the WhiteHat Sentinel Services is being actively deployed to safeguard confidential data from security breaches and hacker attacks

Jeremiah was faced with a rather difficult choice : upset his customer, or upset some in the security community.

But I must call this a "security fail" for for time being.

a) This cert is not claiming that the website is secure
b) This cert claims that Whitehat Security is the web security service provider, only
c) This cert is consumer based; it's meant for the consumer not the security pro
d) A security-ignorant consumer (the masses) will incorrectly conclude that the website IS secure based on seeing the WHS certification logo, even thou WHS is not making that claim

We need more in-depth verification and more process, not less. Projects like the OWASP Application Security Verification Standard meets that challenge head-on.

http://manicode.blogspot.com/2009/06/owasp-asvs-release-version-published.html

PS: So in a few years, when we have a "Aspect Assured" logo, please give me a hard time. :)

OWASP ASVS Release Version published

2009-06-08T09:36:00.004-10:00

Release quality OWASP projects are the level of quality of professional tools and documents.

Application Security Verification Standards are specifications produced by OWASP in cooperation with secure applications developers and verifiers worldwide for the purpose of accelerating the deployment of secure Web applications. First published in 2008 as a result of an OWASP Summer of Code grant and meetings with a small group of early adopters, the ASVS documents have become widely referenced and implemented. Further development of ASVS occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. You can download it here (http://www.owasp.org/index.php/ASVS).

For more information, please contact us. Mike Boberski, Jeff Williams, and Dave Wichers are the primary authors.

OWASP Podcast #23 - Dr. Boaz Gelbord

2009-06-01T00:00:00.005-10:00

OWASP Podcast #23, an interview with Dr. Boaz Gelbord - is now live! http://www.owasp.org/download/jmanico/owasp_podcast_23.mp3

Boaz is the co-author of the OWASP Security Spending Benchmarks Project.

RSS: http://www.owasp.org/download/jmanico/podcast.xml
iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012

'Sound' Analysis by Dave Wichers

2009-05-26T12:12:00.012-10:00

( This blog post was authored by dave.wichers@aspectsecurity.com )

I recently attended the NSA High Confidence Software & Systems (HCSS) Conference and noticed that many tool vendors and researchers working on static and dynamic analysis were using a new term called sound analysis, which means, ‘no false negatives’. In other words, a ‘sound’ analysis won’t miss any of the types of flaws it is looking for. It might have some false positives.

Bill Scherlis, one of the speakers, defined this as: “In a sound analysis, as distinct from heuristic analysis, we do not produce false negatives. If there is a defect of a particular variety, our sound analysis will find it. I’ll note that a sound analysis may have false positives. The mathematics generally preclude the possibility of having it both ways. But in practice we don’t get many false positives. But the main point is to avoid false negatives, to not miss a diagnosis. We may occasionally over-diagnose but we will never miss a diagnosis.”

I like the idea of this, but I have never heard any of the vendors in our space claim sound analysis for anything they look for. I did see one vendor there that claimed they could provide sound analysis for buffer overflows. The company was Kestrel Technology. They define soundness as: http://www.kestreltechnology.com/about/sound.php

So, if you hear of any code scanning vendor claim they provide ‘sound’ analysis, I’d be interested in hearing about it. dave.wichers@aspectsecurity.com

- Dave Wichers

PS: Because Kestrel does ‘sound’ analysis, they are able to report the kinds of positive information I would love to see from a tool. In my presentation, I had the following security facts label (updated based on Jeff’s original idea 5+ years ago). Imagine tools in our space reporting what I have listed in gray … Wouldn’t that be nice :-)

PPS: I don’t think this is an attack ‘against’ the tools. I think there are two points here:
1) Sound analysis vs. best we can do with current state of the art (and even sound analysis can improve with less false positives).
2) And separately, tools reporting what they have found that’s good, rather just what is bad. However, if tools aren’t doing ‘sound’ analysis, they will be reluctant to report goodness, since they can’t find/report everything that’s relevant (and are thus unsound) :)

OWASP Top 6 2009

2009-05-26T00:19:00.001-10:00

6. OWASP Legal Project (Secure Software Contracts for Developers and their Clients) http://www.owasp.org/index.php/Category:OWASP_Legal_Project

5. OWASP Live CD! FREE TOOLS! http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project

4. OWASP Application Security Verification Standard http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

3. OWASP Code Review Guide http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

2. OWASP Developers Guide http://www.owasp.org/index.php/Category:OWASP_Guide_Project

1. OWASP Coders Security Library for Java, PHP, .NET, ASP and Haskel (ESAPI - FOSS
Enterprise Security API) http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Please do not log session ids

2009-05-25T18:07:00.021-10:00

I'm very disappointed to see Johannes Ullrich @ the Internet Storm Center lead off the SANS Software Security Institute blogging effort at appsecstreetfighter.com by providing a software security recommendation that will significantly increase application risk!!

http://appsecstreetfighter.com/2009/05/24/logging-cookies-in-apache/

This is absolutely positively bad application security advice. Logging a session id will actually increase application risk! Never log session ids!

To quote Johannes, "The cookie typically includes the session ID, which then links to a particular user. So this way, you can figure out which user caused a particular action."

An insider could hijack all active sessions by simply having access to a live application log file.

Never log session ids. If you need to uniquely identify each session in your log files for debugging or other purposes, then hash your session id's before logging them. Only transmit session ids over well configured https. Keep session ids out of urls. Make sure session ids are cryptographically random and long. Reduce idle timeout. Enforce absolute timeout. Invalidate session ids at logout.

But really, if you think you need to log a session id or ANY credentials, think again.

Make sure your Web Application Security educator utilizes OWASP principles!

PS: appsecstreetfighter.com is a great blog name.

OWASP Podcast #22 - Dan Cornell

2009-05-22T15:06:00.001-10:00

OWASP Podcast #22, an interview with Dan Cornell, CTO of the Denim Group - is now live! http://www.owasp.org/index.php/Podcast_22

Dan is a smart cookie who puts in incredible amount of time volunteering for OWASP. He's a great guy with a very pragmatic perspective on Application Security. I hope you enjoy!

OWASP Podcast Series RSS: http://www.owasp.org/download/jmanico/podcast.xml
OWASP Podcast Series iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012

OWASP Podcast #21 - Richard Stallman

2009-05-20T14:13:00.005-10:00

OWASP Podcast #21, an interview with Richard Stallman, is now live!

Richard is the founder of the GNU Project and the Free Software Foundation. Created the GNU Compiler and Debugger. Emacs, too. He is one of the original (MIT Style) hackers. He also created a few licenses, like the GPL. He is the original Software Freedom Fighter. (Just don't ask him what his Skype address is, ouch my bad)

To listen to OWASP Podcast #21, you can download the OGG file directly or subscribe to the RSS feed. This podcast is only being released in OGG format only to honor Richards request.

I'm very grateful to Shpongle and Twisted Records for allowing the OWASP Podcast Series FREE use of their music for the show!

OWASP Podcast #19 - March 2009 News Part 2

2009-05-12T00:48:00.006-10:00

OWASP Podcast #19 - Part 2 of the OWASP Newscast for March 2009 - is now live!

OWASP Podcast #19 features Arshan Dabirsiagh, Andre Gironda and Jeff Williams. Andre did all of the extensive copy editor work. We cover a variety of Web App Sec articles found here. The show lasts about 55 minutes.

To listen to OWASP Podcast #19 you can download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes!

Gareth Heyes was kind enough to donate some new album art for the show!

The OWASP Podcast News Commentary Show will soon be on a 2 week production cycle. I've also invited John Steven from Cigital, Alex Smollen from Foundstone, and Tom Brennan from Whitehat Security to join the show. It should make for a very interesting appsec mix!

OWASP Podcast #18 - Jeremiah Grossman

2009-05-03T20:13:00.003-10:00

OWASP Podcast #18, an interview with Jeremiah Grossman, is now live! Jeremiah is the CTO of Whitehat Security and has been an active member of the Web Application Security community for well over 10 years.

To listen to OWASP Podcast #18, you can download the mp3 file directly, subscribe to the RSS feed or subscribe directly through iTunes!

I'm very greatful to Shpongle and Twisted Records for allowing the OWASP Podcast Series to use their music for the show! I'm a very big fan of Ambient and Down-tempo techno. Perfect coding music. Shpongle is among the best.

OWASP Podcast #17 - Interview with RSnake

2009-04-23T14:24:00.006-10:00

OWASP Podcast #17, an interview with Robert Hansen, is now live! Robert achieved fame and glory in the early wild west days of web application security working for e-bay. He's also the brain behind the Google-approved security blog, http://ha.ckers.org .

"courtesy" of ha.ckers.org

OWASP Podcast #16 - Interview with Dave Aitel

2009-04-09T14:03:00.004-10:00

The first rule of Fight Club is: you do not talk about Fight Club.

OWASP Podcast #16, an interview with Dave Aitel, covers a wide variety of topics. Dave started working as a security researcher for the NSA at the age of 18 and has no shortage of experience to pull from in this interview.

To listen to OWASP Podcast #16, you can download the mp3 file directly, subscribe to the RSS feed or subscribe directly through iTunes!

Form input names with reserved words and JQuery

2009-04-07T00:41:00.006-10:00

When you have an HTML form that contains an input field with the name of "action" or "submit" - submitting a form via javascript becomes problematic.

Normally, Jquery users would simply call $("#formid").submit() after referencing a form. However, if your form contains an input field named "submit" (like <input name="submit">) then $("#formid").submit() does not submit the form.

This is my workaround - essentially programatically clicking the submit button, instead of programatically submitting the form.

<html>
<head>
<script src="jquery-1.3.2.js"></script>

<script>
$(document).ready(function() {
alert('action=' + $("#formid").attr("action"));
alert('try to submit');
$("#sneaky").click();
});
</script>

</head>
<body>
<form action="http://www.testdomain.net/actionworksok" id="formid">
<input type=submit name=testname id=sneaky>
<input name=action value=test1>
<input name=submit value=test2>
</form>
</body>
</html>

OWASP Podcast #15 - Interview with Brian Chess

2009-04-06T04:41:00.003-10:00

Brian Chess talks about the Building Security In Maturity Model and software maturity models in general.

To listen to OWASP Podcast #15, you can download the mp3 file directly, subscribe to the RSS feed or subscribe directly through iTunes!

OWASP Podcast #14 - Pravir Chandra and OpenSAMM

2009-03-25T13:36:00.002-10:00

Pravir Chandra talks about the OWASP OpenSAMM project and software maturity models in general. Pravir has been deep in this space for some time and even provides us with the inside scoop as to how OpenSAMM relates to BSIMM!

To listen to OWASP Podcast #14 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes!

OWASP Podcast #13 - Newscast for March 09

2009-03-18T17:28:00.002-10:00

OWASP Podcast #13 - the OWASP newscast for Match 2009 - is now live!

OWASP Podcast #13 features Andre Gironda, Jeff Williams and Arshan Dabirsiagh. The show is hosted by me, Jim Manico. Andre did all of the extensive copy editor work.

To listen to OWASP Podcast #13 you can, download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes, or listen right now!

We cover a very wide array of web app sec news topics. I hope you enjoy the show!

OWASP Podcast #12 - Interview with Ryan C. Barnett

2009-03-11T18:41:00.004-10:00

Ryan Barnett talks about the OWASP ModSecurity core ruleset projec t and WAF technology in general. Ryan has such incredible experience in this space - this one is definately a "must listen" for anyone who deals with web application security operations.

To listen to OWASP Podcast #11 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes!

OWASP Podcast #11 - Interview with Steve Christey and Bob Martin from MITRE

2009-03-04T10:25:00.004-10:00

Steve and Bob give us the "inside scoop" as to how the CWE Top 25 Programming Errors list was created.

To listen to OWASP Podcast #11 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes!

HTTPOnly Supported in Tomcat 6.0.19+

2009-03-02T16:54:00.008-10:00

Jeff caught it first, but the upcoming release of Tomcat 6.0.19 will include HTTPOnly session cookie support!

This upcoming feature will be disabled by default and you will need to use the following setting to enable it.

<Context><Manager useHttpOnly="true" /></Context>

I first blogged about this topic back in March 27, 2008 and submitted a patch to Apache a few days later on March 30, 2008. It's great to know that this functionality will really exist in Tomcat 6.0.19 - which is the current "trunk" as of the posting - and be released - when it's released. =)

To quote someone from the Apache crowd: "If you're interested in getting the next release out more quickly, perhaps you could volunteer to fix some bugs? " =)

OWASP Podcast #10 - an interview with Ken van Wyk

2009-02-28T19:27:00.004-10:00

OWASP Podcast #10 - an interview with Ken van Wyk - is live!!

Ken began to approach application security professionally a lot earlier than most folks. I believe his pragmatic and level-headed perspective is of value to anyone in the information security biz.

To listen to OWASP Podcast #10 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes!

Apache Tomcat HttpOnly Support Saga Continues

2009-02-25T16:24:00.006-10:00

I see Mark Thomas from Apache still trying to get resolution on the whether to back-port the Apache Tomcat 7 HTTPOnly session-id attribution (per Java Servlet 3.0) into Tomcat 6 (a Servlet 2.5 container). The patch has been complete for well over 5 months and is still awaiting approval. What's more important here; standards or security?

For more info:

Update: HTTPOnly is now supported in at least some versions of Tomcat! http://manicode.blogspot.com/2009/03/httponly-supported-in-tomcat-6019.html

OWASP Podcasts #8 and #9 - Newscast

2009-02-19T20:01:00.008-10:00

Hot off the press, OWASP Podcasts #8 and #9 are now live!

OWASP Podcast #8 and #9 make up a 2 part Newscast featuring Andre Gironda, Jeff Williams and Arshan Dabirsiagh hosted by me, Jim Manico(de!).

To listen to OWASP Podcast #8 you can, download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes, or listen right now!

To listen to OWASP Podcast #9 you can, download the mp3 file directly.

We cover a very wide array of news topics, listed here.

HTTPOnly on Tomcat Update

2009-02-15T15:57:00.002-10:00

The following note was sent to the Apache Tomcat DEV community on 2/13/2009 by Mark Thomas, the Tomcat lead. This has been quite an ordeal - it's been over a year and still we are debating the HTTPOnly patch in Tomcat! *sigh*

Folks,

The implementation of httpOnly support in Tomcat 7 fits well with the previous
httpOnly patch [1] that is currently the proposed backport for 6.0.x

When originally proposed there was some concern that the v3 servlet spec may
require some changes. This hasn't been the case. With that in mind could folks
please review their comments and votes for this patch. I'd like to get it into
6.0.19 if posible.

If you still think there is room for improvement, I'm happy to take another look
at this. Some pointers as to how you think things could/should be improved would
be appreciated.

If you do vote for this patch, please remember to indicate your preference for
using or not using httpOnly for session cookies by default.

Cheers,
Mark

Facebook Throttling Rate of New Friends

2009-02-15T11:33:00.004-10:00

Take a look at this CNN TechNews article on Facebook Friend padding.

This article has apparently nothing to do with AppSec. However, this paragraph caught my eye:

"After (Facebook User Zorn) had sent 180 friend requests in less than an hour, an automated note from Facebook popped up on his screen warning him to stop or he’d be kicked off the site."

I think is a excellent defensive coding technique from Facebook. A defensive technique like this would have stopped the MySpace SAMY XSS worm. Samy's worm esentially added friends to his profile so fast and frequently that it took down the global myspace cluster. This friend-adding “throttling” feature could have stopped or slowed down that attack.

This feature is a wise move that will not disturb the vast majority of users. Go Facebook for your appSec excellence!

OWASP Podcast #7 Interview with Jeff Williams

2009-02-13T02:53:00.006-10:00

We just pushed OWASP Podcast #7 - an interview with Jeff Williams - live!.

We discussed Jeff's involvement in OWASP, builders vs breakers, his work on the XSS prevention cheatsheat and of course - ESAPI. Jeff also directly responded to several of Gary McGraw's comments from OWASP Podcast #5 - and did not hold back any punches. This one is sure to please.

To listen to OWASP Podcast #7 you can, download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes, or listen right now!

Long live the king!

Shout out to my co-producer, Kevin Coons from ManaTribe. Keep up the good work, Kevin - we are just getting started!

Threat Classification v2 on Logic Flaws

2009-02-10T13:20:00.007-10:00

MANICODE would like to say thank you to guest blogger Bil Corry who wrote this excellent section for the upcoming "Threat Classification v2 on Logic Flaws". I found his inclusion of recent real world examples to be fascinating!

Threat Classification v2 on Logic Flaws - Real World Examples
By Bil Corry

* Yahoo had a promotional offer where if you deposited USD $30 into an advertising account, Yahoo would then add an additional USD $50 to that account.  The sign-up process was able to be circumvented in such a way that failing to deposit the requisite USD $30 still allowed the additional USD $50 to be credited to the account.

Yahoo SEM Logic Flaw
http://ha.ckers.org/blog/20080616/yahoo-sem-logic-flaw/

* Tower Records' form validation assumed that the user would fill out a form in the order presented, but in reality, some users filled out the bottom portion first, causing a bug that wasn't caught during development and resulted in the loss of sales.

Tower Records Tunes Its Site
http://www.storefrontbacktalk.com/story/021005tower.php

* YouTube restricts some videos to users that are 18-years-old and older on their site. However, if the same video is embedded in another site, then the process that filters the videos is bypassed, allowing anyone of any age to view the video.

Youtube’s 18+ Filters Don’t Work
http://www.darkseoprogramming.com/2008/06/01/youtubes-18-filters-dont-work/

* Facebook restricts access to private user pages, but there have been incidences where an attacker can replace the user ID in the URL with a victim ID, thereby circumventing the security measures.  Two examples include accessing private photos and accessing private fan pages.

Peekaboo! Facebook fills photo security hole
http://news.cnet.com/8301-1009_3-10042909-83.html

Hole unveils Facebook fan pages
http://news.cnet.com/8301-1009_3-10046932-83.html

* E-trade and Schwab failed to limit one bank account to any given user, allowing an attacker to assign the same bank account to tens of thousands of users, resulting in a loss of USD $50,000.00.

double-submit cookie CSRF defense and HTTPOnly

2009-02-06T09:37:00.001-10:00

Let's start with reviewing the Wikipedia paragraph on this subject.

A variation on this approach is to "double submit" cookies. If an authentication cookie is read using JavaScript before the post is made, JavaScript's stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript.

They are suggesting that you build your HTML form in a way that at the time the form is posted, javascript gets called which reads the session cookie and places that cookie in the body of the html (or part of the form post payload as a normal form element). The server would then verify that the session id is valid in both the session cookie and the html body (or form post payload). If the CSRF attack code was hosted on a different server than the victim server, this "session cookie transfer to body" code would fail due to the cross domain rules. Not an unreasonable defense!

The scenario for CSRF defense would not work in the face of HTTPOnly. BUT - I can circumvent this defense by placing CSRF attack code on a cross-site that reads the cookies out of an XHR header (since they are not httponly for this defense), and adds it to the post manually. This lets an attacker circumvent double click defense!

Now, as browsers handling of XHR matures, the validity of this claim gets stronger (the claim that double-click defense is good).

IE lets you read cookies out of XHR request headers (that are not httponly) which would let an attacker circumvent the double-cookie defense like I described above. FireFox is vulnerable to this defense too, prior to 3.0.0.6. Starting with FireFox 3.0.0.6, cookies - any cookies - are no longer included in Firefox XHR response headers.

HTTPOnly will block this defense from working, since it depends on JavaScript reading cookie in the context of the current domain.

In a world where you can no longer read ANY cookies from XHR headers, AND httponly is in widespread use - I can see an argument to not use HTTPOnly depending on the risk - which is why implementers for server side products should provide options to disable HTTPOnly! :)

FireFox 3.0.0.6 HTTPOnly Champion!

2009-02-04T11:15:00.007-10:00

FireFox 3.0.0.6 is truly an HTTPOnly champion!

I want to extend sincere congratulations the the entire Mozilla team. For the first time in history, a browser has been released that completely supports the HTTPOnly cookie flag, including protection against leakage of HTTPOnly cookies via XHR response headers.

The JavaScript document.cookie call has been blocked for HTTPOnly cookies since FireFox 2.0.0.6. The problem that delayed true comprehensive HTTPOnly support in FireFox, as described by the bug entry states: "XMLHttpRequest subverts the idea of HTTPOnly cookies since it allows sending a request and reading of Set-Cookie or Set-Cookie2 headers in the response - even if it has HTTPOnly flag set."

IE 7/8 is very close to complete HTTPOnly support. When we test IE 7.0.5730.13 against http://ha.ckers.org/httponly.cgi - the result is set-cookie2 leakage. At least set-cookie is not leaked. (Note that even though IE exposes a set-cookie call below, it was a non-httponly cookie, so the exposure is reasonable.)

But look at the test results of FireFox 3.0.0.6 - ALL SET COOKIE(2) CALLS ARE REMOVED! Even non HTTPOnly cookies are now removed from the XHR request headers!

Sincere congratulations the the entire Mozilla team. I applaud your dedication to web application security excellence!

Servlet Containers and HTTPOnly support

2009-02-02T09:50:00.002-10:00

Oracle (acquired BEA Jan 08) Weblogic is not playing ball at all: http://coding-insecurity.blogspot.com/2008/12/oracle-just-doesn-get-it.html

Apache Tomcat JSESSIONID Cookie: A developer submitted a patch to Apache Tomcat, which is close to going live in Tomcat 7 for sure soon (aiming to be a 3.0 servlet container). The core developers are voting to decide on whether to include HTTPOnly support for Tomcat 5/6 right now. https://issues.apache.org/bugzilla/show_bug.cgi?id=44382

IBM Websphere: (Sept 08) "WebSphere Application Server has been modified to properly recognize, accept and process HTTP-Only cookies. This support is targeted for fixpacks 6.0.2.21 and 6.1.0.11. Please review the recommended updates page at http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg27004980 for more information."

OWASP Podcast #5 - Interview with Gary McGraw

2009-01-26T00:45:00.006-10:00

I just finished updating the OWASP Podcast series RSS/iTunes feed to include OWASP Podcast #5 - an interview with Gary McGraw! You can read the show notes here, download the mp3 file directly here, or subscribe to the OWASP Podcast series RSS Feed here. If you use the iTunes podcast management feature, you can subscribe to the OWASP Podcast series via iTunes here.

The podcast starts with a 30 second introduction from the song "To You Right Now" off the album 100 Feet Above the Ground. Gary performed the mandolin, fiddle, sang backup vocals and produced this album.

Gary did not shy away from any difficult questions in this interview. In fact, he encouraged them. I was very impressed with Gary's courage to dive into controversy - as well as cause it.

Browser HTTPOnly Support Update

2009-01-22T22:13:00.002-10:00

If you update your Windows OS with the the MSXML Core Services patch MS08-069 then IE 8 Beta 2 and IE 7 will prevent HTTPOnly cookies from being read by XMLHTTPRequest headers (set-cookie headers only) within IE. As of this writing, IE 8 Beta 2 and IE 7 are the only browsers that truly stop HTTPOnly set-cookie leakage in XMLHTTPRequest headers. However, IE 8 Beta 2 and IE 7 are not the HTTPOnly-support winners, yet. IE 8 beta 2 and IE 7 with MS08-069 still leaks set-cookie2 HTTPOnly cookies in XMLHTTPRequest headers!

FireFox is on track to fix this obscure vector, completely. The FireFox patch for XMLHTTPRequest HTTPOnly protected is marked RESOLVED FIXED and will go live shortly.

Even Safari/Chrome will also see complete set-cookie/set-cookie2 XMLHTTPRequest exposure protection shortly - the patch is complete as of 12/21/08.

Final really obscure note, the OWASP WEBGOAT HTTPOnly lab is broken and does not show IE 8 Beta 2 and IE 7 with ms08-069 as complete in terms of HTTPOnly protection. However, Robert Hansens' HTTPOnly test page now includes set-cookie and set-cookie2 checks for XMLHTTPRequest exposure and should be used until OWASP fixes http://code.google.com/p/webgoat/issues/detail?id=18 .

And most importantly, I updated the OWASP HTTPOnly page to reflect this information.

OWASP Podcast #4 - Developers Guide

2009-01-20T12:03:00.000-10:00

I just finished publishing OWASP Podcast #4 - an interview with Andrew van der Stock - over the status and future of the OWASP Developers Guide.

You can check out the show notes for OWASP Podcast #4, download the mp3 file directly, subscribe to the RSS feed, or subscribe directly to iTunes.

I 'm really exited to see what Andrew does in the upcoming revision to the OWASP Developers guide. This key OWASP reference is key for all of the "builders" out there is sure to raise the bar and contribute significantly to achieve industry-wide application security excellence. :)

OWASP Podcast #3 - Live CD

2009-01-07T01:32:00.000-10:00

I just finished publishing OWASP Podcast #3 - an interview with Matt Tesauro.

Matt is the OWASP Live CD Project lead. He's also a member of the Global Project and Tools Committee. His interview is about the OWASP Live CD Project history, status and future.

You can check out the show notes for OWASP Podcast #3, download the mp3 file directly, subscribe to the RSS feed, or subscribe directly to iTunes.

I found Matt to be a very motivated and inspired quartermaster for OWASP. I'm certain he will continue to grow the OWASP Live CD project and I look forward to hearing about his progress in the near future.

OWASP Podcast #2 Securing Webgoat with ModSecurity

2008-12-29T12:40:00.000-10:00

I just finished publishing OWASP Podcast #2 - an interview with Stephen Craig Evans.

We discussed Stephen's OWASP Summer of Code Project, Securing Webgoat with Mod Security.

You can check out the show notes for OWASP Podcast #2, download the mp3 file directly, subscribe to the RSS feed, or subscribe directly to iTunes.

I found Stephen to be very interesting in his analysis of when WAF deployment is prudent. Although WAF deployment is something I personally think of as a last resort, intelligent discussion and arguments like I heard from Stephen make it tougher for me to dismiss WAF technology outright. Great job, Stephen!

HTTPOnly XMLHTTPRequest exposure update

2008-12-21T02:36:00.000-10:00

The HTTPOnly crusade grows stronger.

I have victories to report on several fronts regarding the adoption of HTTPOnly, to the point of stopping XMLHTTPRequest.getAllResponseHeaders leakage of HTTPOnly cookies.

The HTTPOnly world was rocked in the Summer of 2007 when the famous HTTPOnly test url at http://ha.ckers.org/httponly.cgi demonstrated that HTTPOnly cookies could be exposed via the JavaScript XMLHTTPRequest (XHR) object through the getAllResponseHeaders function which includes HTTP headers that contain set-cookie headers - even for HTTPOnly cookies.

So even though HTTPOnly cookies stopped JavaScript calls like document.cookie, they did not stop advanced XSS techniques like http://insanesecurity.wordpress.com/2007/08/01/httponly-vs-xmlhttprequest/

The latest and greatest browsers and standards address this issue.

First out the gate, is Internet Explorer. My HTTPOnly hat's off to Microsoft for delivering the first browser to implement defense from the HTTPOnly exposure vector described above. http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx

However, IE did NOT implement protection from set-cookie2 header exposure!! The horror!

I still declare the HTTPOnly browser war active!

Will FireFox deliver the first browser to truly implement complete HTTPOnly in a way that would make the HTTPOnly working group pleased? Could Opera, Safari or Chrome sneak in with a win?

As I mentioned in an earlier post, some of the recent editorial version of the XHR specification at w3c includes clear verbiage that prevents reading of ALL set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way. Nice!

It's the securing of these core RFC's that help make the applications and browsers of tomorrow more secure. Thanks Anne!

PS: As a HTTPOnly bonus, check out Ryan Barnett's blog post on how to add HTTPOnly protection using ModSecurity.

How to restart Tomcat properly

2008-12-16T15:16:00.000-10:00

David: hmm, i get no cancel confirmation

James: update all code

then refresh

then project-clean

sacrifice 2 chickens

reload tomcat

sacrifice a goat

then you should be ok

David: ok, i forgot the goat

OWASP Podcast #1

2008-12-15T15:47:00.001-10:00

I am very pleased to announce the inception of the OWASP Podcast series.

OWASP Podcast #1 was recorded on November 21, 2008. The guest panel includes Jeff Williams, Arshan Dabirsiaghi, Jeremiah Grossman and your host, Jim Manico.

You can download OWASP Podcast #1 here.

You can read the show notes here.

You can subscribe rss/itunes/feedburner here.

Thank you, very much, to all participants and listeners. Please pass the word!

This is only the beginning. My hope is that the OWASP podcast series serves the community well.

Enjoy!

XMLHttpRequest will be more secure in the future

2008-12-11T19:58:00.001-10:00

Some of the most recent iterations of the XHR specification at w3c (edited by Anne van Kesteren) includes excellent security choices which will lock down the JavaScript HTTPOnly edge-case exposure vectors.

The latest editorial draft of the XHR w3c spec http://dev.w3.org/2006/webapi/XMLHttpRequest/

• prevents creating set-cookie/2 headers via setRequestHeader() in a case insensitive way. (but XHR is free to send Cookie/2 headers for any existing cookie (HTTPOnly or otherwise).
• prevents reading set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way.

Excerpts from the spec:

getAllResponseHeaders(), method….
Return all the HTTP headers, excluding headers that case-insensitively match Set-Cookie or Set-Cookie2, as a single string, with each header line separated by a U+000D CR U+000A LF pair excluding the status line, and with each header name and header value separated by a U+003A COLON U+0020 SPACE pair.

setRequestHeader(header, value), method
For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers:
• Accept-Charset
• Accept-Encoding
• Authorization
• Connection
• Content-Length
• Cookie
• Cookie2
• Content-Transfer-Encoding
• Date
• Expect
• Host
• Keep-Alive
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• User-Agent
• Via

I’m excited to see this key specification move in such a secure direction!

Java and UTF-8 Shortest Form

2008-12-06T15:50:00.000-10:00

Java 6 update 11 contained an interesting change to UTF-8 handling that I think is worth noting.

Here is the original JRE bug:
4486841 UTF-8 decoder should adhere to corrigendum to Unicode 3.0.1

Here is the impact of the problem
The UTF-8 (Unicode Transformation Format-8) decoder in the Java Runtime Environment (JRE) accepts encodings that are longer than the "shortest" form. This behavior is not a vulnerability in Java SE. However, it may be leveraged to exploit systems running software that relies on the JRE UTF-8 decoder to reject non-shortest form sequences. For example, non-shortest form sequences may be decoded into illegal URIs, which may then allow files that are not otherwise accessible to be read, if the URIs are not checked following UTF-8 decoding.

The solution is to flat out reject anything other than shortest-form UTF-8 per http://unicode.org/versions/corrigendum1.html which has been around since - March 2001??

In UTF-8, <004d> is serialized as <4d>.
The problematic "non-shortest form" byte sequences in UTF-8 were those where BMP characters could be represented in more than one way. These sequences are illegal...

HttpOnly in Tomcat, almost?

2008-08-26T10:47:00.000-10:00

Ah, I saw a post from one of the Tomcat leads hinting that we might see HttpOnly support in Tomcat soon....

https://issues.apache.org/bugzilla/show_bug.cgi?id=45632

It's been 5 months since my original Tomcat HttpOnly post and patch at https://issues.apache.org/bugzilla/show_bug.cgi?id=44382

No word on Webkit/Safari. https://bugs.webkit.org/show_bug.cgi?id=10957 Also no word from Opera about complete HttpOnly protection. I'll start making more noise soon.

The HttpOnly crusade, quietly, does continue.

Input Validation with ESAPI - Very Important

2008-08-15T15:03:00.001-10:00

I just committed a new concrete class into the ESAPI core called org.owasp.esapi.ValidationErrorList.

ValidationErrorList will allow you to attempt groups of validation checks in a non blocking way.

I also added a variant of many org.owasp.esapi.Validator functions that will accept a ValidationErrorList as an argument instead of throwing a ValidaitonException. These ValidationErrorList variants will populate the ValidationErrorList with the ValidationException, hashed by the context.

To actually submit and collect errors for an entire validation group, your controller code would look something like:

ValidationErrorList() errorList = new ValidationErrorList();.
String name = getValidInput("Name", form.getName(), "SomeESAPIRegExName1", 255, false, errorList);
String address = getValidInput("Address", form.getAddress(), "SomeESAPIRegExName2", 255, false, errorList);
Integer weight = getValidInteger("Weight", form.getWeight(), 1, 1000000000, false, errorList);
Integer sortOrder = getValidInteger("Sort Order", form.getSortOrder(), -100000, +100000, false, errorList);
request.setAttribute(errorList , "ERROR_LIST");

Then later in your view layer, you would be able to display all of error messages via a helper function like:

public static ValidationErrorList getErrors() {
HttpServletRequest request = ESAPI.httpUtilities().getCurrentRequest();
ValidationErrorList errors = new ValidationErrorList();
if (request.getAttribute(Constants.ERROR_LIST) != null) {
errors = (ValidationErrorList)request.getAttribute("ERROR_LIST");
}
return errors;
}

And even check if a specific UI component is in error via calls like:

errorList.getError("Name");

Input Validation - Not That Important

2008-08-10T15:38:00.000-10:00

When I bring up almost any category of web application injection attacks, most folks in the field almost instinctively begin talking about "input validation". Sure, input validation is important when it comes to detecting certain attacks, but encoding of user-driven data (either before you present that data to another user, or before you use that data to access various services) is actually a great deal more important for truly stopping almost any class of web application injection attack.

The Java variant of ESAPI has a wide variety of encoding functions depending on the need (called easily via ESAPI.encoder()).

Some of these include:

//when user-driven data is used
//as a javascript variable
String encodeForJavascript(String input);

//used when presenting user-driven
//data inside of an HTML tag
String encodeForHTMLAttribute(String input);

//used for presenting user-driven
//data inside of an HTML body
String encodeForHTML(String input);

//used then presenting data
//as a vbscript variable
String encodeForVBScript(String input);

//used when accessing LDAP services
//with user-driven data
String encodeForLDAP(String input);
String encodeForDN(String input);

//XML centric encoding operations
String encodeForXPath(String input);
String encodeForXML(String input);
String encodeForXMLAttribute(String input);

//used when placing user-driven
//data within a url
String encodeForURL(String input) throws EncodingException;

While input validation is still crucial for a defense-in-depth application security coding practice; it's truly the encoding of user data that becomes your final and most important line of defense against XSS, SQL Injection (PreparedStements and binding of variables actually encoding user-driven data specific to each database vendor via the Java JDBC driver), LDAP injection, or any other class of injection attack.

Getting Started with Java Web Application Security

2008-06-27T12:22:00.000-10:00

Some in the WAF world have conjectured recently that web application security coding practices are difficult. I am starting to believe Jeff Williams - that secure coding practices - especially when using a toolkit like ESAPI - is actually a great deal CHEAPER and EASIER than not writing code securely in the first place.

Here is my "hit list" of coding security practices that can be easily integrated into any agile software development process:

Make sure ALL data that is user driven is run through output encoding to render (at least) XSS attacks inert – ESAPI.org has a version of that function that is good to use http://www.owasp.org/index.php/ESAPI - or just use this function http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java
Make sure ALL user data is run through strong input validation, ESAPI.org also has a strong validation set of functions that handles double-encoding protection and canonicalization - in additional to configurable regular expressions.
Look out for Session Fixation problems in Java http://www.owasp.org/index.php/Session_Fixation_in_Java
Look out for SQL injection problems in Java (All database access must be through Hibernate, or the Java PreparedStatement class with proper binding of all variables. String selectStatement = "SELECT * FROM User WHERE userId = ? ";PreparedStatement prepStmt = con.prepareStatement(selectStatement);prepStmt.setString(1, userId);ResultSet rs = prepStmt.executeQuery();
Audit access control carefully across every page. Use an access control grid to document access control across all functions and have a manger sign off on that artifact.
JSP’s should never be accessible via a public directory like www.somesite.com/program.jsp - they should always be placed in a private non-accessible directory to be accessed and streamed to the user via a servlet. JSP parameter tampering is to easy. If your development team uses emacs to edit code, make sure files like www.somesite.com/program.jsp~ are not deployed - it will give an attacker easy access to the source code
Make sure the servlet container is hardened. Here is a decent guide to Tomcat hardening http://www.owasp.org/index.php/Securing_tomcat
Remove all default, management or demo code that comes with any servlet container - it’s almost always insecure.

Coding your application securely is ALWAYS better protection than depending on a WAF.

Opera 9.5 HttpOnly Read Prevention

2008-06-15T22:37:00.000-10:00

Opera 9.50 is now available for download at http://www.opera.com.

Although the official release documentation did not mention it, Opera 9.50 does indeed include the most basic form of HttpOnly support - HttpOnly cookie read prevention. The following results are from Opera 9.50 on Vista Ultimate. I tested using the WebGoat v5.1 HttpOnly test page at /WebGoat/attack?Screen=176&menu=51.

And here are the official results:

Results:
* SUCCESS: Your browser enforced the HTTPOnly flag properly for the 'unique2u' cookie by preventing direct client side read access to this cookie.
* FAILURE: Your browser did not enforce the write protection property of the HTTPOnly flag for the 'unique2u' cookie.
* The unique2u cookie was successfully modified to se/M3Lw5Ia4cMyKIUAJrbz23Ibo= on the client side.
* FAILURE: Your browser does not prevent an XMLHTTPRequest read for the 'unique2u' cookie.

This is obviously not perfect support; we should at least see HttpOnly write prevention. Current versions of IE 6/7 and FireFox 2/3 all include both HttpOnly cookie read and write prevention per OWASP's HttpOnly browser support section.

However, this is still another victory for HttpOnly crusaders and Web Application Security. I'll be sure to post a bug on Opera's support site requesting complete support.

And don't forget to vote for the Firefox "XMLHttpRequest allows reading HTTPOnly cookies" bug at https://bugzilla.mozilla.org/show_bug.cgi?id=380418 so we can have at least one browser with complete HttpOnly support!

HttpOnly Crusade Update

2008-05-22T09:44:00.000-10:00

I would like to report 2 exciting victories regarding the ongoing HttpOnly crusade!

1) The underlying network library used for Safari - the Qt C++ library - particularly the QNetworkCookie class - has finished adding HttpOnly support! See http://trolltech.com/developer/task-tracker/index_html?id=206125&method=entry for more information on the specific bug. My undercover Safari developer resource tells me that Safari is soon to follow with full HttpOnly support in both the Windows and OSX versions!

2) The latest version of the Servlet 3.0 specification (JSR 315) has added HttpOnly support to both the Cookie and SessionCookieConfig classes. You can download the JavaDoc here. Thank you to Rajiv Mordani @ Sun!

HttpOnly is not a cure-all. It's simply one defense-In-depth measure to assist in preventing XSS session hijacking attacks. HttpOnly can also be circumvented via triggering an AJAX request via the XMLHttpRequest object and reading cookie data out of the headers. Fellow HTTPOnly crusader, Eric Bing from Oracle, is also leading the charge communicating with the w3c regarding future specifications to prevent the XMLHTTPRequest JavaScript object from accessing HttpOnly cookies! Exciting!

In other HttpOnly news:

WebLogic is testing a HttpOnly flag and is currently reviewing the patch "for feasibility".

There is a FireFox bug already addressing the circumvention of HttpOnly via XMLHttpRequest headers as described above. Please consider adding you vote to help encourage the team to lock down this HttpOnly circumvention vector: https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=380418#vote_380418

And the Crusade Continues......

ShakaCon 2008 Hawaii

2008-05-22T08:16:00.000-10:00

You now have a business-critical reason to encourage your boss to send you to Hawaii. ShakaCon 2008 (June 9th-13th) is Hawaii's only information security, IT audit, compliance and ethical hacking conference!

For the second year running, one of the most beautiful places on Earth will serve as the backdrop for this truly unique security conference experience.

ShakaCon will include a wide variety of security speakers, including an update on the OWASP ESAPI (Enterprise Security API) project on June 11th. ShakaCon will also host a 2-day Web Application Security Training course by the Aspect Security Hawaii office on June 12th and 13th.
For more information, please see http://www.shakacon.org/ or download the registration form here.

CSRF Solutions

2008-04-12T10:38:00.000-10:00

The problem: CSRF.

Jeremiah Grossman's explanation of the problem at RSA 08 :
http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgrossman-349028/

OWASP CSRF Overview:
http://www.owasp.org/index.php/CSRF

Testing for CSRF:
http://www.owasp.org/index.php/CSRFTester

Java Filter for CSRF Protection:
http://www.owasp.org/index.php/CSRF_Guard

Java ESAPI Defense:
org.owasp.esapi.HTTPUtilities.addCSRFToken(String href)

Plaform's with built-in CSRF defense:
Drupal.org

ha.ckers.org pwnd?

2008-04-07T19:04:00.000-10:00

It's strange and disheartening to see ha.ckers.org "down" this evening. I hope it's only unscheduled maintenance. I would hate to see the pwnders get pwnd!

Another interesting note: ha.ckers.org uses Wordpress? Ewwwwwwwwwwwwwwwwwww

Plaintext PCI Compliance

2008-03-30T14:49:00.001-10:00

One of the main flaws of PCI-DSS compliance requirement #4 is that it allows for plaintext transmission of credit card information within private networks. The most recent mass-credit-card heist involves my favorite east coast grocer, Hannaford. Hannaford passed a PCI audit. Even more interesting, Hannaford passed their PCI audit on Feb. 27, 2008 - 2 months after they were breached - and 3 weeks before public disclosure! Just how did this happen?

"But in Hannaford's case, the intruders were able to intercept the data at a point where it obviously was unencrypted"

- Heather Paquette, Hannaford Manager Midwest Information Risk Management

"At the time of this potential exposure, Hannaford was certified to be in compliance with the highest security standards required by the credit card industry."

- Ronald C. Hodge, Hannaford's CEO

Anytime you transmit or store credit card information - do so using industry standard strong encryption.

This seems like a no-brainer. We should have learned this lesson in InfoSec 101!

HttpOnly, Safari, Servlets and Tomcat

2008-03-27T16:42:00.000-10:00

I'm a huge fan of the benefits provided by the HttpOnly cookie flag, especially as it pertains to enhancing the security of session cookies in web applications. As we can see by Andrew van der Stock's recent blog post on HttpOnly Browser Support, almost every browser supports or will soon support the HttpOnly flag except for Safari.

Safari uses the WebKit.org open source project. And there is indeed a bug submitted for HttpOnly support in WebKit. But this bug was posted back in September 06' - whats taking so long? Unfortunately the problem is Apple. Apple is blocking WebKit from supporting HttpOnly. The CFNetwork library is the closed source Apple library that converts HTTPHeaders into objects - and the CFNetwork library does not support the HttpOnly cookie flag. Please do not hesitate to email the Apple Product Security Team to nudge them along in the right direction!

Also, I have heard rumors that the JEE Servlet Expert Group will soon agree to support the HttpOnly flag in the Servlet 3.0 specification! I'm absolutely thrilled about this. I cannot provide proof of this yet, but I am a longtime Sun contractor and have authoritative sources. This is a very encouraging development.

I've run across much resistance on my HttpOnly cookie crusade. The Tomcat team is hesitant to support this cookie flag since HttpOnly is not a standard - but I'm working on the Tomcat HttpOnly bug and am likely to get it rolled live into Tomcat once it becomes part of the standard for Servlets.

Vive la HttpOnly!

Actual Photo of Arshan Dabirsiaghi

HTTPOnly support for Apache Tomcat

2008-03-09T09:43:00.001-10:00

I've made specific suggestions to the Apache Tomcat core developer team to add HTTPOnly support to Tomcat 5.5 (for starters). The adoption is slow-going since it involves changes to three of the most core files of Tomcat.
Here is how you can get HTTPOnly support NOW while you wait for official adoption.

1) First download the Tomcat source code and be able to build the core server via ANT. See http://tomcat.apache.org/tomcat-5.5-doc/building.html for instructions. Although the link above points to Tomcat 5.5, the changes I'm suggesting below will work for any Tomcat build.

Once you have downloaded the Tomcat code and have set up your build environment, you will need to make the following changes to at least org.apache.catalina.connector.Request.java and org.apache.catalina.connector.Response.java. You could (should) also make changes to org.apache.tomcat.util.http.ServerCookie.java if you require a very scalable solution where every StringBuffer.append matters; but that addition is beyond the scope of this post.

2) org.apache.catalina.connector.Request.doGetSession(boolean create) is where the session cookie (JSESSIONID) is initially created. You are going to need to change this. This first change is at approximately loc 2321 of the file org.apache.catalina.connector.Request.java (for Tomcat 5.5).

//this is what needs to be changed //response.addCookieInternal(cookie); //this is whats newresponse.addCookieInternal(cookie, true);
}

3) In order to support the new HTTPOnly version of Response.addCookieInternal, we need to modify the functionality of org.apache.catalina.connectorResponse.addCookieInternal. The following are my suggested backward-compatible changes:

public void addCookieInternal(final Cookie cookie) {addCookieInternal(cookie, false);
}public void addCookieInternal(final Cookie cookie, boolean HTTPOnly) {
if (isCommitted()) return; final StringBuffer sb = new StringBuffer(); //web application code can receive a IllegalArgumentException //from the appendCookieValue invokation if (SecurityUtil.isPackageProtectionEnabled()) { AccessController.doPrivileged(new PrivilegedAction() { public Object run(){ ServerCookie.appendCookieValue (sb, cookie.getVersion(), cookie.getName(), cookie.getValue(), cookie.getPath(), cookie.getDomain(), cookie.getComment(), cookie.getMaxAge(), cookie.getSecure()); return null; } }); } else { ServerCookie.appendCookieValue (sb, cookie.getVersion(), cookie.getName(), cookie.getValue(), cookie.getPath(), cookie.getDomain(), cookie.getComment(), cookie.getMaxAge(), cookie.getSecure()); } //of course, we really need to modify ServerCookie //but this is the general idea if (HTTPOnly) { sb.append("; HttpOnly"); } //if we reached here, no exception, cookie is valid // the header name is Set-Cookie for both "old" and v.1 ( RFC2109 ) // RFC2965 is not supported by browsers and the Servlet spec // asks for 2109. addHeader("Set-Cookie", sb.toString()); cookies.add(cookie); }Any feedback is appreciated.

PS: For more on HTTPOnly and how it can be a part of your defense-in-depth web application security strategy, see http://msdn2.microsoft.com/en-us/library/ms533046.aspx

JQuery vs Prototype JS Libraries

2008-02-14T17:00:00.000-10:00

Here are my thoughts on JQuery vs. Prototype - I do not think either is better. It's just a tradeoff based on your needs and team.

JSQuery positives:
Easier
Better Containment
Better Chaining
More Active Community
More Active/Verbal Maintainer
Designer-centric
More concise code

JSQuery Negatives:
Memory hog
Cross-browser support is not so great
Dom centric programming (not so easy for Java folks to wrap their heads around this)
No class support or inheritance (again, odd for Java folks to wrap their head around this)

Prototype positives:
Amazing cross browser support
Low memory footprint (compared to other frameworks)
Great Object Orientation/Functional based programming (easy for Java/back end developers to jump in the game)
OO Coder-centric
More readable code
Better security awareness/responsiveness for Ajax functionality

Prototype negatives:
sizable download file
not as concise as JQuery
community not as active (at times)

Summary: Most designers prefer JSQuery. Most Java Programmers prefer Prototype. But if you would like to have your cake and eat it to, then use both, together.

It's my Vista Party and I'll cry if I want to

2008-02-10T05:34:00.000-10:00

You would cry too if it happened to you.

Last week I was handed a new Vista Ultimate(tm) machine as my primary Java development machine. Yes, I wept. I tossed and turned for nights wondering WHY WHY did this happen to me? But as a social experiment and respect for my new boss, I'm going to give it a good ol college try. So far, Java 1.5 and Eclipse installed just fine. I stripped almost every feature from Vista that I could using this very reasonable gamers tweak guide for speeding up Vista. http://www.extremetech.com/article2/0,1697,2247431,00.asp

But I hit my first wall when trying to install MySQL 5.0. MySQL MySQLInstanceConfig 5.0.51a simply does not work on any version of Vista due to some error with UAC configuration. Admittedly, it was the MySQL developers fault, not Vista. MySQL 5.0.45 is the latest version of MySQL to actually run properly on Vista as of this posting.

Charging forward with Vista laptop in hand....

Secure Agile Software Engineering with ESAPI

2008-01-29T01:09:00.000-10:00

The principles of agile development are revolutionary and have only come to full fruition as computer languages, software engineering tools and software platform paradigms have matured to the depth that we have seen in recent years. But as anyone who works in Application Security well tell you, Software Development is a combat sport and we must continually march to the drumbeat of Better, Faster, Stronger. That new frontier is developing Secure Applications with lightning speed. We are not there yet. But the dawn of the age of secure agile software development is upon us, and the weapon of choice shall be ESAPI. But with such power comes great responsibility and we must continually learn skills anew. This brief article will debunk some of the theories of agile development, but will prepare you for the battle ahead.

Some of the core aspects behind agile development is placing working iterations of applications in front of the customer in a very rapid model similar to the spiral software engineering model. This rapid turnaround (and rapid desires from the customer for change) can allow software analysts to forgo much of the design process of an application. Pre-development design documentation no longer becomes an efficient process when you are iterating so frequently with the customer.

1) Design documentation in a secure agile development life cycle is more efficient when done after the primary live delivery.

Efficiency in the agile process is fundamental. We must be empowered to not only iterate fast, but to do so in a way that is of high quality. The chief architects code and the newest members of our team must be of similar quality, and a junior coder fresh out of school will not do. There are certain lessons that only the heat of battle and years of coding will teach you. For a new recruit, a support role to the team is more appropriate.

2) Junior Programmers do not belong in the core of secure agile development teams

Simplicity is no longer an option. K.I.S.S. died the day the first programmer completed an application that was a combination of J2EE, Hibernate XML mapping, ANT and Tomcat xml configuration, Javascript, SQL, XHTML/DHTML and CSS. The applications being
asked of us web-centric agile programmers are a mesh of 7 or more different programming languages with rich client cross-browser concerns that make even the most hardened C++ programmers weep.

3) We shall expect complexity as the norm and shall build such functionality in reusable well encapsulated abstractions

Our teams are now distributed. Face to face conversations are so - 1990's. We can expect our teams to be scattered all over the world. This new generation of agile warriors will use the free tools of new media to the fullest and will appear to be in the cubical next to yours from 6000 miles away in almost ninja like fashion. The Secure Agile Programmer is an extrovert who gains great satisfaction in clear and constant communication with the customer.

4) We shall expect our teams to be global and have the capacity to maximize Instant Message, Email, VOIP, Audio Chat Rooms and other forms of net communication in a very verbose yet clear way.

Our agile developers are not cowboys, they are elite soldiers with the right tools in hand. Before a agile coder can move fast, the application architecture must be well formed. We cannot build application infrastructure on the fly. That is where ESAPI comes in. ESAPI is the only enterprise Java API that covers all aspects of secure application development. It can be injected in to
any Java architecture. It will minimize the need for security testing when used appropriately. It will save you money, time and present you with a simple and effective way to build Java applications securely from the ground up, the first time.

5) We will have a secure robust architecture in place before we begin the agile process.

All areas of secure coding are covered in ESAPI:

1) Authentication
2) User Management
3) Access Control Abstraction
4) Secure Object Reference
5) Input Validation
6) Output Encoding
7) Encryption
8) Secure HTTPUtilities
9) Random Number Generation
10) Logging with proper Security Considerations
11) Intrusion Detection
12) Secure Configuration

Game on. Join us: ESAPI.org

Logout via Javascript with OnBeforeUnload

2007-12-29T11:59:00.000-10:00

One sure fire way to protect users from CSRF attacks is to minimize the window of time that a user is logged in. Current CSRF mitigation strategies focus around the topic of adding a token to each form and link in addition to timing out the session after the the user has been inactive for a relatively short window of time.

However, any third party site than can exploit a weakness in Single Origin Policy can break though these defenses (such as the iframe SOP hack we saw in the past). In addition, the web world is moving to technologies that allow cross-site-requests on purpose, both through Flash, JavaScript and other technologies for mash-up capability.

Not all users are kind enough to explicitly press the logout link or button when they are done using your site. There are three situations that we can trap via JavaScript and force the user to logout without requiring additional action of the part of the user.

1) The user simply types in or browses to a new url in a single-tabbed environment without explicitly logging out.
2) The user closes the tab or window without choosing to press the logout link or button.
3) The user browses to a new tab while staying logged in the previous tab.

The following code sample will allow a programmer to trap events 1) and 2) reliably in IE 6/7 and Firefox 2. It's trivial to fire off the logout event especially if your logout server code will allow a GET request.

<html>
<body onbeforeunload="dothis();">

<script>
function dothis() {
alert('logmeout ajax event');
}
</script>

</body>
</html>

The third situation, when a user changes a browser tab, is much more difficult of an event to trap since it does not fire a onbeforeunload or similar event. It may also harm the user experience. Browser tab changing may not be a situation where the user actually wants to log out. None the less, to accomplish this task, you will need to work with the windows' onblur event. However, this event is very chatty. Just changing a tab will fire onblur event 5 times in Firefox 2.0. You
can play with code such as:

<script>
var logout = false;
function dothis() {
if (logout == false) {
alert('logmeout ajax event');
logout = true;
}
}
</script>

But Firefox 2 will still fire the alert 2x. You will need to test and expand upon this code for each unique browser.

Logging out via JavaScript is by no means a complete CSRF mitigation, but is an excellent defense-in-depth measure to add to your current mitigation strategy.

12 Steps To Application Security

2007-12-24T11:00:00.000-10:00

There are several holdouts in the industry who wish to trump the term "Application Security" with the term "Software Security." My Christmas wish is that we standardize on the term "Application Security" - because I think it's a more realistic term to describe the state of the industry that helps organizations design, develop, deploy, assess, maintain, retire and build procedures around Applications in a way that protects them from external and internal threats.

1) We must admit that we have a problem and that the security posture of our enterprise Applications are becoming unmanageable.

Let me start by saying that most code is insecure. This is not necessarily getting better, but seems to be getting worse.

Those of us who are professional programmers were never taught to write secure code in school. Even Michael Howard, who is hiring the best and brightest out of the worlds top universities, clearly says that these star graduates have no idea now to write a secure application.

2) We must believe that a power greater than ourselves (Application Security Service Vendors) can help us restore sanity.

It would be effective to re-write all of the worlds applications in an environment that embraces best-of-breed Application Security methodologies. But the truth is that most CIO's have several thousand applications under their responsibility, that are largely insecure. It's already built. It's already in production. We low level programmers are tasked with writing more code, faster and faster, to keep the business moving, since they depend on our work more every day. We simply do not have the luxury of time or budget to rewrite all of those applications. So we are stuck with a state of having to secure applications after the fact. This is a reality check to those in the industry who conjecture that "Software Security" is a better term because "Application Security" implies protection of software after it is built.

3) We must make a decision to turn our will and our lives over to Application Security excellence.

I also feel that the term "Software Security" is a dangerous position that both polarizes the industry and blames the coder. Software Security implies Lines Of Code. Although at the end of the day, individual lines of code need to be written using best practices (input validation, output encoding, proper access control, etc,etc,etc) it's only a small part of the entire picture. Individual coders cannot solve the problem alone.

4) We must make a fearless inventory of the security posture of our current applications.

We cannot just run Fortify, Spi, Cenzic and Watchfire and be secure. We cannot prove that an application is secure by any predicate mathematical proof. So what do we do? We (at times) slap up a WAF to stop the bleeding. We bring in pen testers, conduct code reviews and run tools for the most critical apps.

5) We must admit to a higher power (our CIO), to ourselves and to other coders the exact nature of our wrongs.

We wage political warfare in our organizations to ensure that the "C" level, the project managers, the infrastructure teams, the architects and the low-level programmers are all on the same page about Application Security. Not to mention incident response. Legal issues. Risk analysis - which really has nothing to do with software - but measures a financial impact on a business.

6) We must be entirely ready to be re-trained to remove all these defects of how we develop applications.

We re-train software engineers as quickly as possible. We start growing a dedicated internal AppSec team to conduct these reviews in-house in a more cost effective way.

7) We must humbly ask our Vendor to help us remove our shortcomings.

There are so many activities around securing an application that does not involve lines of code - and does NOT involve software - that is seems myopic to me to use the term "Software Security".

8) We must make a list of all applications that are insecure, and become willing to make amends to them all.

No tool will answer the question of the state of our Application Security posture. It takes a village - and often several villages - to even achieve measurement of our current posture! Most CIO's have "no clue" where they are today in terms of Application Security exellence.

9) We make direct amends to our insecure Applications wherever possible by fixing the underlying code, except when it would harm the organization by spending to much to do so.

It is not cost effective to spend 100$ to re-code an application that protects 10$ worth of data. We need outside help to do proper risk analysis - and that measurement needs to be a combination of not just engineering but also non-technical business expertise which has little to do with Software.

10) We continue to take inventory of the security posture of our applications and when we are wrong we promptly admit and fix it.

Depending on a vendor alone will not set you free. The best of breed vendors encourage building AppSec teams internally - the best Vendors help accelerate your organization to achieving Application Security Independence. Continuing education is a great deal cheaper than re-education. Internal penTest expertise is a great deal cheaper than bringing in a service vendor. Using the right tools effectively is a great deal more cost effective than the shotgun approach of using whatever tool was sold to your CIO. The right Vendor will help you get there fast without disrupting the organization.

11) Through continued education and studying of industry best practices, we try to embrace that philosophy in all of our day to day engineering activities.

Once we have the knowledge, we must start building all applications with security in mind and practice from the first few days of each applications conceptual birth.

12) Having had an awakening as a result of these steps, we carry this message to other engineers, and practice these principles in all our affairs as we build new applications.

Software implies the programs that run a computer.

Application implies a solution to a problem - in the enterprise we are talking about delivering data securely.

And I think those of us who use the term "Application Security" do so because it is not the software that we are trying to fix - it's the solution to a business need that we are trying to make more robust.

Hash Migration Strategies

2007-12-20T22:12:00.000-10:00

I've had several engineers ask me recently about how to migrate very large number of users from an old non-salted md5 hash to SHA-512.

I can think of 2 main strategies:

1) Rolling migration: Weaker security, stronger user experience.
a) Add a new database column to your USER table that will hold the 1024 bits necessary for SHA-512.
b) Every time a user logs in, first check to see if the SHA-512 column is empty.
c) If empty, just verify the password though the old md5 hash. If that login is successful, rehash to SHA-512 and delete the md5 column.
d) If the md5 column is not empty, verify the password via SHA-512 (preferably with per-user salts and multiple iterations of the hash)

2) Mass migration: Stronger Security, weaker user experience.
a) Email users (in blocks of 10,000) that their password will be expiring soon.
b) At login time, do the same as a rolling migration except also force the user to change their password upon successful login.
c) If a user does not change their password within a limited amount of time, lock their account and force a customer service interaction in order to re-open the account - giving that user 1 hour to change their password or be locked out again.

Input Validaton Rant

2007-12-08T13:41:00.000-10:00

When should we do input validation in J2EE applications?

I can think of 3 scenarios all with their own trade-offs.

1) "Let's just skip validation inside the application, and apply a few J2EE filters before we deploy. "

This is the solution I've been forced down in the past. I'm not a fan. It's not fair to be in a situation where the coder has the responsibility, but not so much the power. J2EE filters, while still being Java code, are external to the core app. I think of J2EE filters as part of the configuration layer; not integrated deep into the app itself.

Now, there are occasions where adding a filter (such as Eric Sheridan's CSRFGuard) is completely external to the app. The programmer never even needs to think about this kind of vulnerability if CSRFGuard is deployed. However, validation of a form element to ensure that it's a proper email address really seems like programmer responsibility to me. But adding a configuration filter like CSRFGuard to modify all forms by adding form keys really does not seem like programmer responsibility to be, but the platforms responsibility. When are we going to see work like CSRFGuard and the OWASP ESAPI project integrated deeper into J2EE, Sun?!

2) "Let's just start using Struts XML ActionForm configuration, have programmers completely skip doing any kind of validation, and have a AppSec regex professional work with our architect to set up configuration."

This has significant benefits, and I'm a fan of this methodology for big teams. But do not be lulled into a false sense to security just because you might have your input validation dialed in. Strong input validation does not protect you from security design flaws and a host of other attack vectors. But still, Struts input validation configuration at the XML level can be very powerful if done completely across the entire app. (each and every form element.) But you better have some serious regEx experience in-house, and have a regEx expert who is very much willing to take the time to learn the application as deeply as the folks who wrote it.

3) Let's do white list validation inside our controllers' dispatchers the moment we get data from the request.

This is my favorite, because I'm a manicoder.

[rant]
With the exception of Dinis Cruz, everyone in the industry is blaming the coders. http://reddevnews.com/features/article.aspx?editorialsid=2386 (Thank you, Dinis) Yes, we are often the scapegoat (baaaaaaaaah!) being asked to write code faster, cram more functionality in, and get it done before some arbitrary date passes. And we have wonderful people like Alan Paller "expressing frustration with the fact that everything on the [SANS Institute Top 20 Internet Security] vulnerability list is a result of poor coding, testing and sloppy software engineering."

Thanks Alan; but when are executives like you going to really invest the time, energy, money, training, Q/A resource and longer development cycles to truly allow us manicoders to engineer secure applications? Blaming the coder is an easy way out; Application Security policy, money and time needs to come from the top down. And this is a very tough sell when all you get out of it is insurance and assurance that is still very difficult to mathematically prove correct. If you have programmers in you org who are writing insecure code, I conjecture that we need to look at the "C-level" and see how much they truly care about this topic and take note if they are willing to commit to the cost and time necessary to win the battle of secure code.

We can't just blame the likes of Alan, even Gartner is telling the "C-level" that "developers need to take more responsibility" http://news.zdnet.co.uk/security/0,1000000189,39291194,00.htm thereby taking responsibility off the hands of the C's. Again, so unfair, when even Michael Howard at Microsoft with an almost unlimited hiring budget says that even the best and the brightest minds coming out of college have "no idea" now to write secure applications. http://searchsoftwarequality.techtarget.com/qna/0,289202,sid92_gci1283745,00.html?track=sy280&asrc=RSS_RSS-25_280

Let's kick it up another notch.

Right now, coders with security awareness are the "high priests" of software engineering groups. It does not have to be this way, but that is the truth in most organizations. AppSec knowledge is not integrated well into most organizations yet. And sadly, those coders who do have solid AppSec awareness and ability need to apply best-practice security guidelines **IN OPPOSITION TO UPPER MANAGEMENTS DESIRE TO DEPLOY CODE FAST**

If you really want to put the responsibility of AppSec into the hand of me, the coder, than we cannot depend on external configuration to lock down our apps. If you really want me to add IDS type logging deep within the bowels of my code, then you need to both empower me with training, tools and time to do so. This AppSec squeeze-play from the C-level needs to end.
[/rant]

Ok, back to input validation. I want control over my application at the absolute soonest possible situation when user input enters my code. I want to make sure strong whitelist validation is applied at the earliest point of entry into my code. I want to empower an auditor to easily dig through my code, look for every situation where we do request.getParemter and the like, and see whitelist validation applied right there and then, without having to dig through 10 other files or some elaborate platform technology to ensure proper validation is being done.

Thanks kindly for reading this far. For more information, contact Aspect Security for all of your appSec training, assurance and acceleration needs! :)

Deeper CSRF Protection

2007-10-29T08:46:00.000-10:00

It's almost impossible to truly protect against stored CSRF found on a secondary/malicious website, not to mention browser Trojans that we see in the banking industry on a regular basis. It's non trivial to protect against these problems, but here is one potential solution to deeply secure this frightful attack vector:

a) Implement form keys defense on all forms where both the key name and value is a strong random session id. (Current standard defense)
b) At time of login, inject another per-link session ID to all URL's of that page. No request can even request a copy of a form without the correct url-level session id.
c) If some code is trying to request a page/form with the wrong session id, explain to the user of the attack and log them off their session immediately.
d) Any time a new page is returned to the user, create new per-link session ids for all additional links on page.

This defense strategy would still work in a multi-tabbed enviornment. The key differentiator is that a potential attack from malicious CSRF would be detected and drop the users session immediately since there is an obvious compromise or poor surfing habits.

I want Cake, but please make it Light (as in Lightppd)

2007-10-18T11:33:00.001-10:00

What a great post from Brendon Crawford (working on the woefully insecure PHP language) showing how to get CakePHP 1.1x running on Lighttpd. The woosies at CakePHP rejected his excellent patches for "IP reasons", so sad.

Anyhow, here we go!

http://thefaultandfracture.blogspot.com/2007/10/enabling-cakephp-11-on-lighttpd-15.html

Java Snob Laughter

2007-10-13T09:23:00.000-10:00

Yes, I'm a serious Java snob who has spent way to much time working with PHP. I've tried hard to artfully describe my disdain for PHP, and I would like to thank the people at http://tnx.nl/php for helping describe my feelings in my favorite art medium: inspirational posters! :)

Reflective XSS protection, output encoding

2007-10-04T17:03:00.001-10:00

UPDATE: The best XSS defense strategy is described here:

http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

***

Thanks to Eric Sheridan over at OWASP for fielding our "battle of the output encoding method for reflective XSS Protection" competition today! All commentary below is from Eric via email on 10/4/07.

>>1) Output encoding try 1 (Jim)

""

Although it is not frequently mentioned, URL encoding will prevent reflected XSS attacks. The browser will not interpret URL encoded values. It looks as though this approach is sufficient for this particular instance. However, I'd recommend you use HTML entity encoding instead. Aside from addressing XSS, entity encoding will fix that 'ugliness' problem that you mentioned.

>>2) Output encoding try 2 (Brendon)


badChars = [ "<", ">", "#", "&", "'", "\"" , "%", "\\" ];
entities = [ "<", ">", "&", "'", "*", "%",
"\" ];

word = "some bad xss phrase goes here";
out = "";
i = 0;
while(i < ordinal =" toAscii(word{i});" killbadchar =" false;" j =" 0;" ordinal ="="="" killbadchar =" entities[j];"> 126) {
    out .= " ";
    i++;
   }
   else {
    out .= word{i};
    i++;
   }
}

print( out );

Eck, rough looking pseudo-code :)

If I were doing a security review and I saw some code like this used to prevent XSS, I would mark it as a finding (albeit low, for the moment). This is a 'negative' or 'blacklist' approach - the developer is rejecting known 'bad' characters rather than accepting known 'good' characters. Guys like RSnake (http://ha.ckers.org) spent their entire career bypassing such blacklist filters. Don't get me wrong, this method will prove effective in a lot of scenarios. Unfortunately, there are going to be special cases where this particular method fails. Consider the case when user supplied data lands within a JavaScript tag. Example:


<script language="JavaScript">
var a = ;
</script>

In this particular example, the proof-of-concept would look like "a; alert(document.cookie); var b=" (without the quotes). A real attack vector would have to do quite a bit of obfuscation, but a determined individual will find a way (see 'Myspace Worm').

If you are looking for a good output encoding example, check out

http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java

This method follows a 'positive security model'. It only accepts the known good values and entity-encodes all of the rest. I think the method is so simple that it can be easily ported to any language. I'd recommend you use this method in place of the two output encoding attempts listed below. Also, if your validation routines detect someone trying to enter malicious javascript, I'd highly consider logging the event as a "security event". Hope this helps!

-Eric

Secure Coding Smartie

2007-10-02T12:58:00.000-10:00

"Product teams don't get better by reading secure coding standards. They get better by working with security testers, seeing how their code gets broken by attackers, and learning from the experience. Before we expect software companies to ship better products, we need to see a top-down commitment to security, just like we saw at Microsoft. Everyone from the board room down to the QA team needs to agree that security trumps feature sets and release schedules."

- Thomas Ptacek, principal with Matasano Security.

Who would have predicted that Microsoft would become the poster-child for secure application development practices?

JavaScript debugging in IE 6/7

2007-10-02T09:59:00.001-10:00

Thank you Brendon Crawford for this excellent summary:

After thoroughly testing and trying about 9 or 10 different products, I have come up with the definitive must have list for debugging and developing in IE. These are all free BTW:

1) CSS/HTML inspecting - Microsoft Internet Explorer Developer Toolbar (Free)
2) AJAX/HTTP Inspecting - Fiddler (Free)
3) Javascript debugging - Microsoft Office XP Script Editor (Free if you have Office)

And here are the tools to avoid (too costly, difficult to use, lacking features, lacking stability, or unnecesarily complicated)

1) Microsoft Ajax View
2) Firebug Lite
3) CSSVista
4) DebugBar
5) DebugBar/CompanionJS
6) Microsoft Script Debugger
7) IE Watch
8) DocMon
9) IE WebDeveloper V2

IED and WebAppSecurity

2007-10-01T15:20:00.000-10:00

When reading this article about how the US Military is struggling to defeat IED's - I could not help but think of this topic parallels to how difficult of a time we are having in terms of Web App Security.

http://www.msnbc.msn.com/id/21053750/

Java Applet Security?

2007-09-27T10:40:00.001-10:00

With so many Java applets vulnerabilities, it's tough not to poke at Java applet security. But what about the real world? Are we seeing any real attacks against enterprise applets? And how good is applet security when compared to ajax/javascript web sites that we see today?

"I'm always surprised how far people will go to ding Sun/Java security, when there are so many other targets that are so much worse it's not even really the same thing." - Jeff Williams

Well here's one for the applet side...

http://www.cio.com/article/141151/Sun_Changes_Java_Updates_Following_Criticism

Web Development Time Breakdown

2007-09-04T10:53:00.001-10:00

What a brilliant piece of web-development wisdom! This one made me laugh out loud...

Web Application Security Scanners

2007-08-18T14:19:00.001-10:00

Jeff Williams over at OWASP (Chairman) / Aspect Security (CEO) posted a very insightful monologue about the State of Web Application Security Scanners to several of the OWASP eLists, and I thought it was so crucial to those of us who care about Web App Security that I placed a copy at http://www.owasp.org/index.php/Web_Application_Scanning.

The takeaway from this is that you just cannot buy a web app scanner from one of the big three (spi, cenzic, watchfire) and use that as the foundation to your application security process. Web app security scanners do not pick up a large class of errors including business logic, access control and deeper application security problems that are not easily exposed from the endpoints. For that you need manual review by an expert, and architectural review by an expert.

Security Awareness

2007-08-18T02:38:00.000-10:00

It's my belief that you cannot write a secure application without security awareness deeply rooted within the minds, souls and software development life-cycle practices of your software developers.

If you are trying to go from a developer team that contains no awareness to total developer security awareness and practices, the cost is prohibitive. But if security awareness training for developers becomes a regular part of your software development life cycle, the cost to train goes down dramatically over time. Continuing education is cheaper than full blown re-training.

- Jim