The Security Problems with Serving Up Scripts & Mobil Code

Q: How can a webmaster verify that his computer programs have not been tampered with?

Time passed...

Then, we received this inquiry from http://kingarthur.com/give.html:

THE ARTS help = journalism
THE ARTS help = multimedia
BUSINESS help = marketing
BUSINESS help = publicity
Name of person inquiring = MAC
city = Triangle
state = VA 22172
citizen of = USA
political affiliation = None (military)
a friend of KingArthur.com says:

First a bit about myself.

I currently work as a community relations representative for the United States Marine Corps and webmaster of Marine Corps Base Quantico. I am University Trained as a computer engineer (dropped out my senior year) and spend two years as a combat correspondent. I also spent time on the Marine Corps Judo and Sombo Teams and became sort of an expert in ballistics from having to explain various events to local media.

My intent is to rejoin the think tank if for no other reason than because my time with the Corps is coming to a close now and I am looking for a group to join where I can exercise my brain a bit.

I have an extreme interest in marketing philosophy, especially in e-commerce, and my studies are the driving force behind coming changes to web sites across the military. My multimedia experience and extreme love for philosophy may also be of benefit to the group.

As such, I humbly request to rejoin the think tank. (I was known in a past life as Oak...)

Please let me know what I can do.

dear MAC... er, a... oak,

thank you for your inquiry.

yes! we have many ways that you can fit in 'round here.

in particular, you said:

"I have an extreme interest in marketing philosophy, especially in e-commerce, and my studies are the driving force behind coming changes to web sites across the military."

members of our think tank are very concerned about this... in fact, one of our members wrote navy headquarters in the last month... and, we have a complaint filed with the FTC (against the FTC).

i'd be happy to fill you in on more of the details... but, you might want to start at http://membrane.com/security/

thank you. i look forward to having you on the team.

Mac should do fine, thanks.

I'll preference this by saying that I can and will not speak officially for any part of the DOD on this topic. I can however shed some light on the topic if you ask the questions. I do ask that if you reprint my correspondence that it be done so in full. (in other words, include any disclaimers I may attach.)

We currently use javascript for a few functions on our site, however part of our current requirement is to change over our sites so that they are viewable by non-javascript enabled browsers (part of Section 508 compliance). As such, many of our current uses are being moved over to ASP format and the rest eliminated. I would be interested in seeing the specific concerns you have about Java and ASP (if applicable). Since we are in the midst of rewriting our sites, I should probably see this. I'd also be interested in seeing the letter to the DON (wasn't on your site...)

Does the think tank still run a list serve? How do we communicate now-adays?

Fill me in!

cool... do you want your name used, or not? or a pseudonym?

Mac should be fine.

there are a coupla webpages that talk about our concerns with "push" programs. (like java and asp)

1. http://membrane.com/security/java_and_cookies/notes/basics.html

Interesting, but let's look at this a bit...

Of concerns for my users...

"u cannot be sure what the client browsers will do with the code u send them" This was true in 1995. However my logs are showing that 97% of my hits are coming from web browsers capable of Javascript. (Most of the rest are me, since I still surf my site on a text based browser on a regular basis...)

I argue then that I do know what the browsers do with the code. Either it executes it or it ignores it (presuming I have written it correctly)

Furthermore, you (well, Sidd, anyway...) claim that "most people will not inspect the code that their browser executes or if they do, they don't understand it so they are handing over control of their machine to anybody on the net whose website they visit"

First, I disagree that users today are quite that ignorant of the internet's ability to affect a machine. The average user is at the least wary of viruses and the like, and will take precautions against them (such as disabling javascript in their browser...)

Script is just that, script. It is not executable code. If the browser does not recognize what to do with the script, it can't do anything.

I argue users are able to care of themselves after almost 8 years of commercial internet. I also believe instilling regulations like the ones you ask us too would be like reinstating the law where a man must walk 30 feet in front of a vehicle with an oil lamp so people will know you are coming.

