JavaOne 2015 Session Information

In case you will attend JavaOne in San Francisco end of October… Session scheduler is just around the corner, my two sessions are scheduled for the following dates and locations:

Session Type: Conference Session
Session ID: CON2022
Session Title: The Web Application Strikes Back
Venue / Room: Hilton – Plaza Room B
Date and Time: 10/26/15, 14:30 – 15:30

Conference: JavaOne
Session Type: Conference Session
Session ID: CON2023
Session Title: Java Web Security Antipatterns
Venue / Room: Hilton – Plaza Room B
Date and Time: 10/29/15, 13:00 – 14:00

USA is too far away? No problem, there are still a lot of upcoming talks in Germany this year.

JavaOne 2015 Session Information auf Twitter teilen
JavaOne 2015 Session Information flattrn
JavaOne 2015 Session Information auf Digg teilen
JavaOne 2015 Session Information auf Delicious teilen
JavaOne 2015 Session Information auf Xing teilen
JavaOne 2015 Session Information auf LinkedIn teilen
JavaOne 2015 Session Information auf Pinterest teilen
JavaOne 2015 Session Information auf StumbleUpon teilen
JavaOne 2015 Session Information auf Tumblr. teilen
JavaOne 2015 Session Information auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Using OWASP Dependency Check as Jenkins plugin

OWASP Dependency Check is a great tool to check your third party dependencies in Java (web) applications. Besides using it as command line tool, Maven plugin or Ant task, you should integrate it all your Jenkins build jobs.

One downside is that as default, every build job downloads and regularly updates its own National Vulnerability Database file. In order to improve that, I recommend creating an update only job that runs daily. In order to do that, create a freestyle project and add Invoke OWASP Dependency-Check NVD update only as build step:

Invoke OWASP Dependency-Check NVD update only

Enter a data directory which will be used by every job. This job should have a build trigger to run that job periodically (like @daily). Now save and run the job.

After that you need to activate OWASP Dependency Check on every build you like. To do that, open all job configurations and add Invoke OWASP Dependency-Check analysis as a post-build step:

Invoke OWASP Dependency-Check analysis

Click on the Advanced button and enter the data directory configured in the update job before. Remember to activate the Disable NVD auto-update checkbox since all updates are done by the updates job. Now add Publish OWASP Dependency-Check analysis results and configure the status thresholds as you like. Since developers tend to hate failing jobs I recommend configuring warning thresholds only:

Publish OWASP Dependency-Check analysis results

Time to save and run your job. As with any (security) scan results: these lists tend to contain false positives, verify each finding!

This configuration ensures fast job execution and minimizes the required update time for the National Vulnerability Database. Besides that, it reduces the required disk space by using only one common database.

Using OWASP Dependency Check as Jenkins plugin auf Twitter teilen
Using OWASP Dependency Check as Jenkins plugin flattrn
Using OWASP Dependency Check as Jenkins plugin auf Digg teilen
Using OWASP Dependency Check as Jenkins plugin auf Delicious teilen
Using OWASP Dependency Check as Jenkins plugin auf Xing teilen
Using OWASP Dependency Check as Jenkins plugin auf LinkedIn teilen
Using OWASP Dependency Check as Jenkins plugin auf Pinterest teilen
Using OWASP Dependency Check as Jenkins plugin auf StumbleUpon teilen
Using OWASP Dependency Check as Jenkins plugin auf Tumblr. teilen
Using OWASP Dependency Check as Jenkins plugin auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Free web application vulnerability scanner for Eclipse

Contrast released Contrast for Eclipse 1.0 already a little while ago. The Eclipse plug-in works as a runtime security scanner and checks for security vulnerabilities in your web application while executing it in Eclipse. Promised by Contrast on Eclipse Marketplace is an Automated detection of OWASP Top 10 vulnerabilities.

This is the first free tool available that explicitly scans for security vulnerabilities. Other tools like FindBugs or PMD may find some security problems as well, but are focussed on bugs and bad practices.

Running the Contrast test is easy: Instead of running or debugging your web application you simply launch your configured web server with Contrast in the Servers view:

Contrast in Eclipse Server view

The scanner detects possible vulnerabilities while you are using the web application (a.k.a. at runtime) and points to the source code line causing the vulnerability, extended with helpful information about the vulnerability and additional links.

I’ve used some of my intentionally vulnerable web applications in the JavaSecurity and Java-Web-Security repositories as test environment. These are some of the results I received while using the XSS sample application:

Contrast view with findings

The findings are all correct, but the important one is missing: The XSS vulnerability. So while Contrast tells me that no Anti-Caching response headers are in place and that my forms use auto-completion (both warnings are absolutely correct), it has missed the successful XSS attack that ended in the following dialog visible in my browser:

XSS popup in the browser

Bummer!

