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,
Also, I placed a copy of the Department Of Navy
Email at:
http://membrane.com/security/java_and_cookies/notes/navy.html
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.
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 --
"a" was prohibitively expensive for us... the server
load to verify code on a well trafficked website would
be substantial.
to deal with something like membrane.com
we would need
several "clusters" / super computers... wouldn't we?
if you couldn't do these things on schedule with a very generous budget, i'd fire all of you and find somebody who could. then i'd fire your bosses for having failed to demand this of you... in that you're all in violation of a gov policy of significant importance on e-security.
in your case, this means you'd all be serving out your terms of service in alaska.
2)aanything u wanna do in java we can do better without
3)-- see 2)