Tag Archives: owasp

contrast security plugin for eclipse

Posted on by
1

I recently learned that Contrast Security has a free plugin that tests your application against the OWASP Top 10.  We’ve tried to fix these already. You can read about how we fixed Clickjacking, CSRF and XSS in JForum.

Installing

I started out by installing the Contrast plugin from the Eclipse Marketplace. After restarting Eclipse, a Contrast view automatically opens with instructions. It says to right click your server and choose “Start with Contrast.” Easy enough. I usually use Sysdeo so I can start the server in one click, but this is hardly onerous.

A Diversion: Fixing Tomcat Configuration

I got an error on startup. I then tried to start the server using the server view (without Contrast) and got the same NoSuchMethodError:

java.lang.NoSuchMethodError: sun.security.ec.NamedCurve.<init>(Ljava/lang/String;Ljava/lang/String;Ljava/security/spec/EllipticCurve;Ljava/security/spec/ECPoint;Ljava/math/BigInteger;I)V

I fixed this by switching Tomcat 7 to use Java 7 instead of Java 8. (We aren’t using Java 8 yet for CodeRanch’s JForum software so this is fine.)

  • Workspace preference
  • Server
  • Runtime Environments
  • Click Tomcat and edit
  • Choose Java 7 as JRE

This had nothing to do with Contrast. I hadn’t encountered it because I was using Sysdeo to start Tomcat before this.

Actually testing

Now that the server starts up, I stopped it and restarted with Contrast. Then I clicked around the app a bit. (You can use Selenium tests or any other testing tool to automate this part.) The Contrast view starts to populate with its findings. I clicked around until I had about a dozen findings. They were:

Category Issue # Instances Details My analysis
Orange Insecure hash algorithms in XXX 3 Provides an explanation of what the problem is, why it might/might not be a problem along with the stack trace (showing how it is used) and the HTTP request/headers for the request(s) that triggered it. Two of the three findings refer to the exact same line of code. (Which was run on two different screens). The other appears to be in Tomcat itself. My configuration isn’t the same as the real server here. [The other two I need to look into further]
Yellow Anti-Caching Controls Missing in XXXX 6 Provides the HTTP request/headers, suggested remediation It’s annoying to have this reported on every page. Glad there is an :ignore this rule” option. We run a public website and want things to be cached. Client side caching makes the site faster for users and doesn’t leak information since 90% of our information is public to begin with. The only risk is if a moderator access the private forum on a public computer. We are technical users and know to clear data if this happens.
Yellow Forms without autocomplete prevention 3 Provides the HTTP request/headers, suggested remediation Again, we are a public site so not a big deal for browsers to retain information.
Warning CVE(s) in commons-httpclient-3-1.jar 1 Provides links to the two CVEs along with the manifest of the vulnerable library. I knew this from running Sonatype CLM Insight. The two CVEs are in functionality in the library that we don’t use. Still it is sweet to have this information available for free and with almost no effort. (Insight is a commercial project. We saw a one time result from the report.) I was concerned that information about the jars was being sent over the internet so I asked on Twitter. Jeff Williams replied that the CVE information is in a built in database updated via Eclipse Marketplace. Neat!

What to do with the results

When right clicking on any finding, you have four options:

  • Mark Resolved
  • Delete
  • Ignore (this instance) – useful for a false positive
  • Ignore rule – useful for a rule that doesn’t apply

My thoughts on the Contrast plugin

  • I like that the stack trace is included because it is easy to see context. I also like that lines belonging to the app is in blue in the stack trace.
  • It was very easy to use. And free. Which makes using it a no brainer.
  • While there aren’t false positives from unused code, there are false positives from context (which a tool can’t know).
  • Two of the rules triggered on a number of pages. (and would have triggered on a lot if I tested more)
  • While I don’t have a long list of things to follow up, it was a good thought exercise. And the reason I don’t have a long list is because we manually went through the OWASP top 10 in preparation for the “Iron Clad Java” promo recently. (so as not to have embarrassing issues pointed out)

blogging from owasp security meetup

Posted on by
Reply

The NYC Cyber Security meetup had Jeff Williams as a speaker.  He’s really good so I decided to go and blog about it.  All three sessions were really good!  Which sets good expectations for the Appsec USA conference which I’m thinking about attending in November.