Next stop, CSRF: Same findings (cache and auto-complete), no CSRF warning.

Final stop, SQL Injection: Same findings (cache and auto-complete), no SQL Injection warning.

XSS, CSRF and SQL Injection are – in my eyes – still some of the nastier problems we are facing in web applications (among others). And they have been a part of the OWASP Top 10 forever.

Countercheck with FindBugs (and manually enabled security and malicious code vulnerability checks): got several warnings on reflected cross-site scripting and SQL Injection vulnerabilities.

So, use the Contrast plug-in or not? Well, use it from time to time, it still might discover some vulnerabilities in your web application. But don’t expect too much and definitively extend it with regular FindBugs scans. Still a long way to go with open source security scanner.

Free web application vulnerability scanner for Eclipse auf Twitter teilen
Free web application vulnerability scanner for Eclipse flattrn
Free web application vulnerability scanner for Eclipse auf Digg teilen
Free web application vulnerability scanner for Eclipse auf Delicious teilen
Free web application vulnerability scanner for Eclipse auf Xing teilen
Free web application vulnerability scanner for Eclipse auf LinkedIn teilen
Free web application vulnerability scanner for Eclipse auf Pinterest teilen
Free web application vulnerability scanner for Eclipse auf StumbleUpon teilen
Free web application vulnerability scanner for Eclipse auf Tumblr. teilen
Free web application vulnerability scanner for Eclipse auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

JavaOne 2014 retrospective

JavaOne 2014 is over, and it has been a fantastic experience! Better than my first attendance 2012. Most sessions had a higher quality, JavaHub was fantastic (I just love the Nao robot), enjoyed Geek Bike Ride and met a lot of new and interesting Java developers. The only mixed feelings I have are about both keynotes (Sunday and Thursday). No new content on Sunday, cut off in the middle of the most interesting part to probably make room for the OpenWorld keynote. Thursday contained a lot of advertisement for one of the sponsors (I’m not going to repeat their name), first half hour totally wasted (yeah, I know, the conference seems to need sponsors, Oracle can’t afford all the money, totally poor company, oh, wait…). But the rest of the keynote was actually quite good. Food was poor as always, but the parties in the evenings were much better and the food was ok there (which does not include the beer).

Of course I attended a lot of security sessions and met a lot of speakers I only knew from recordings so far. And as Jim Manico said today, it is nice that the security people started to tell unexperienced developers the same stories and recommend the same solutions. That doesn’t make us interchangeable! Instead it helps the developers to do the right thing and develop software securely.

Next year promises to be somehow special, Java turns 20 (and finally 21 in 2016, legal age to drink alcohol, maybe they will serve good beer then). JavaOne will take place one month later as usual at the end of October. Maybe with a real lunch and a working conference app that does not log you off 10 times a day and does not require session updates 50 times a day…

My slides are available for download here.

JavaOne 2014 retrospective auf Twitter teilen
JavaOne 2014 retrospective flattrn
JavaOne 2014 retrospective auf Digg teilen
JavaOne 2014 retrospective auf Delicious teilen
JavaOne 2014 retrospective auf Xing teilen
JavaOne 2014 retrospective auf LinkedIn teilen
JavaOne 2014 retrospective auf Pinterest teilen
JavaOne 2014 retrospective auf StumbleUpon teilen
JavaOne 2014 retrospective auf Tumblr. teilen
JavaOne 2014 retrospective auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Using security response headers with WordPress

I’ve added several security headers to my blog today. The first part was easy: I’ve created a .htaccess file in my blog’s root directory with the following content:

Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options DENY
Header set X-Content-Type-Options "nosniff"
Header set Strict-Transport-Security "max-age=31556926"
Header set Cache-Control "no-store, no-cache, must-revalidate"

Only one header was missing: Content Security Policy (CSP). The header itself was easy to add, but caused some problems at first:

Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options DENY
Header set X-Content-Type-Options "nosniff"
Header set Strict-Transport-Security "max-age=31556926"
Header set Cache-Control "no-store, no-cache, must-revalidate"
Header set Content-Security-Policy "default-src 'self'; img-src 'self' http: https: *.gravatar.com; frame-ancestors 'none'"

This works perfectly for the pages you can access, but totally breaks the admin pages. There are way too many JavaScript files consumed from other domains. And a lot of these pages contain unsafe inline JavaScript, which would force me to add ‘unsafe-inline’ to the policy. And with that value not much security is left. Fortunately, I’m talking about the admin area, which is only accessible by myself. So instead of creating a new policy in the wp-admin folder that would more or less allow anything, I’ve decided to deactivate it completely in this area by creating a .htaccess file in this folder with the following content:

Header unset Content-Security-Policy

The Content Security Policy header is great, but this is a typical example for problems with older (I don’t wanna say legacy in this case) applications or application parts you don’t have under control.

