Oh ... Java ... What Are We Going To Do With You?
-
-
What Are We Going To Do With You?
Take out back to tend the rabbits, hopefully.
-
s/Java/Oracle/
-
Well, for one, stop using Java anywhere that isn't on the server side.
And that includes those stupid management interfaces for network hardware.
While the company said it could be exploited only through the sandboxed Java Web start applications and sandboxed Java applets, it can also be exploited in server environments such as the Google App engine for Java.
This would need some explaining.
My understanding of Java web applications is that the app server runs one (or more)
ClassLoader
(s) itself as well as oneClassLoader
for each web application.Further
ClassLoader
s are prevented from running by security policy.
-
Java
Security policy
MFW
-
The article says Java. Leave the thread title alone, please.
-
Something something mondays
-
Leave the thread title alone, please.
See? You're nice now. How long until you @Blakeyrat out about it?
Better put something at the top of the OP so people get the message or something...
-
The thing is... it's still slightly safer than running a .exe... which we do every day.
-
I'm always nice.
On an unrelated note, all dissenters have been rounded up and incarcerated.
-
Safer ... in what way? o_O
-
-
Either the Java sandbox is secure, in which case the application can't interact with the system, or it isn't, in which case... it can do everything a .exe already could. So equal to or better, but never worse.
Unless your java.exe runs as administrator... that would be a problem.
-
But it does mean Oracle Java specifically, doesn't it?
Yes, which is why I didn't pitch a fit about the recategorization;)
-
Either the Java sandbox is secure, in which case the application can't interact with the system, or it isn't, in which case... it can do everything a .exe already could. So equal to or better, but never worse.
Okay, I'll concede that point, but stipulate that it is no different than saying, "either the Windows operating system is secure, or it isn't."
And, between the two, Windows by itself, and Java, which have we heard of more in the last 5 years as security holes providing vectors for malicious code to find homes? That doesn't even bring into the equation Flash, which really does deserve its own category of
-
-
I am so happy! After ten years of having to defend Java on the desktop (and that was still Java 6 and Java 7, when I left a couple of months ago) I am now 100% certified Java free!
I do feel for my ex-colleagues though - what a big pile of doggie do...
-
Oh yeah, I forgot to mention, if you're able to deploy apps to a JavaEE server, you're probably already on the other side of the airtight hatchway (or are using some other exploit to gain access to it).
-
@skotl said:
I am so happy! After ten years of having to defend Java on the desktop (and that was still Java 6 and Java 7, when I left a couple of months ago) I am now 100% certified Java free!
Good for you!
-
@NTW if he's like me and ended up doing JS stuff then I'm not so sure.
-
@Eldelshell Nup - it's all C# and .net MVC goodness now, with added Azure sugar.
Mind you - one of the guys started talking about JEE the other day, so need to shut that shit down!
-
@skotl said:
it's all C# and .net MVC goodness now, with added Azure sugar
Welcome to the Promised Land ;)
In all seriousness, ASP.NET MVC is a genuinely good framework. It has its warts obviously, but then everything has faults.
-
@RaceProUK The guy who mentioned JEE was trying to justify it by saying that the rate of progress in Java is faster than in .netland...?
-
@skotl I seriously doubt Java's moving any faster than .NET
-
This post is deleted!
-
@RaceProUK I seriously doubt you're wrong!
To be fair, his other argument was how much is already baked into JEE and well understood, rather then on the .Net side where we need to play google-the-options to assess which library to link in. Flavours of the month in .Netland often don't last the month...
But I'm still happier on this side, just so we don't have to deal with Java
-
@skotl He sounds like someone who has little or no experience of .NET; the base framework is very comprehensive, and the various add-on frameworks MS makes like ASP.NET MVC and SignalR are all very well supported and being actively developed.
-
@skotl I work in java and bitch about it constantly.
I style myself as @Lorne-Kates lite but incompetent. Fuck you and give me money and I'll build shit in any language you like.
Edit : I mean to delve into .net fully one day but I never appear to have the time. :(
Another Edit : jee... A headache I never want to have... I see why you hate java
-
@skotl said:
@RaceProUK The guy who mentioned JEE was trying to justify it by saying that the rate of progress in Java is faster than in .netland...?
look at the time java took to have generics, and lambdas
c# progress run circles around java
-
@fbmac Sorry, I couldn't hear you over my password having
<B
in it crashing the server.Yes, that is a real feature of C#.
-
@ben_lubar said:
Yes, that is a real feature of C#.
ASP.NET actually, and it's the feature that protects against HTML injection attacks
-
@RaceProUK in addition to the feature of the template engine escaping HTML? I can see why you'd need the server to crash on an input it can already handle.
-
@ben_lubar
@Html.Raw()
doesn't escape HTML
-
@RaceProUK so the proper course of action is obviously to throw up our hands and say "if the developer is able to disable this feature, we must crash the server when someone attempts to exploit the disabled security feature!"
-
@ben_lubar If you've disabled the feature, then the crash is caused by something else
-
@RaceProUK so you're saying that if
@Html.Raw
is used anywhere in the program, the crash from having<B
in my password is from some other part of the code than if@Html.Raw
wasn't called?
-
@ben_lubar No, what I am saying is that if you have disabled the security feature, then the crash is caused by something else;
@Html.Raw()
has nothing to do with it
-
@RaceProUK in this conversation, you've told me that the feature of the server crashing when I have
<B
in my password is there so that people can't do HTML injection attacks. Except that the templating engine already escapes HTML by default. And then you countered with "theHtml.Raw
function doesn't escape HTML" and then told me that the crash must be caused by something else if I didn't callHtml.Raw
on a password.
-
@ben_lubar For fuck's sake…
Look, it's really simple. The templating engine escapes HTML except when you use methods like
@Html.Raw()
. As a result, there's a potential avenue for a malicious user to submit HTML to the website and have it served to other users unaltered. When enabled, the security feature stops this happening by throwing an exception. However, if the security feature is turned off, then the exception is never thrown and the HTML submitted is accepted. That means the crash you're seeing is caused by something else entirely.
-
@skotl said:
Mind you - one of the guys started talking about JEE the other day, so need to shut that shit down!
@skotl How bad JavaEE is depends on which frameworks you're allowed to use.
If the answer is None, immediately take him out back and club him to death.
If the answer is Spring + JPA, it's not that bad assuming you're using a sane JPA implementation.
Having said that, mentioning that Java innovates faster than .NET is like saying the Tortoise was winning the race before the Hare took a nap.
-
@fbmac said:
the time java took to have generics
Java had generics before c#, which is partof why java generics suck so much worse than c#'s. They thought they could implement them as a zero-cost abstraction, but it turns out not really. C# was able to learn from java's mistake. So if java's a bit slower now on the uptake, I'm ok with that. C#'s endless syntax bloat can be annoyance of it's own.
-
@powerlord said:
Having said that, mentioning that Java innovates faster than .NET is like saying the Tortoise was winning the race before the Hare took a nap.
The interesting innovations in Java-space are almost all outside the language.
-
The same could be said about C#. A lot of ideas are imported from other languages and frameworks.
-
@lucas1 And they're going to import more; they've already got local functions (which you can do in JavaScript) implemented for C#7, and they're working on tuples and pattern matching too (like Haskell/Scheme/F#/functional-language-here)
-
@ben_lubar the "feature" is that asp.net assume the programmer will screw witg security, which is common tbh
it checks for anything like a tag as soon as it receive a request, no matter what you call
-
@RaceProUK said:
local functions
Is that with the local variables in the containing scope being modifiable? The problem with that is that it lets you leak prodigious amounts of memory in hard-to-detect ways. Well, not so much leak as carry around without realising it; it's still properly referenced and all so it is technically not leaked even though it looks suspiciously similar.
-
@dkf If you mean 'closures', then yes, it'll do that
-
@RaceProUK The real “fun” comes when you manage to have closures hanging off closures. Mix in some threads and so on and you can really have a gigantic amount of memory hanging off one reference without appearing to do so to the casual reader of the code. With read-only closures, while it is still possible to make huge graphs this way, the code at least looks like you're being sneaky, which should act as a warning. :)
I hate it when languages let sneakiness hide. Makes debugging take so much longer.
-
@dkf said in Oh ... Java ... What Are We Going To Do With You?:
@RaceProUK The real “fun” comes when you manage to have closures hanging off closures.
closureception?
-shudder-
dealt with that before..... not fun.
-
@accalia Reminds me of hunting down that sort of thing in Java. Oracle's actually got some reasonable tools for doing it (packaged together as
jvisualvm
, IIRC). Unfortunately, I discovered in my case that my leak was fundamentally caused by the way that the thread pools were managed (plus some code that just insisted on entangling the application code and the thread) and the whole thing ended up leaking.Fortunately, the leak didn't matter in production deployments. It was just annoying as hell in my dev and test environments.