JBoss AS 7 context-root manipulation for web services

I recently had a requirement for web service availability at root context level on JBoss AS 7. Without any configuration, a web service URL (as the rest of the web application) contains the jars’ name like http://localhost:8080/MyJar/MyService/MyEndpoint whereas my desired URL looked like http://localhost:8080/MyService/MyEndpoint without the jars’ name. Adding the jboss-webservices.xml file to the META-INF folder of the web service project with the following content was only have the story:

<?xml version="1.0" encoding="UTF-8"?>
<webservices version="1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.jboss.com/xml/ns/javaee"
  xsi:schemalocation="http://www.jboss.com/xml/ns/javaee
  http://www.jboss.org/schema/jbossas/jbossws-web-services_1_0.xsd">
  <context-root>/</context-root>
</webservices>

Now JBoss Management Console showed service availability at the desired URL, but the service was unreachable (404). The final part was to modify standalone.xml and set the value of the enable-welcome-root attribute to false (attribute belongs to the virtual-server element), which made the web service reachable on context root.

JBoss AS 7 context-root manipulation for web services auf Twitter teilen
JBoss AS 7 context-root manipulation for web services flattrn
JBoss AS 7 context-root manipulation for web services auf Digg teilen
JBoss AS 7 context-root manipulation for web services auf Delicious teilen
JBoss AS 7 context-root manipulation for web services auf Xing teilen
JBoss AS 7 context-root manipulation for web services auf LinkedIn teilen
JBoss AS 7 context-root manipulation for web services auf Pinterest teilen
JBoss AS 7 context-root manipulation for web services auf StumbleUpon teilen
JBoss AS 7 context-root manipulation for web services auf Tumblr. teilen
JBoss AS 7 context-root manipulation for web services auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Remove Checkstyle warnings for certain classes

Checkstyle warnings for generated or automatically filled classes like Messages.java in Eclipse RCP can be annoying. But even without the .checkstyle file under version control, it is possible to deactivate Checkstyle warnings for selected files.

First you have to add the SuppressionFilter module to your Checkstyle configuration file:

<module name="SuppressionFilter">
 <property name="file" value="${samedir}suppressions.xml"/>
</module>

The path entered to suppressions.xml must be absolute, ${samedir} takes care of that.

The suppressions.xml file contains a simple list of suppress elements, where a . as checks-attribute property represents all checks (the attribute value is a regular expression). The other possibility is to deactivate only selected checks by inserting a module name as configured in the Checkstyle configuration.

<?xml version="1.0"?>
<!DOCTYPE suppressions PUBLIC "-//Puppy Crawl//DTD Suppressions 1.1//EN" "http://www.puppycrawl.com/dtds/suppressions_1_1.dtd">
<suppressions>
 <suppress checks="." files="Messages.java"/>
</suppressions>

Remove Checkstyle warnings for certain classes auf Twitter teilen
Remove Checkstyle warnings for certain classes flattrn
Remove Checkstyle warnings for certain classes auf Digg teilen
Remove Checkstyle warnings for certain classes auf Delicious teilen
Remove Checkstyle warnings for certain classes auf Xing teilen
Remove Checkstyle warnings for certain classes auf LinkedIn teilen
Remove Checkstyle warnings for certain classes auf Pinterest teilen
Remove Checkstyle warnings for certain classes auf StumbleUpon teilen
Remove Checkstyle warnings for certain classes auf Tumblr. teilen
Remove Checkstyle warnings for certain classes auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

A little bit more security for Java in the browser

Oracle just released Java 7 update 21, containing once more many security fixes (install it right away). And some changes for applet usage und handling. First of all, the preference dialog does not contain the low security setting any more. Which forces more user interaction when launching unsigned applets. Unsigned applets therefore require at least some interaction now; they are not launched automatically any more. A future Java update (probably the next update in July) will prevent you from running unsigned applets at all. And there will be a blacklist which will protect you from running applets signed with an invalid or revoked certificate.

For sure this will have a positive impact on Java browser security, but it’s not a big catch. This totally relies on certificate authorities and that they carefully check people buying certificates. And we all know how well that worked out in the past many, many times. It’s just too easy to get valid certificates. And there are no restrictions left when running signed applets.
Yeah, now we ‘know’ who bought the certificate and probably signed the malicious applet and can trace it back. Up to the point where we figure out a faked id was used to buy the certificate. This is not helpful at all. Oracle’s reaction to certificate fraud is to add such an invalid certificate to the frequently(?!) updated JRE certificate blacklist and prevent the JRE from further applet execution. This might work in 80% of the time. The other 20% will receive this update too late. In my eyes this is not a real solution, just another workaround to avoid killing the whole Java applet support at all.

