Monday, July 14, 2014

OWASP Top Ten Proactive Controls

Jim Bird (jimbird@shaw.ca) just completed a 10-post blog series on the various OWASP Top Ten Proactive Controls. These articles have been cross-posted up on DZone and Java Code Geeks. Two of the posts (on logging, surprisingly, and on including security in requirements) have made "Big Links" on DZone so far and have been syndicated. The posts have already reached a couple of thousand developers and growing, so that's a good thing!

Here are the complete set of links:

Parameterize Database Queries
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-to-make-your-app.html

Encoding Data
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-to-make-your-app_9.html

Validate Input
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-to-make-your-app_11.html

Access Control
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-to-make-your-app_16.html

Authentication Controls
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-as-developer-to.html

Protect Data and Privacy
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-as-developer-to_23.html

Logging and Intrusion Detection
http://swreflections.blogspot.ca/2014/06/10-things-you-can-do-as-developer-to_30.html

Secure Frameworks: Leverage other people's code (Carefully)
http://swreflections.blogspot.ca/2014/07/10-things-you-can-do-as-developer-to.html

Start with Requirements:
http://swreflections.blogspot.ca/2014/07/10-things-you-can-do-as-developer-to_7.html

Design Security In:
http://swreflections.blogspot.ca/2014/07/10-things-you-can-do-to-as-developer-to.html


Great work, Jim Bird!
Aloha,
Jim Manico

Friday, December 13, 2013

Reflections on Password Complexity

Michael Coates started an interesting thread on the OWASP Leaders list about password policy complexity guidance. http://lists.owasp.org/pipermail/owasp-leaders/2013-December/010492.html

I think that password policy overall is a failure and we indeed need to update our guidance on this topic.

Password length is the most important mathematical aspect to password policy, so passphrases seem like a good idea. But if your passphrase is a known sentence from a book, or just a collection of dictionary words - then the benefit decreases significantly. Here are some interesting articles that discuss this problem to some degree from the perspective of offline password cracking.

http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/
http://dashburst.com/bible-hackers-password-cracking/
https://bitcointalk.org/index.php?topic=85862.25;wap2

Jeffrey Walton suggested to me that one of the most important aspects to a good password policy is to not allow users to use commonly used passwords; even passwords that fit your corporate password policy. For example, the password Password1! probably would be accepted by most corporate password policies, but it's a dangerously bad and commonly used password. Hackers conduct "reverse brute force attacks" where they take a commonly used but supposedly strong password, and make one attempt against a large list of accounts. This and other reasons have prompted some banks to enforce strong policies on usernames!

I feel like the use of Password Managers is one of the key aspects to secure user password management. I know of several mid-size companies who have or are starting to enforce their use. Bob Lord, the Director of Security at Twitter, has led the charge of enforcing this on the entire Twitter staff. I think this move is a big win for Twitters internal security. 

http://news.softpedia.com/news/Hack-in-the-Box-13-Twitter-s-Bob-Lord-Forces-New-Employees-to-Use-Password-Managers-344699.shtml

Last, any password advice needs to push multi-factor. Poorly misquoting John Steven (as well as taking his quote out of context), "Using passwords to protect your account will help you as much as motorcycle helmets will protect you at high speed."

Monday, January 14, 2013

SecAppDev 2013, 4-8 March, Leuven, Belgium

Dear all,

We are pleased to announce SecAppDev Leuven 2013, an intensive one-week course in secure application development. The course is organized by secappdev.org, a non-profit organization that aims to broaden security awareness in the development community and advance secure software engineering practices. The course is a joint initiative with KU Leuven and Solvay Brussels School of Economics and Management.

SecAppDev 2013 is the 9th edition of our widely acclaimed course, attended by an international audience from a broad range of industries including financial services, telecom, consumer electronics and media and taught by leading software security experts including
  • Prof. dr. ir. Bart Preneel who heads COSIC, the renowned crypto lab. 
  • Ken van Wyk, co-founder of the CERT Coordination Center and widely acclaimed author and lecturer. 
  • Dr. Steven Murdoch of the University of Cambridge Computer Laboratory's security group, well known for his research in anonymity and banking system security. 
  • Jim Manico, an OWASP board member. 
  • John Steven, a sought-after architect for high-performance, scalable JEE systems. 
When we ran our first annual course in 2005, emphasis was on awareness and security basics, but as the field matured and a thriving security training market developed, we felt it was not appropriate to compete as a non-profit organization. Our focus has hence shifted to providing a platform for leading-edge and experimental material from thought leaders in academia and industry. We look toward academics to provide research results that are ready to break into the mainstream and attract people with an industrial background to try out new content and formats.

The course takes place from March 4th to 8th in the Faculty Club, Leuven, Belgium.

For more information visit the web site: http://secappdev.org.

  • Places are limited, so do not delay registering to avoid disappointment.
  • Registration is on a first-come, first-served basis.
  • A 25% discount is available for Early Bird registration until January 15th.
  • Alumni, public servants and independents receive a 50% discount.

