tag:blogger.com,1999:blog-4088979.post2872722827449451884..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: Do Devs Care About Java (In)Security?Richard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-4088979.post-40820663100272056002013-03-20T09:15:37.688-04:002013-03-20T09:15:37.688-04:00We're back to the first comment. You need to d...We're back to the first comment. You need to distinct between Java based web applications (server side) and Java based appliactions for workstations.<br /><br />For the former you're right. This applies to web application security (SDL).<br /><br />However, if you have Java based applications in an enterprise and you need to have Java enabled in your browser for the business (maybe even just for intranet apps), then you still have the risk of Java malware infections from drive-by (or "watering hole") attacks, where patching JRE on all workstations will always be too slow. This can be mitigated (or minimized) by the previously described Java whitelist approach on a web proxy.<br /><br />Cheers,<br />@c_APT_ureTomUhttps://www.blogger.com/profile/16795133222461988201noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-66186670591708643132013-03-20T05:26:05.440-04:002013-03-20T05:26:05.440-04:00Security should be as much a concern for developer...Security should be as much a concern for developers as performance or reliability. It should not even have a special "oh, right, that, too" status, but be considered in the process of developing Java applications. Grayhttp://www.softwaysolutions.com/java-j2ee-j2me-programming-application-development-programmer-houston-texas-uk-europe.htmlnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-47946806665103820122012-11-25T15:10:45.992-05:002012-11-25T15:10:45.992-05:00We've implemented it with a custom policy rule...We've implemented it with a custom policy rule on a COTS web proxy. But I guess you can do the same with many proxy products, maybe even some open-source like Squid etc.<br /><br />You need to know all Java (JRE / Webstart) User-Agents in your environment and create a regex matching them all. I found that UA based is the only way to distinct Java applets (or webstart appl's) from other browser requests.<br /><br />Here's a sample UA regex using "." instead of spaces. (may need adjustment for other environments)<br />("Mozilla/4\.0.\(Windows.(2003|Server.2008|Server.2008.R2|Vista|7)..\..\).Java/1|"JNLP/6\.0.javaws/1)<br /><br />The policy rule should be something like:<br />- if UA matches Java-UA-RE and domain is in whitelist --> allow<br />- if UA matches Java-UA-RE and domain is NOT in whitelist --> block<br /><br />I hope this gives anyone an idea of how this could be done. Good luck!<br /><br />Cheers,<br />@c_APT_ureTomUhttps://www.blogger.com/profile/16795133222461988201noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-29703748648386910702012-11-24T19:10:28.127-05:002012-11-24T19:10:28.127-05:00@TomU: is your whitelist Java proxy all custom cod...@TomU: is your whitelist Java proxy all custom code or are you using COTS? Is it something you could share/opensource so we can all benefit?S Anoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-71624614455323150302012-11-22T18:12:46.586-05:002012-11-22T18:12:46.586-05:00Why does everything always need to be black or whi...Why does everything always need to be black or white? You can't just disable Java in an enterprise that has many Java based applications in use, but updating Java is sometimes really hard, too. So we've implemented a proxy-based Java whitelist for "trusted sites" that need Java applets, much like the trusted sites model in IE for Active-X. I found many blocked malicious applets since, but not one drive-by infection from Java exploits. In additiona you might also want to whitelist executable downloads, in case some drive-by exploit still worked, the download of malware.exe would be blocked. There is also enough malware spreading using plain executables without browser-plugin exploits.<br /><br />Cheers,<br />@c_APT_ureTomUhttps://www.blogger.com/profile/16795133222461988201noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-74365834366463558962012-11-22T16:20:31.639-05:002012-11-22T16:20:31.639-05:00Otherwise, they may find themselves coding for a p...<i>Otherwise, they may find themselves coding for a platform that enterprise users will increasingly disable.</i><br /><br />In our organisation, as I'm sure in many others, that's simply not an option. Some of our corporate applications require a client-side installation of Java, which often must be held back until that application has been certified with the latest patch revision. Changing the software used is non-trivial and, frankly, many within the enterprise itself don't understand the need (and there's not a lot of competition to change to anyway).<br /><br />Yes, there's many workarounds. But they're workarounds, not solutions. As long as this is the case, Oracle has to know they've got a captive audience.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-64762843763415705772012-11-22T14:31:51.926-05:002012-11-22T14:31:51.926-05:00You're comparing apples to oranges. Server-sid...You're comparing apples to oranges. Server-side Java (spring, hibernate, etc) and client-side Java (applets, local desktop apps, etc) are two completely different situations. Current vulnerabilities in Java are exclusively exploitable in the latter, not the former. There are other reasons to avoid writing server-side web apps in Java, but the reasons you listed here are not them.Anonymousnoreply@blogger.com