Of course it is not Oracle’s fault that it is that easy to get a valid certificate with a fake id or no check at all. But fixing one broken system with another broken system is simply not going to work. And the loser is Java.

A little bit more security for Java in the browser auf Twitter teilen
A little bit more security for Java in the browser flattrn
A little bit more security for Java in the browser auf Digg teilen
A little bit more security for Java in the browser auf Delicious teilen
A little bit more security for Java in the browser auf Xing teilen
A little bit more security for Java in the browser auf LinkedIn teilen
A little bit more security for Java in the browser auf Pinterest teilen
A little bit more security for Java in the browser auf StumbleUpon teilen
A little bit more security for Java in the browser auf Tumblr. teilen
A little bit more security for Java in the browser auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Java in the browser is dead

So its certificates now. Looks like Java applets don‘t care about certificate revocation lists at all. Signed applets gain full access to the system. An invalid certificate should prevent that. Which means a certificate revocation list is kind of important. But no, let’s forget about that check. No need to hack the sandbox this time (which is easy anyway, see the last couple of Java updates).

This is another huge security failure in Java applet ‘security’ again. One in a long way. And not the last one. In fact there are still some known vulnerabilities even in the latest Java version.

The latest series of security problems caused a lot of damage for the whole Java platform and ecosystem. As a Java developer I can (and do) only advise everybody to uninstall Java or at least to deactivate Java browser support. Like a lot of people do. But what’s Oracle’s reaction? By shipping one critical update after the other. Faster than ever. But that won’t change much, the next critical security hole is just around the corner. Java in the browser is insecure and will remain so. And Java in the browser is that. Oracle just won’t admit it.

The problem with that is: Java on the client will be dead next. Normal users cannot distinguish between Java browser applications and rich clients (kind of our fault, since we told everybody for years now to ignore that border). Server side Java will not die that easily (good!), but the last couple of months caused a lot of damage there too. It became much harder to argue for a Java web application instead of .net for example. Not that other frameworks don’t have security issues too. But all people hear at the moment on a certain (management) level is that Java is insecure and needs security fixes every couple of days. How would you react?

This will become even harder in the future if Oracle continues like that. The only solution in my eyes is to remove Java browser support right now. Get rid of this totally outdated and widely unused peace of technology. Restore Java’s good reputation before it is too late.

Java in the browser is dead auf Twitter teilen
Java in the browser is dead flattrn
Java in the browser is dead auf Digg teilen
Java in the browser is dead auf Delicious teilen
Java in the browser is dead auf Xing teilen
Java in the browser is dead auf LinkedIn teilen
Java in the browser is dead auf Pinterest teilen
Java in the browser is dead auf StumbleUpon teilen
Java in the browser is dead auf Tumblr. teilen
Java in the browser is dead auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

OWASP Top 10 2013 release candidate published

The first release candidate of the new OWASP Top 10 2013 was published a couple of days ago (PDF). And the top 10 changed quite a bit (see the project wiki):

  • A1 Injection
  • A2 Broken Authentication and Session Management (was formerly A3)
  • A3 Cross-Site Scripting (XSS) (was formerly A2)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration (was formerly A6)
  • A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
  • A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
  • A8 Cross-Site Request Forgery (CSRF) (was formerly A5)
  • A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
  • A10 Unvalidated Redirects and Forwards

Some changes are a little bit surprising in my eyes at first. Definitively not that injections are still number 1. Guess some things never change. But I think the drop of XSS from 2 to 3 and CSRF from 5 to 8 does not reflect reality. Sure, there is little more awareness to these problems (only a little), and some Java frameworks offer (some, but getting better) out-of-the-box-protection. But these issues are still tough to solve and are still dangerous. And they are a good eye-catcher and easy to talk about. Hopefully that does not prevent developers to think about it during web application development. Not that the other items are unimportant, however I can’t fully agree with the order.

But whatever is your motivation for secure development (in case you simply need another one besides, well, security), don‘t take the OWASP top 10 positions too seriously. The issue is important, not the current position. OWASP top 10 issue 11 (whatever dropped out the list) may be your issue number 1. And even a controversial list makes developers talk about security, which is the best thing that could happen to us.