I hope that we will be able to welcome you or your colleagues to our course.

Kind regards,

Lieven
-- Lieven Desmet
http://secappdev.org

Friday, January 4, 2013

Handling Untrusted JSON Safely

JSON (JavaScript Object Notation) is quickly becoming the de-facto way to transport structured text data over the Web, a job also performed by XML. JSON is a limited subset of the object literal notation inherent to JavaScript, so you can think of JSON as just a part of the JavaScript language. As a limited subset of JavaScript object notation, JSON objects can represent simple name-value pairs as well as lists of values.

BUT with JSON comes JavaScript and with JavaScript comes the potential for JavaScript Injection, the most critical type of Cross Site Scripting (XSS).

Just like XML, JSON data needs to be parsed to be utilized in software. The two major locations within a Web application architecture where JSON needs to be parsed are in the browser client-side and in application code on the server.

Parsing JSON can be a dangerous procedure if the JSON text contains untrusted data. For example, if you parse untrusted JSON in a browser using the JavaScript "eval" function, and the untrusted JSON text itself contains JavaScript code itself, the code will execute during parse time.

From http://www.json.org/js.html
"To convert a JSON text into an object, you can use the eval() function. eval() invokes the JavaScript compiler. Since JSON is a proper subset of JavaScript, the compiler will correctly parse the text and produce an object structure. The text must be wrapped in parens to avoid tripping on an ambiguity in JavaScript's syntax.
var myObject = eval('(' + myJSONtext + ')'); 
The eval function is very fast. However, it can compile and execute any JavaScript program, so there can be security issues."
So, the essential question is: How can programmers and applications parse untrusted JSON safely?

Parsing JSON safely, Client Side

The most common safe way to parse JSON safely in a modern browser is to utilize the JSON.parse method inherent to JavaScript. Here is a good reference that describes the state of JSON.parse browser support. And for legacy browsers that do not support native JSON parsing, there is always Douglas Crockfords JSON parsing library for legacy browsers.

Parsing JSON in the browser is often the result of an asynchronous request returning JSON to the browser. Another technique that is becoming more common is to embed JSON directly in a Web page server side, and then to parse and render that JSON in the browser. The mechanism of embedding JSON safely in a Web page is described here:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233.1_-_HTML_escape_JSON_values_in_an_HTML_context_and_read_the_data_with_JSON.parse

Step 1 includes embedded JSON on a web page safely through HTML Entity Encoding:

<span style="display:none" id="init_data">
    <%= data.to_json %>  <-- data is HTML escaped -->
 </span>

Step 2 and 3 includes decoding the JSON data and then parsing it safely.

 <script>
    // unescapes the content of the span
    var jsonText = document.getElementById('init_data').innerHTML;
    // parse untrusted JSON safely
    var initData = JSON.parse(jsonText);
 </script>

Parsing JSON safely, Server Side

It's important to use a formal JSON parser when handling untrusted JSON on the server. For example, Java Programmers can utilize the OWASP JSON Sanitizer for Java. The OWASP JSON Sanitizer project aspires to accomplish the following goals.
"Given JSON-like content, converts it to valid JSON. 
This can be attached at either end of a data-pipeline to help satisfy Postel's principle: 
Be conservative in what you do, be liberal in what you accept from others            
Applied to JSON-like content from others, it will produce well-formed JSON that should satisfy any parser you use. 
Applied to your output before you send, it will coerce minor mistakes in encoding and make it easier to embed your JSON in HTML and XML."
The OWASP JSON Sanitizer project was created by and is maintained by Mike Samuel, an esteemed member of the Google Application Security Team. For more information on the OWASP JSON Sanitizer, please visit the OWASP JSON Sanitizer Google Code page.


I hope this article helps you on your way to safer parsing of JSON in your applications. Please drop me a line if you have any questions at jim@owasp.org.



Jim Manico is the VP of Security Architecture for WhiteHat Security, a web security firm. Jim is also a board member for the OWASP foundation where he manages and participates in several projects.




Sunday, February 13, 2011

Taming the Beast

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();
}

Sunday, January 9, 2011

Touchpoints and BSIMM hurt AppSec

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.

Wednesday, June 30, 2010

Injection-safe templating languages

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.

Tuesday, March 30, 2010

Shure SM-7B

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

Thursday, January 21, 2010

How bad is it?

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....

Wednesday, December 23, 2009

If I were cyberczar

(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.

Sunday, November 22, 2009

OWASP Top 5 rc1 released!

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! :)



Saturday, November 14, 2009

Hardware Security

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.

Monday, August 17, 2009

justifying the focus on insider threat

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

Sunday, August 9, 2009

When to use OWASP AntiSamy?

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

Saturday, August 8, 2009

Real world cookie length limits

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);
}

Saturday, July 18, 2009

Open letter to the Struts 1.x team on AUTOCOMPLETE

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

Sunday, June 28, 2009

ESAPI Logging

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


Thursday, June 25, 2009

One file to secure them all

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}$