Tag Archives: appsecusa

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.

application risk and components at app sec usa – jeff williams’ part

Posted on by
Reply

Thesis: Need to rethink how things work so they happen real time.

Aspect does a lot of code review and manual testing. That’s why they don’t have XSS and System.out.println() as the leading items. Static analysis tools are good at finding that.

Stats

  • 98% of apps have at least one vulnerability
  • On average, Apsect uncovers 22.4 serious vulnerabilities per app. A small fraction are in open source libraries.

We find vulnerabilities months or even years later. Developers are likely on another project by now. Or have at least forgotten the code. Which means they won’t have gotten any learning out of it.

Interception points

  • HTTP Traffic – ZAP can be proxy between Selenium and app to sniff traffic.
  • Data Flow
  • Control flow – static or interactive
  • Libraries and frameworks
  • Configuration data – static analysis tools don’t look here. But could write a static analysis rule for it
  • Back end connections – sometimes developers don’t know so isn’t in architecture review

What if this were the US tax code?
Imagine somone dropped the US Tax code on your desk and ask you to find the loopholes. It’s about a million lines of code. Lawyers don’t do it in one week. You wouldn’t read it line by line. You’d look for patterns. Caman Islands?

Mix existing techniques to get continuous security

  • Code review useful, but hard to do real time. Need to take that effort and turn it into small automated tools. Make it into repeatable test case. ZAP does this – you can write a ZEST script to test for future instances of vulunerabiity. Mozilla is going to make that the standard way of reporting a bug to them.
  • Static analysis – Great at enforcing simple checks. Explore positive rules. Custom rules for more complex patterns.
  • Dynamic analysis
  • Interactive application security testing – look at insides, good at data flow analysis, injection flaws, library testing
  • JUnit – verify your controls are correct. Don’t see enough people using JUnit for security

My Take
This was similar in message to Jeff’s morning session. Some parts were the same (reuse) and some parts were different. And some parts went into different depth. And again Jeff mentioned Sonatype more than Ryan did.