Before we move on to security – a bit of humor.  I asked where the ladies room was and an employee pointed at what appeared to be the elevator bank.  On the end was a door with the word “womens” on it.  It looked just like the wall.  Camouflage!
Jeff Williams from Aspect – Is OWASP the New Rainbow Series?
Jeff is a very dynamic speaker so this was fun.
Rainbow series and security models
  • The Rainbow Series is colored pamphlets/thin docs.   Stopped printing due to internet.  Community evaporated and group folded. Info still holds – access control, encryption, etc. nobody shepherded knowledge over tech gap.
  • Security IMPLIES a model –  what does security mean?  Possibilities include: policy, no high exploitable vulnerabilities, standards, compliance , your tool’s ruleset, what pen tester interested in, whatever just got hacked (reactive). Need a model to say secure. Compliance is what others care about.  It’s like delegating your security model to someone else.
  • Rainbow had positive view – assurance world.  said controls must be analyzable – must know if good. Completeness, patterns, policy, etc.
  • OWASP uses a negative model. Top 10 is what thou shalt not do. Negative model is harder, but ok.   Current world is negative and risk based. Assume ok until prrove otherwise.
  • Goal – rational, defensible, confidence that our apps are “secure” – id important threats, strong defense for each, implement correctly and evidence defenses are working
Coverage
  • Code coverage – Static analysis tools only look at your custom code. They don’t look at libraries, frameworks, app server and runtime.  Only a small percent covered.  On the dynamic side we hit all te layers but only part of the app. 25-30% is typical.
  • Weakness coverage – NSA has a test suite called Juliet. You run static analysis against it to see how good the tool is. Found 80% failing test and more than 60% false alarms.   And Juliet is less complex than code real apps would have.
  • Portfolio coverage- most apps unreviewed because not critical. A small percent are scanned/penetration test.  And an even smaller portion get manual code review
Aspect Top 10 
  • Jeff hates top ten lists  Negative, incomplete (for example: clickjacking not in top 10), abstract (all of session management in one item), arbitrary, retrospective. Not a good model.   [This is sort of in jest as he does find them better not thing; it’s more frustration that we haven’t moved on]
  • Was needed in 2002.  Goal was to set a bar so can keep raising bar.   That didn’t happen. First top 10 was forward looking. Then started relying more on data and people doing reviews.  This is a problem. Because auditors behind casual hackers and way behind organized chrime and espionage. Compare to the crypto community who looks at what the threat will be in 10 years.  Better capability,better tools.
  • Owasp top 10 is most widely used project at owasp.  Failure because nothing has changed.  Also biggest success because raised awareness.
  • Security efforts and tools focused on apps of 2005. Not ajax, sockets, gwt, html 5, inversion of control, aop
A9 in top 10 – using components with known vulnerabilities  
  • New to the top 10.  (In case you are wondering, nothing got removed.  Insecure cryptography and insecure transport layer got merged.)
  • Reddit quote:  “One of the vulnerabilities is having known vulnerabilities”
  • The amount of custom code in our apps hasn’t changed much in 10 years. Amount of library code growing quickly. Now 80% library code. Hudson core has 103 open source library.  You are trusting ALL that code on your machine.   Dependency resolution brings in other dependencies so don’t know what using.
  • One single vulnerability (cve-2010-1622) on spring beans tainted 1447 projects!
  • Developers don’t update libraries in general. Sometimes not using that part of project. Some bad like spring EL injection policies
  • 2313 organizations using esapi and it is built into cold fusion
  • Rougly 26% libraries are vulnerable.
  • Maven can list what libraries using
 What to do
  • Focus on soeed and scale. If need an expert for technique or tool, introduces feedback lag and cant scale. Looks good for one app.  Which causes pressur to compromise on scope and accuracy to increase throughout.   Better to use experts to id threats, build automated tests, create rules, strategy, etc.   security HAS to work in parallel.
  • See if can embed sensors in app and report back data about security. Instrument code and organization so it feeds you info. Think big data.
  Panel – from Morgan Stanley – the hosts (I confirmed with the moderator from Morgan Stanley that it is ok to blog)
