VOOZH about

URL: https://manicode.blogspot.com/

⇱ Manicode

skip to main | skip to sidebar

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: 



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            



 



"

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.


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












 

 








Subscribe to:
Posts (Atom)