Furthermore, we in the internet industry are now a customer driven society. This wasn't true when you first made these arguments. Users expect the kind of "flash and dash" they get when we use current technologies. They pay out the rump for cable modems so they can get Napster or download videos from the net. They choose the flash version over the html and deal with the longer download time because they are in the mood to be entertained. All without inspecting the data packages for hidden tricks and viruses.

What matters in this equation? That I, as a content provider, get my point across because I used a technology which allowed me to pass my information to my customer in a way he or she wants to see it? Or that make an effort to police my customer's web use for them, so they'll go off to another web site to see something more interesting.

As much as I hate to admit it, the large majority of web users (and, I content almost all of the users the DON is interested in) are not the educated university graduate students looking for information like in the mid nineties, but rather the "low attention span" majority of our national population for which commercial makers have decided can't watch a still shot in a commercial for more than four seconds without getting bored.

Another comment Sidd made was: "i have no wish to run my code except in an environment that i control ..."

Fine. While this would be more protective of your users, I agree this may open up issues for you security wise on your server. I argue, however, that if you set up your server correctly, there would be no problems.

It is up to you to know how to set up your firewalls correctly. It is up to you to get a security certificate and a secure socket layer to protect sensitive information. It is up to you to only place items in the public domain that need to be in the public domain. It is up to you to know enough about the language you are coding in to eliminate areas of security risk.

I think you would be hard pressed to actually tell me a security risk I would have as a result of utilizing a server side scripting language on my server. Especially those like ASP where users can't even see the code (providing you remove anonymous FTP from the server.) I think you would be even harder pressed to show me a security concern I would have by using a client side scripting language, so long as you use the language intelligently.

I see you are against scripting languages (even though there is a much larger demonstrated risk in holding a Perl CGI-Bin on you server... ), but I still have not seen any specific examples why. Don't hold back on me, get technical. I am MCSE, MCSD and Cisco certified. I went through three and a half years of computer engineering and I have been designing content for the internet since 1989. I think I can handle it. Sidd said it best. "there are other reasons...but these will suffice ..."

Maybe to describe why you won't allow the codes to be placed on your server, but certainly not to get me to join the cause... and certainly not enough to get the SecNav webmaster to change his mind and order a total rewrite of even his own webserver, much less than the 560 some odd others he has administrative control over.

2. http://membrane.com/security/java_and_cookies/

Much of what I said above applies here as well. Again, I can not fault you for writing this abstract in 1994, I might have even agreed with you then. I still claim that most of your concerns do not apply to people who know their coding language and are willing to ensure they act in a moral way.