Securing the enterprise – what means to you
  • Protect developers from selves. Not have to think too much about what take off shelf and put in app
  • The enterprise used to be a building when gates, guards and guns were data security because thats where the data was.
  • Now have to worry about employees sending stuff out ,  not just attackers coming in.   Threat landscape changes, tech advances quickly. If rush and hurry, can roll out globally in 12-18 months
 What would you do if owasp releases new findings?
  • New data – threat intelligence – can mitigate, detect or respond with technologies in house. Big enough to have a team of people will full time jobs focused on this.
  • Financial industry grouos to share info. Move in a pack. Exchange info.
  • In small company with 20-30 apps can have one guy look at it. hTis doesnt scale to 20,000. Need to know what apps and people permitted on network
Thoughts on mailing plaintext passwords
  • Finanical sector means saving for 7 years in an archive.  Authentication and sso – have internal docs for developers so get this right so doesn’t happen.
  • Importance of keeping your personal email account secure.
  • Different passwords for all sites, password management system. Beyond what the average person will do. Need to hold system accountable. Shouldnt be able to email password to user.  [I’m surprised nobody mentioned two factor for email – I use that for gmail.
  • Need to give vendors feedback so can improve
  • Discussion on standard self declaration of password handling practice.   Another panelist refuted because additional intelligence – “if they know that, they wouldn’t be emailing you your password”. Don’t want it to be a hitlist when a vulnerability comes out.
  • Jeff Williams from audience said likes idea of making model public.  Morgan Stanley folks cringed. View as challenge or a boast. Jeff said make public internally.   Financial sector – you know what minimum standards are. For internet sites, don’t know threshold. Only held to FTC 15 years of supervision after breech.
Is data the thing that enables us to move into the future?
  • Data has always been at the core. After a breech, one of the first questions is what did they get.
  • Libraries should have an end of life or expiration date so doesn’t last with vulnerabilities forever.
  • Ability to process the data is catching up.  Easier to find the holes. And what went thru that hole
  • From vendors – need better metrics and inteligence. Currently get more graphics not intelligence
  • Can get badge saying ran automated scanning tool against site
Standards
  • New perimeter – bring your own device (BYOD) – access corporate intranet from whatever device
  • No such thing as a perimeter any more.   Or more perimeters on the inside. Not dead. Can’t just trust the inside. Contain breech. Compartmentalize.
  • Bring your own tech – bringing network connections too – Starbucks is in your enterprise
  • What enterprise thinks it can control will shrink – byod, cloud, paas, saas
  • If 20 person company, have a lot more control
  • On the AP Twitter hack (white house bomb false story.)  It affected the market because some high frequency trading was keyed into twitter.  This is the danger of being first and fastest.  Corners cut.  Want to know about twitter but not automated based on it.  Is Twitter in your security perimeter?
  • Cant just have tech. Need policies to back up. So can enforce and prosecute. Need management support
  • Wouldn’t consider having just 1 isp. If all 5 isps under siege, trading is the least of your problems. Extreme resiliency
  • Wouldn’t care if password policy published. Not a surprise because know vague idea in finance. Thousands of people. Every year. Assume info is out there. And give info to suppliers for confidence
 Tom Brennan -Trustware global security report
The report contains a collection of interesting stats.  You can read the report online (or at least last year’s version; see the resources section below for the link).
  • They focus on monetary loss.
  • Top victims – us, australia, canada, uk, brazil
  • Top attackers – romania, us, unknown, ukraine, china
  • Websites and email most utilized vector
  • Mobile malware on the rise
  • Breach quadrilateral – propagation, aggregation, exfiltraton, (how get data out of environment) and infiltration. – much emphasis on perimeter but not propagation. Once gets in, need to be able to stop. If can stop any phases, you beat the bad guy
  • 82% of apps they looked at have xss and 72% csrf. Wow. I shouldn’t be surprised.  CodeRanch only fixed CSRF (read about how) this year.
  • What  to do: Train developers, Review code, Test a lot, Protect in real time and patch

Mobile

  • Mobile malware up 400% last year. Top findings are insufficient cache controls, replay attacks on sensitive transactions, sensitive info in server response.
  • Use case: Malicious game sends hidden sms messages. Similarly can use receiving hidden sms to launch botnet
  • Apple did better job than android.  Android kitered with malware
  • Can’t patch. With byod, phone not owned by company
Spam
  • Spam down to 2007 levels but nearly 7% of spam links to a malicious website.
  • Still 75% ompanies email is spam

Passwords

  • Weakest links are employees and users
  • Password1 is 38% of top 25 password
  • Lot of passwords are top child and dog names for reset questions
  • Peak password length is 8 characters because default active directory minimum length
Six security pursuits
  • visualize events
  • unify activity logs
  • register assets
  • educate employees
  • identify users
  • protect data
Problem: Businesses focus on making money in version 1 and security in version 2. And then forget about version 2
Resources
I learned about the following at the event:

csrf for JForum without javascript

Posted on by
Reply

In February, I wrote a three part series on how we fixed JForum on coderanch to protect from CSRF.  In included;

  1. Analysis
  2. Extending OWASP
  3. Problems

Remaining problems

Unfortunately, there were three remaining problems.

  1. Some mobile devices weren’t able to handle the JavaScript which added the tokens.  Meaning our site didn’t work on all mobile devices.
  2. The CSRF token was in the URL of thread links which meant people were sharing those links with tokens in them.  This isn’t a significant security risk, but it does confuse Google which is bad for SEO.  It is a tiny security risk in that if someone posts their current CSRF token, that user can be targeted for a CSRF attack until that token expires.
  3. Some people take a really long time to write a post or have lunch in the middle and the token expires.  Giving them a CSRF error page when they finally finish.

This blog post shows how we solved these problems.

Ending requirement for JavaScript to set CSRF token and getting token out of URLS

In general, there are three options for setting a CSRF token in forums/URLs: JavaScript, a filter to change the HTML at runtime before it gets served to the client or hard coding the token.

Based on our experience with mobile devices, we decided not to go with option1 (JavaScript.)  I had used a technique similar to option 2 (changing the HTML as it goes by) to transform our JForum URLs to a different format.  This turned out to be more complex on a forum where users routinely post code.  The same problem would occur here so I decided against that option.  We don’t want to be adding CSRF tokens to code user’s post in questions.  And we certainly don’t want someone to be able to inject a CSRF attack in a post!

This left me with option 3 – hard coding the token.  There were a few steps to implementing this option:

  1. The JavaScript solution added the token to URLs in addition to forms.  This wasn’t “good” in the first place in that URLs shouldn’t be changing database state.  I had recognized this as a shortcoming back in February but lacked the time to fix it then.  There’s a representative list of these pages/URLs on github.  Many were fixed by a one to one conversion of links to forms. (with POST as the method.)  A few were fixed with a generic form on the page and JavaScript that calls it.  We used the generic JavaScript form for some admin links to save bandwidth. Most of these aren’t available in the mobile view anyway.  And moderators weren’t the ones having JavaScript issues in the first place – probably because we have newer mobile devices. 
    </span></span>function submitActionForForum(actionVerb, forumId) {
var action = document.actionForm.action;

action = action.replace("ACTION", actionVerb);

action = action.replace("FORUM_ID", forumId);

document.actionForm.action = action;

document.actionForm.submit();

}
  2. At this point we don’t need to add tokens to anchors.
  3. Remove AddJavaScriptServletFilter and JavaScriptServlet so tokens are no longer generated by JavaScript.
  4. Add token to all forms: 
    <input type="hidden" name="OWASP_CSRFTOKEN" value="${OWASP_CSRFTOKEN!""}" />
  5. For forms containing multipart/form-data (there were less than 10 of these), add to the URL:(this is needed because the multipart request is only parsed once – later on in the process and the parameter isn’t available to us in the filter) 
    ?OWASP_CSRFTOKEN=${OWASP_CSRFTOKEN!""}
  6. In parallel to the previous two steps, I wrote a unit test to ensure I didn’t miss any required tokens AND to alert anyone adding a form to the codebase in the future about the need to add a token.  Unit test available on github.
The other problem – session timeouts
My first thought was to use AJAX to keep the session active as long as the browser is open.  This session isn’t ideal as some users keep their browser open all day.  I talked to the site owner and we agreed on a three hour timeout for CSRF tokens based on inactivity.  (This also has the advantage of the token surviving a server restart which we do for deployments.)
I implemented by creating a database table with the user id and token.  I have a TimerTask that deletes any tokens over three hours old and runs every 15 minutes.  (This isn’t strictly accurate as it keeps the token alive as long as the user session or the token is less than 3 hours old.  So if I have an active session for 2 hours 55 minutes and a server restart happens, I lose my token.  This implementation may change if it turns out to be a problem in reality.  The current filter and helper class are now online for reference.
What I learned
It’s a lot harder to protect against CSRF on a public website than one with controlled users.  This was an interesting project though.