For many Java developers, application security has not been an issue they've wanted to address. That changed last week as a panel of application security experts tackled the subject at TheServerSide Java Symposium in Las Vegas.

The panel's message was clear: Not only is it important to know what your risks are, but you need to develop a plan to incorporate security in all levels of software development.

Led by moderator Cameron Purdy, president of Somerville, Mass.-based Tangosol, panelists Jeremiah Grossman, Ted Neward, Christopher Steel and Justen Stepka agreed that application security can't be an afterthought. You need a plan from the beginning.

In "Java developers can't afford to ignore app security," the panel's core results are presented as an array of issues to address, rather than actual solutions, but as Ted Neward said, developers don't want to address security, but they need to, and awareness is the first step to making secure applications.

One interesting threat was mentioned a number of times: SQL injection, where SQL text is injected directly from a user application into a string executed on a database. Numerous articles in almost every trade magazine have addressed this issue, in particular (centering around the mantra of "use PreparedStatement instead of Statement," which is sufficient for the majourity of cases) but the continued mention of the problem indicates that injection hasn't gone away.

To be sure, injection has broadened to include Javascript as well, such that malicious users are injecting scripting text in addition to SQL code, but it's strange that SQL injection, which is nearly trivial to eliminate, is still a problem -- which only serves to highlight what the panel's conclusions were.

More resources:

• More on SQL Injection from SearchAppSecurity
• More on cross-site scripting from SearchAppSecurity

For many Java developers, application security has not been an issue they've wanted to address. That changed last week

Nothing changed! A bunch of panelists at TSSS aren't going to change a fundamental industry trend.

Developers are perfectly happy to develop secure applications as long as their customers ask for it and are willing to pay for it.

Unfortunately, everybody asks for it but nobody wants to pay for it.

Unfortunately, everybody asks for it but nobody wants to pay for it.

+1.

"Java developers can't afford to ignore code quality"
"Java developers can't afford to ignore code security"

what other lame presentation was there on the symposium?

something in the line of:

"Java developers can't afford to ignore object-oriented design basics"
"Java developers can't afford to ignore relational databases"

etc.?

Dear Lord, it must have been a real waste of time and money :)

amazing...

Hi Irakli -

"Java developers can't afford to ignore code quality"
"Java developers can't afford to ignore code security"

what other lame presentation was there on the symposium?

So, here's the story: TSS wanted to find someone knowledgeable to moderate this forum, and failing to find that person (and in no part due to desperation) they asked me to do it. I had never moderated a panel before, but I took some good queues from Ted's moderation of a panel that same morning, and got the audience (which was largely composed of application developers etc.) to provide questions -- which they did!

The questions from the audience were intelligent, well worded, and they clearly reflected real application development and operational concerns. I learned more about security from this panel than from the previous 20 or so security-related sessions I've sat through. The members of the panel were quite knowledgeable on the subject (one was an author on the subject, another a "white hat" cracker, etc.), the audience questions were spot on, and the result was truly informative.

I'd love to see more sessions like this in the future. No slides, but lots of information!

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

/s/queues/cues

Cameron,

if you say, that's how it was, I happily believe you and withdraw my complaint.

However, you have to agree that the session name is misleading and somewhat lame.

Except the valid argument, already mentioned here, that security is mostly ignored by customers, not developers - there is one more thing...

There is nothing in application security that is specific to Java. So why - "Java developers"? Meaning - C++ ones can ignore? :)

Also, there is a very wide range of applications where application security is not relevant at all. Not all applications are enterprise systems, you know?

So, I guess application security is about - what kind of applicaiton you are working on and has nothing specific to do with Java and even less with - Java developers.

Therefore, you have to agree - the session name was lame :) I am glad to hear the session itself was useful, though.

cheers,

Irakli

Risks (even security) are quantified economically. Whether it is economic loss due to the risk, economic loss due to damaged reputation because of the risk, or liability loss due to the risk, it is all quantified economically. Right now software bugs (including security) are semi-protected with the clause in a lot of eula's that say "we are not liable for any loss due to the use of this project". We are one of the few industries that have that protection. I think we are slowly seeing that being chipped away. Eventually, I believe we will see a legislative solution (i.e. Congress passing a strict law removing this eula protection) or a market solution (i.e. software use insurance) or both. I think the market solution is most interesting. If we look at automobile insurance we see that there is a legislative solution as well as a market solution. If there wasn't how many of us would be driving? Probably not many. After all, it would only take one accident to wipe a lot of us out financially. Also, if there wasn't liability for defective products how many of us would want to drive some cars (i.e. anyone still have a Pinto?). Lastly, this was kind of a light weight article. It may be necessary for the extreme beginner so I guess there may be an audience on TSS for it. One last thing from the article, "figure out how to factor prime numbers"? Good luck with that one:)

When you buy a house, you have the freedom to buy one with just a door or one with an expensive security system. I like that freedom. Some people only need a door.

Making software vendors legally liable for security is like making a seller of house responsible for a burglary or worse, claiming the seller should have included an expensive security system.

When you buy a house, you have the freedom to buy one with just a door or one with an expensive security system. I like that freedom. Some people only need a door.Making software vendors legally liable for security is like making a seller of house responsible for a burglary or worse, claiming the seller should have included an expensive security system.

Not a very apropos analogy. Try this one instead: "Making software vendors legally liable for security is like making the seller of [a] house responsible for a burglary or worse, even though the seller didn't know (and therefore failed to disclose) that the next door neighbor had tunnelled under their back yard and had instant access to the house's basement."

This was one of the better sessions I attended at TSSJS ... not because of the cool slideware :-), but because it addressed a problem area that far too many Java developers do not even care to understand. And the developers that were in attendance were clearly taking it seriously.

Blaming a lack of concern for security issues totally on management is a cop-out.

Craig McClanahan

I agree blaming the whole problem on management is cop-out. I've seen first hand management ignore security, even though the developers all agreed the security was insufficient. I've quit jobs in the past because the security was ignored. There are plenty of java developers who do ignore security, but there are numerous cases developers are told "not to worry about security."

the entire company from manager down to the developer need to care and think about security. Rare can a developer or a team of developers change corporate culture. my bias 2 bits

peter

I agree blaming the whole problem on management is cop-out. I've seen first hand management ignore security, even though the developers all agreed the security was insufficient. I've quit jobs in the past because the security was ignored. There are plenty of java developers who do ignore security, but there are numerous cases developers are told "not to worry about security."the entire company from manager down to the developer need to care and think about security. Rare can a developer or a team of developers change corporate culture. my bias 2 bitspeter

+1. In fact, the worst situation is when you are told specifically not to worry about security as the resources (time, money) are inadequate, so you do what you have to do and then at the end of the day, management turns around and say, well now we need security, put it in, as if it is something you can slap on top without any extra costs.

...Blaming a lack of concern for security issues totally on management is a cop-out...

I see a few issues with security:
- management cares about security, but they pack you with deadlines and issues
- management cares about it, but the developer does ignore it
- management and the developer do not care about it
- both (management and the developer) care about security, but do not know how to deal with it

For the management point 2 is frustrating (although they canfire the developer), for the developer its point 1 (and he can do almost nothing about it). BUT for the users all points are bad...

Alexander Jesse

How many times have people been asked to "delay security" because something else was more important. I don't believe it's true that developers don't care about security. Atleast not in the general sense.

a developer can keep saying, "we need better security" until he turns blue, if management always places some other tasks as "higher" priority.

peter

How many times have people been asked to "delay security" because something else was more important. I don't believe it's true that developers don't care about security. Atleast not in the general sense.a developer can keep saying, "we need better security" until he turns blue, if management always places some other tasks as "higher" priority.peter

Agreed. In the US., Sarbanes-Oxley compliance is forcing these managers' hands in a lot of cases -- at least a little bit. The barrier is still too high though, and security seems to be the lowest hanging fruit when it comes to the economics of the situation.

I've also seen and heard of cases where SOX compliance was "lip-service". For many companies, complying with federal regulations is too costly, so they "fudge" compliance. Those who think SOX regulations is a threat haven't really seen compliance applications first hand. Those who are serious about SOX were already doing fairly rigorous compliance, so adding SOX wasn't something new. For companies that didn't do compliance, the hurdgle is just so big they are overwhelmed.

peter

...but good to sell to executives.
We always knew it:
I's the developers who are to blame!

http://www.vnunet.com/vnunet/news/2150294/economics-work-against-safe