The OWASP Top 10 2013 final version should be available in May 2013.

OWASP Top 10 2013 release candidate published auf Twitter teilen
OWASP Top 10 2013 release candidate published flattrn
OWASP Top 10 2013 release candidate published auf Digg teilen
OWASP Top 10 2013 release candidate published auf Delicious teilen
OWASP Top 10 2013 release candidate published auf Xing teilen
OWASP Top 10 2013 release candidate published auf LinkedIn teilen
OWASP Top 10 2013 release candidate published auf Pinterest teilen
OWASP Top 10 2013 release candidate published auf StumbleUpon teilen
OWASP Top 10 2013 release candidate published auf Tumblr. teilen
OWASP Top 10 2013 release candidate published auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Making Java secure again

The recent total failure of Java security is neither the first one, nor will it be the last one. Java in the browser (in the form of Java applets) is not secure and will never be secure. Oracle can provide all the security patches they want, the next major security breach is just around the corner.

This is comparable with Microsoft Windows security a couple of years ago. Year after year they tried to fix it and ran from bugfix to bugfix before noticing it will not change too much and that a complete redesign of their operating system is required. In case of Java the only solution (in my eyes) is to remove Java browser support with the next major release Java 8. This feature is not widely used any more, applets are plain old technology. Oracle should announce the stop of support right now. Don’t tell people to deactivate it, this is not a solution. Don’t even ship it. Users still requiring Java in the browser can use Java 7 in the transition period. This should provide enough time for all companies and all products to switch from unsecure Java applets to much safer Java web applications. And companies still using Java applets should ask themselves, why they force their users to rely on an unsafe technology.

Oracle keeps telling (e.g. in the JRE installation dialog) us that 3 billion devices run Java. This number will go down rapidly with every new major security problem. The security problems of one little part of the platform will have a negative influence on the rest of the platform. Word will spread that Java is insecure. This makes the usage of Java in any project harder than necessary. Server side Java is safe, Java desktop applications are safe, Java embedded is safe (in the usual dimensions). But it’s hard to argue about Java safety with everybody hearing about Java security failures in mainstream news. Normal users do not and cannot differentiate between web and desktop application security as we developers do. For a normal user Java is failing. This will be a huge problem in the future.

And finally, removing Java browser support will give more time for all the great Oracle Java employees on moving the platform forward. The rest of the Java platform would surely benefit from that.

Making Java secure again auf Twitter teilen
Making Java secure again flattrn
Making Java secure again auf Digg teilen
Making Java secure again auf Delicious teilen
Making Java secure again auf Xing teilen
Making Java secure again auf LinkedIn teilen
Making Java secure again auf Pinterest teilen
Making Java secure again auf StumbleUpon teilen
Making Java secure again auf Tumblr. teilen
Making Java secure again auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Java 7 update 11 available, addressing the latest major security flaw

So, Oracle released Java 7 update 11 today, addressing the latest major security flaw with Java applets. Guess we are safe now for about a week. Of course I strongly recommend installing the new release as quickly as possible. But keep Java disabled in your browser! In case you do need a Java applet I’ll recommend to only activate Java on demand. Java in the browser (I’m talking about Java applets only) is outdated technology, and it is totally unsafe. And it will remain unsafe, no matter how many security patches will be provided by Oracle. The next security flaw is just around the corner. It is time to get rid of Java browser support; focus on server side Java, Java desktop applications as well as the mobile world. Java rocks, but it definitively sucks as a safe browser extension.

Java 7 update 11 available, addressing the latest major security flaw auf Twitter teilen
Java 7 update 11 available, addressing the latest major security flaw flattrn
Java 7 update 11 available, addressing the latest major security flaw auf Digg teilen
Java 7 update 11 available, addressing the latest major security flaw auf Delicious teilen
Java 7 update 11 available, addressing the latest major security flaw auf Xing teilen
Java 7 update 11 available, addressing the latest major security flaw auf LinkedIn teilen
Java 7 update 11 available, addressing the latest major security flaw auf Pinterest teilen
Java 7 update 11 available, addressing the latest major security flaw auf StumbleUpon teilen
Java 7 update 11 available, addressing the latest major security flaw auf Tumblr. teilen
Java 7 update 11 available, addressing the latest major security flaw auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren