java tools for dependencies and build (ant vs maven)

Posted on by
2

A student at the robotics program I mentor emailed me the following question.  Since it isn’t specific to him, I decided to answer in a blog post.

As a developer, what tools does Java have to help me manage things like dependencies and building the project? For example, Python has pip and Ruby has gem+bundler, for managing dependencies.

Can you extol the virtues of Maven and ant? Why should I use one over the other? My research leads me to believe Maven supersedes ant. Are there any other alternatives? And if you prefer one, what makes it valuable to you?

Ant and Maven are the most common build tools in the Java world.  I’ve used both.  Gradle is a third that I’ve heard a lot about.  I haven’t used Gradle, but it looks cool.  The benefits of Maven, but the Groovy language.  Maven and Gradle are actually  both a build and dependency tool.  Ant is just a build tool.  You can use Ant without any dependency management tool/repository.  Or you can use Artifactory or Ivy with Ant.

Maven came after Ant, but didn’t supersede Ant.  Both have their purposes.   We use Ant at CodeRanch to:

  1. Build the forum software 
  2. Generate the book promotion documents every week

Ant serves these purposes very well to this day.  The latest release of Ant was in the past 6 months; it is far from a dead project.  The strengths of Ant include:

  1. Ant works better when internet availability is unpredictable or very slow.   With Ant, you have complete control over when and which jars are downloaded.  (To be fair, you can work with Maven in offline mode once you have the jars locally.  But there are a lot more dependencies and therefore more to download.)
  2. Ant works better when you don’t want to do things “the Maven way.”  Maven uses convention over configuration.  Which is great when you can use those conventions.  They save a lot of time.  (And most of those conventions are fine).  It so happens at CodeRanch, we don’t deploy a full war.  We deploy a zip file containing a subset of the project files.  Again because of that internet thing.  We don’t all have the ability to upload a full war without the internet connection timing out.  This could be done in Maven, but it would be odd.  And I think it would be confusing to use Maven and ignore conventions.
  3. Ant gives you complete control.

Maven has a different set of advantages

  1. It is much faster to get started with a new project.  You can use an “archetype” to get a project template.
  2. You don’t have to think about dependencies.  If you are using X and it depends on Y, both get pulled.  The dependency management is excellent.
  3. Convention means you don’t have to set up much in your build configuration.

I think Maven is going to be better for the project I was asked about here.  You want dependency management which is something Maven excels at.  And you have a greenfield project which means there is no reason you can’t use Maven’s conventions.   Also, many other tools easily integrate with Maven (or Ant) like Findbugs which will be helpful.

Application Security USA 2013 – live blog index

Posted on by
Reply

I attended the Application Security USA conference this year. Similar to The Server Side Symposium two years ago, ago, I blogged about it.  This post a link to all of those blog posts.  For readers in the New York City area, OWASP has a quarterly meetup.  I’ve gone to the last three or so and found the speakers to be excellent.  And since the conference was in NYC this year, I took the opportunity to go.

Wednesday

Thursday

Plus how blogging with the iPad Air went.

csrf defenses at app sec usa

Posted on by
Reply

speaker: Ari Elias-Bachrach

Overview

  • Most defenses work 80% of the time. Does your app fall into the 80%?
  • CSRF sometimes pronounced c-surf
  • CSRF attack uses browser to perform action without user consent
  • Vulnerable if all params predictable. Then can put url in image tag. Or use JavaScript to submit (need for post)
  • If have multiple tabs or haven’t logged out, your browser thinks authenticated session so can still perform actions.

Patterns

  • Synchronizer token – most common alternative – use a csrf token then have server make sure gets same random value back. Watch how token is remembered and completeness of coverage
  • Double submit cookies – Makes sure cookie and hidden field match. Useful for REST. Do not use session iD for this purpose. Session ID is in the GET request; not secrete
  • Challenge response – CAPTCHAs or reauthentication – do protect against CSRF but usually used for other things. Watch user impact.Never seen for CSRF primarily
  • Check the referrer header – the referrer should be your site not another site like twitter. You don’t perform action on first visit to the site. Watch side effects. Never seen for CSRF primarily.

Code level

(.net) ViewState
Submitted state on all postbacks. Useful for wizards. Add session id to view state for token. Now your view state is unpredictable. Works fine if only use postbacks. If sometimes actions go to other pages, won’t work.

(.net) AntiForgery token
Put Html.AntiForgeryToken() as first scriptlet in form. And add [ValidateAntiForgeryToken] before each action. Problem is by default this only works for POST by default. People have hacked it. If your application is properly designed, GET is idempotent anyway. The worse problem is the “forgetful programmer issue”. A developer can forget to add it to every form. [I wrote a unit test for this problem in Java]

(.net) AntiCsrf
Implements double submit cookies pattern. Only supports POSTS.

(Java) CsrfGuard
PHP and .NET versions in progress. Keeps on token per session by default and uses synchronizer token pattern. Problem is that exposure of token jeopardizes whole session to CSRF. Experimental option to per link/action token. Modifies get and post requests. Supports AJAX via a HTTP header. May mess up links if use funky URLs. [you shouldn’t be using GETs. grumble. It’s not that hard to change GET to POST]

(Java) HDIV – HTTP Data Integrity Validator
Uses synchronizer tokenizer pattern. Session by default. Experimental optional for link/action tokens as well. Queue based expriy. Set queue size accordingly.

Server level

Tomcat
Tomcat 7 generates UUID for each page loaded. Protects GET and POST. Runs as a filter. Don’t have to change app at all. Helpful for an old app that nobody knows about. [seems risky to me. apps have funky javascript, get vs post, etc. Oh good. Jim Manico called out that it can break your app.]

F5 (Load Balancer) ASM
Same ideas as Tomat except it has less visiblity into your session. Can have token expire based on time since can’t go by session expiration. Defaults to 10 minutes.

Imperia SecureSphere
Checks referrer header isn’t from an external site. Can see false positives. Browser plugins can tamper with referrer. Browser won’t include referrer error from SSL. More useful for detecting than preventing. There are plugins that create random referrers so would have to turn off that plugin to use your site. Also, wouldn’t stop stored XSS for CSRF attack.

Other problems

  • CSRF token can reveal which library you are using. If you have an uncovered vulnerability, this could be revealed
  • If you have ANY XSS vulnerability in your site (even on another page), you are not protected against CSRF
  • Protecting GET pages comes at a cost [I’m glad he finally mentioned this]

slides available

My take
CSRF isn’t new to me. See what we did at CodeRanch. I think it is an important topic though and it was interesting to see about other solutions. The speaker was very thorough assuming no knowledge and covering more advanced topics.