For instance, in your cache_attack article ( http://membrane.com/security/java_and_cookies/notes/cache_attack.html) you blame the ability of javascript for the code. The true culprit in this case is not the language, it is the way it is used. "the exploit allows an unethical Web Site", not an ethical one. No more so than an unloaded gun offers a threat to a crowded room. Someone must load that gun and fire it, whether accidentally or intentionally, to harm someone.

So why Ban javascript? Wouldn't it be better for organizations to set rules to police how they use scripting languages and allow the users to decide where to go? Is a company unethical for searching out where employees go on the internet? Especially during work hours and if they are informed that they are being watched?

3. http://KingArthur.com/law/FCC_inquiry.html

Just a side note... by law there is no such thing as a formal complaint via e-mail. We in the fed aren't even required to enter into a log if we answer it. Yes, I know all about paperwork reduction act and electronic signature laws... but it still remains a fact.

I would comment further, however I do not know when this e-mail was sent and what reply you received (if any...)

4. http://membrane.com/security/java_and_cookies/notes/department_of_defense.html

I remember when this article came out... sometime late in 1999. The "investigation" was nearing it's close. The result was two fold... one, all DOD servers were requested to go to full SSL and password protect any sensitive information. Public affairs offices and security manager offices were requested to determine what was and wasn't safe. Two, Persistent cookies were banned, much to the chagrin to both our command webmasters and many of our users... since we could no longer offer some of the better services we used to provide online. Any other problems with script language use were considered solved by the new Section 508 requirements of the American Disability Act.

All that said... answer me this.

I currently administrate 13 DOD webservers as well as oversee or consult on the administration of 232 commercial web servers (my contracts as of Jan 12... my managers should have another report to me on the 5th of next month.)

I try to design all my websites to offer as much flex- and usability as possible to the widest array of users possible. We use asp as a rule, and use the scripts to determine what abilities our clients have and offer webpages tailored to that client. In other words, users who have java disabled don't get any java on the page. (mostly because alternative browsers are often not java capable, such as one used by the blind ...)

All websites contain publicly releasable information, and four copies (two tape, one CD and one on a backup server) are kept for quick reload of server content in the event of a hack. Any non-releasable information is kept SSL and password protected. Anything I definitely can't let out is mailed to clients (CDs are mailed to our clients containing the information they need overnight registered mail)

So, where am I wrong? What is the threat? If there is one, I certainly would love to know. In the mean time, I need to continue to give my contracts the flexibility of service they have come to expect.

NOTE: These comments reflect my own views and not those of any of my clients nor any part of the department of defense or federal government. In some cases, these comments do not even reflect my own views, but instead serve to liven up the conversation a little.

Dear MAC,
Just a coupla quick notes before the hoopla starts to fly... our complaint with the FTC… against the FTC… was made via the phone. I was promised a review by a Commissioner lawyer within 12 hours of my submission. I have not heard back.

Also, I placed a copy of the Department Of Navy Email at: http://membrane.com/security/java_and_cookies/notes/navy.html

Wally's Reply

From Sidd:

wait .. i am not against the use of scripting languages i am against the use of client side scripts that execute on client machines .. this does not include javascript, or asp the latter 2 are server side scripts, and asking the client to open up javascript entails much less risk on the client side

I argue then that I do know what the browsers do with the code. Eithor it executes it or it ignores it (presuming I have written it correctly)

there are substantial differences between java interpreters.. code that runs perfectly well on suns implementations will crash and die orribly on microsoft platforms .. and there are even differences between releases by the same vendor

It is up to you to know how to set up your firewalls correctly. It is up to you to get a security certificate and a secure socet layer to protect sensitive information. It is up to you to only place items in the public domain that need to be in the public domain. It is up to you to know enough about the language you are coding in to eliminate areas of security risk.

agreed

I see you are against scripting languages

NOOOO!

Mark Hammel, OPSEC, responded:

So why Ban javascript? Wouldn't it be better for organizations to set rules to police how they use scripting languages and allow the users to decide where to go

absolutely.

so you're suggesting that SECNAV, SECDEF, DOJ/AG, SECEN/DOE (oh baby, there's a whole other can of worms), or OPS-2, ... have all done so? or that the code on all these sites now con- forms to those rules? or that there is code-consistency among their code rules? or that any of the current sites' code has been benchmark tested for intrusion-resistance?

a thought to consider:

DOD has been openly recruiting at the last two black hat hacker conferences. generic approaches to use of highly vulnerable code by existing in-house personnel is one of many reasons.

so instead of using existing code with known vulnerabilities, like a herd of lemmings, why not use either alternate code, or develop code variations, testing same, then deploying after rigorous testing?

fellas,

da... er, a... am i missin' sumpin' here?

but, what about the tampered code problem?

as a practical matter... for use in the real world... we took the question to a round table (i think it was round... the picnic table in my backyard... hehehe) of top programmers and thinkers. (about 2 years ago or so?)

the result:

any mobile code that resides on our webservers must either be --

1. verified as untampered before being served
2. be certified and made read only (e.g. cdrom)

3)-- see 2)

Back To The Study