But anyway, all security relevant headers are returned in my blog now. Please report any problems you might discover.

Using security response headers with WordPress auf Twitter teilen
Using security response headers with WordPress flattrn
Using security response headers with WordPress auf Digg teilen
Using security response headers with WordPress auf Delicious teilen
Using security response headers with WordPress auf Xing teilen
Using security response headers with WordPress auf LinkedIn teilen
Using security response headers with WordPress auf Pinterest teilen
Using security response headers with WordPress auf StumbleUpon teilen
Using security response headers with WordPress auf Tumblr. teilen
Using security response headers with WordPress auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Keep Your X-Frame-Options header a little while longer

So Mozilla has decided to deprecate the X-Frame-Options header to avoid clickjacking or UI redressing attacks (have a look in the page history, the first version used a much stronger language). This header was never standardized (as the leading X indicates), but is supported in all browsers (yes, in ALL browsers, with the exception of the special ALLOW-FROM value). The X-Frame-Options replacement is Content Security Policy Level 2 (CSP) with its frame-ancestors directive. I’m all for reducing the huge amount of headers and using CSP instead. Even though a CSP for a normal web application might already be extensive.

There is one huge problem though: browser support. While most modern browsers support CSP level 1 (where there is no frame-ancestors directive) – Internet Explorer supports at least a subset – only Firefox supports the frame-ancestors directive. Give it a try, I’ve updated my security-headers web application you can clone from GitHub. This of course leads to the situation that we developers have to return both headers at the same time, X-Frame-Options and CSP with frame-ancestors directive. And the browser shouldn’t have any problem with that. Older browsers ignore the CSP, newer browsers should ignore X-Frame-Options if frame-ancestors is present. Doesn’t sound like a lot of fun for both parties, does it? But that’s the way it is. We simply cannot afford replacing X-Frame-Options header with CSP right now and leaving most web users unprotected. Especially corporate environments with older browsers (even older Firefox versions do not support CSP Level 2) this will be the situation for quite a while. In the end, CSP will win, and it’s a win we all will benefit from. Just be patient, there is no need to hurry removing old headers right away.

Keep Your X-Frame-Options header a little while longer auf Twitter teilen
Keep Your X-Frame-Options header a little while longer flattrn
Keep Your X-Frame-Options header a little while longer auf Digg teilen
Keep Your X-Frame-Options header a little while longer auf Delicious teilen
Keep Your X-Frame-Options header a little while longer auf Xing teilen
Keep Your X-Frame-Options header a little while longer auf LinkedIn teilen
Keep Your X-Frame-Options header a little while longer auf Pinterest teilen
Keep Your X-Frame-Options header a little while longer auf StumbleUpon teilen
Keep Your X-Frame-Options header a little while longer auf Tumblr. teilen
Keep Your X-Frame-Options header a little while longer auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

My two security sessions at JavaOne 2014

Awesome news today, my two security sessions at JavaOne 2014 have been accepted! I’ll be speaking about Security starts in the head(er) (CON2371) and 7 security tools and libraries every developer should know (CON2585) (see the session information below). Flight and hotel are booked; hope to see you in San Francisco!

Security starts in the head(er)
Java developers surely have already heard or even used some of the many available HTTP response headers in their web applications. Some of these response headers promise to have a positive impact on the security on the client side. However, they are not widely used yet, even in newly developed web applications. This results in giving away relatively easy attainable security benefits.
This session introduces attendees to different security related response headers and intends to raise the participants’ attention for the unjustified low usage of these security headers. Besides an introduction and a closer look at their properties, the session explains how to correctly configure and integrate them into a Java web application.

7 security tools and libraries every developer should know
Like in almost any other part of Java the security area for web applications offers a huge amount of different sized libraries and tools which all promise to make the life of a developer much easier. However their sheer amount raises the question which libraries are used best at which time and which tools optimally support the secure development of a web application.
This session introduces seven different security-tools and -libraries (frameworks), which support a developer when developing secure Java based web applications. These libraries solve common and wide spread security problems in web applications. The shown tools assist the developer and make it easier to preserve the achieved level of security in the web application.

My two security sessions at JavaOne 2014 auf Twitter teilen
My two security sessions at JavaOne 2014 flattrn
My two security sessions at JavaOne 2014 auf Digg teilen
My two security sessions at JavaOne 2014 auf Delicious teilen
My two security sessions at JavaOne 2014 auf Xing teilen
My two security sessions at JavaOne 2014 auf LinkedIn teilen
My two security sessions at JavaOne 2014 auf Pinterest teilen
My two security sessions at JavaOne 2014 auf StumbleUpon teilen
My two security sessions at JavaOne 2014 auf Tumblr. teilen
My two security sessions at JavaOne 2014 auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

JSF stateless views and CSRF protection

JavaServer Faces (JSF) – especially since version 2.2 – provides a good Cross-Site Request Forgery (CSRF) protection. To achieve this, every form automatically receives a random hidden token:

JSF non-transient view

Nothing more to do for the developer, JSF takes care of comparing the token’s value against the one stored in the server side session. Without the correct token, the request won’t be processed.

JSF 2.2 also introduced stateless views, simply by marking one as transient:

<f:view transient="true">...</f:view>

Using a transient view may make sense e.g. before a user has logged in and no session needs to be stored on the server. Or you want to avoid that nasty ViewExpiredException. But keep in mind that this influences the out of the box CSRF protection as well. Looking at the same form from before but with transient on true, the anti CSRF token changes:

JSF transient view

An anti CSRF token needs to be unpredictable and absolutely random to be of any use for CSRF protection. The static value stateless of course is not.

Is this a bug? No! The most common implementation for CSRF protection is called Synchronizer Token Pattern. This pattern stores a hidden value in forms (like javax.faces.ViewState) and the corresponding value in the server side session. Using transient=”true” avoids creating a server side session. No session, no Synchronizer Token Pattern, no CSRF protection. So when using stateless views you’ll have to implement CSRF protection yourself. The requirement is the same: a random token calculated per user and per session (or per request depending on your security needs). But without the server side session the implementation needs to change. Luckily, there is another option called Double Submit Pattern (see here for a description of both patterns). Double submit, as the name implies, submits the same token from two different places: one in a cookie and the other one, as before, in each form you want to protect. Whereas the cookie is always submitted – including faked requests – the form token is missing and your backend – which has to compare the two submitted tokes – can recognize an invalid request. So by avoiding session creation for every visitor (user), you’ll be giving away the out of the box JSF CSRF protection.

One usage scenario for stateless views might be a login form. After logging in, you want a session for the user, but not for any anonymous visitor. You might ask yourself, what harm a login form that is prone to CSRF could do? Well, it may enable an attacker to automatically log in a user with prepared credentials. This way, the attacker may record and retrace the users’ actions. Therefore you should protect the login form against CSRF as well.

That’s the tradeoff you have the be aware of: JSF provides out of the box CSRF protection, as long as your view isn’t transient. If that this the case you’ll have to take care of the CSRF protection yourself.

JSF stateless views and CSRF protection auf Twitter teilen
JSF stateless views and CSRF protection flattrn
JSF stateless views and CSRF protection auf Digg teilen
JSF stateless views and CSRF protection auf Delicious teilen
JSF stateless views and CSRF protection auf Xing teilen
JSF stateless views and CSRF protection auf LinkedIn teilen
JSF stateless views and CSRF protection auf Pinterest teilen
JSF stateless views and CSRF protection auf StumbleUpon teilen
JSF stateless views and CSRF protection auf Tumblr. teilen
JSF stateless views and CSRF protection auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

A look back at JavaLand 2014

JavaLand 2014 is over, and it has been a great first edition of the conference! It was a great privilege speaking there. The sessions I’ve attended were interesting, I ended up with a lot of new ideas for the weeks to come. The different community activities made it really easy to get in touch with others, talking about Java more or less the whole time. Enjoying some park attractions in the late evening did the rest to get to know some new Java enthusiasts. The whole location was nice, definitively the most extraordinary place of any Java conference I’ve attended so far. Like a little geek holiday. Organization was good (with some minor places for improvements). Lunch and dinner buffets were huge. And the floating lunch time avoided long lines. Speakers and organizers welcome dinner on the first evening was a good start, the African food served really something unusual and tasty.

Two minor things I did not like that much were the two too dark session rooms (including mine). I like to see my audience and have some kind of eye contact. Yes, the stage background was really great and something completely different. But simply too dark. The other thing I did not like was the stuff you had to pay for separately. I don’t have a problem that not everything is included in the conference fee (which, as a speaker, I did not pay anyway). But the hotel was quite expensive; to be topped by the drinks at the bar and the drinks you had to pay for after running out of coupons. Yeah, it’s a theme park, which all are at least a little bit pricy. But the park was opened for the conference only, more fair prices should have been possible.

But besides that, I really enjoyed this new conference, definitively worth a visit next year in case you missed this one. And I’m sure that most of this years attendees will come back.

A look back at JavaLand 2014 auf Twitter teilen
A look back at JavaLand 2014 flattrn
A look back at JavaLand 2014 auf Digg teilen
A look back at JavaLand 2014 auf Delicious teilen
A look back at JavaLand 2014 auf Xing teilen
A look back at JavaLand 2014 auf LinkedIn teilen
A look back at JavaLand 2014 auf Pinterest teilen
A look back at JavaLand 2014 auf StumbleUpon teilen
A look back at JavaLand 2014 auf Tumblr. teilen
A look back at JavaLand 2014 auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren