http://www.cnn.com/2008/TECH/science/03/21/antarctic.search.ap/index.html
Looks like a giant species of star fish has been found. These guys would look better with faces. I propose that we tattoo faces on all star fish:
Friday, March 21, 2008
giant starfish found
From
http://www.cnn.com/2008/TECH/science/03/21/antarctic.search.ap/index.html
Looks like a giant species of star fish has been found. These guys would look better with faces. I propose that we tattoo faces on all star fish:
http://www.cnn.com/2008/TECH/science/03/21/antarctic.search.ap/index.html
Looks like a giant species of star fish has been found. These guys would look better with faces. I propose that we tattoo faces on all star fish:
Tuesday, November 13, 2007
Monday, October 29, 2007
Robust DHTML
DHTML is the technique of combining JavaScript and CSS to create dynamic page elements that are not possible with static HTML. For example, it's easy to dynamically show or hide page elements, or move them.
Given the differences in broswers, it is by nature a bit difficult to write clean DHTML. And worse, most free DHTML examples of code on the internet are written poorly, as they have countless little browser checks, and conditional code branches like:
This is poor design, as it is brittle, hard to maintain, and often breaks when new browsers are released or change. And likely, any browser not in the checks will not supprted correctly either. Also I see a lot of newer DHTML scripts doing more css and in place of javascript, although, I still think css support across browsers is still a bit flakey.
A better way is to design something with these simple principles:
Here is a small example designed with these principles in mind (modified from Apple Developer's site):
This code works in all javascript-enabled browsers I've tested (FireFox 1+, IE 4+, Netscape 4+, Opera), despite having no checks for any specific browser. Also, all code that interfaces directly with the broswer api is isolated, so it is very easy to extend or debug if there ever is a problem.
To use the code above, for example, save it to a file named "dhtmlutil.js" and use it like:
If you add more functions, put them all together in the head with the included file.
to use hyperlinks, use a dead link with an onclick handler like:
DEGRADING GRACEFULLY
A fundamental problem with DHTML is figuring out how to design the page so that it degrades gracefully. In other words, if javascript or css aren't supported, the user can still use the page. This is especially difficult for menus, and othter page entitties that are hidden/collapsed by default. A menu is the most important element on the screen, and should be viewable on the lowest common denominator. Even if old browsers are obsolete, there is always a chance it won't be compatible with future broswer releases/bugs (for example, the Netscape 6 to 7 fiasco). The general rule is:
The best way to achieve this is to wrap javascript around css elements in the header, such as:
This code, for instance, will hide all members of the class "switchcontent," except for the one with the id "sc1". So, if javascript or css is broken, all these entities will be visible. Note that these tags conflict, but that the style closest to the element takes precedence. Corresponding div tags for this code might look like:
Given the differences in broswers, it is by nature a bit difficult to write clean DHTML. And worse, most free DHTML examples of code on the internet are written poorly, as they have countless little browser checks, and conditional code branches like:
if(isIE){
//do something one way
} else if(isNetscape6){
//do something else another way
} else if(isNetscape4){
//do something else yet another way
//...
}
This is poor design, as it is brittle, hard to maintain, and often breaks when new browsers are released or change. And likely, any browser not in the checks will not supprted correctly either. Also I see a lot of newer DHTML scripts doing more css and in place of javascript, although, I still think css support across browsers is still a bit flakey.
A better way is to design something with these simple principles:
1. sniff for functionality rather than browser name/version
2. create a single wrapper function that encapsulates brower specific code
3. page should "degrade gracefully" if possible (meaning the page will still be readable and functional if javascript or dhtml not supported)
Here is a small example designed with these principles in mind (modified from Apple Developer's site):
// cross-browser dhtml utilities
// wrap blocks of html in div> tags with unique id's
// try to get a style object given its id
function getStyleObject( objectId ) {
if ( document.getElementById &&
document.getElementById( objectId ) ) {
// W3C DOM
return document.getElementById( objectId ).style;
} else if ( document.all && document.all( objectId ) ) {
// MSIE 4 DOM
return document.all( objectId ).style;
} else if ( document.layers &&
document.layers[ objectId ] ) {
// NN 4 DOM.. note: this won't find nested layers
return document.layers[ objectId ];
} else {
return false;
}
}
// a template function for setting two-state style properties
function setStyleBoolean( objectId, booleanValue,
propertyName, valueOn, valueOff ) {
var styleObject = getStyleObject( objectId );
if ( styleObject ) {
if ( booleanValue ) {
styleObject[ propertyName ] = valueOn;
} else {
styleObject[ propertyName ] = valueOff;
}
return true;
} else {
return false;
}
}
// try to show/hide object. a empty visual space will remain in place
function setObjectVisibility( objectId, booleanValue ) {
return setStyleBoolean( objectId, booleanValue,
'visibility', 'visible', 'hidden' );
}
// try to insert/remove object from display. page will redraw and no space will remain in place
function setObjectDisplay( objectId, booleanValue ) {
return setStyleBoolean( objectId, booleanValue,
'display', '', 'none' );
}
// try to move object
function moveObject( objectId, newXCoordinate, newYCoordinate ) {
var styleObject = getStyleObject( objectId );
if ( styleObject ) {
styleObject.left = newXCoordinate;
styleObject.top = newYCoordinate;
return true;
} else {
return false;
}
}
This code works in all javascript-enabled browsers I've tested (FireFox 1+, IE 4+, Netscape 4+, Opera), despite having no checks for any specific browser. Also, all code that interfaces directly with the broswer api is isolated, so it is very easy to extend or debug if there ever is a problem.
To use the code above, for example, save it to a file named "dhtmlutil.js" and use it like:
<html>
<head>
<script language="javascript"
src="dhtmlutil.js"></script>
</head>
<body>
<h2>Clean DHTML example</h2>
<div id="test1">
this is a block of html that can be hidden or removed
</div>
<p>
you can change the properties of the
block above with these buttons:
<p> set display
<input type=button
onclick="setObjectDisplay('test1', false);"
value = "off">
<input type=button
onclick="setObjectDisplay('test1', true);"
value = "on">
<p> set visibility
<input type=button
onclick="setObjectVisibility('test1', false);"
value = "off">
<input type=button
onclick="setObjectVisibility('test1', true);"
value = "on">
</body>
</html>
If you add more functions, put them all together in the head with the included file.
to use hyperlinks, use a dead link with an onclick handler like:
<A HREF="javascript:void(0)" onClick="....">
DEGRADING GRACEFULLY
A fundamental problem with DHTML is figuring out how to design the page so that it degrades gracefully. In other words, if javascript or css aren't supported, the user can still use the page. This is especially difficult for menus, and othter page entitties that are hidden/collapsed by default. A menu is the most important element on the screen, and should be viewable on the lowest common denominator. Even if old browsers are obsolete, there is always a chance it won't be compatible with future broswer releases/bugs (for example, the Netscape 6 to 7 fiasco). The general rule is:
4. Any hidden entity should be visible if DHTML is broken.
5. No core functionality should ever depend on DHTML.
The best way to achieve this is to wrap javascript around css elements in the header, such as:
//write styles via javascript, to degrade gracefully
var idx = 'yourid';
if (document.getElementById ||
document.all || document.layers ){
document.write('<style type="text/css">')
document.write('.switchcontent{display:none;}')
document.write('<\/style>')
document.write('<style type="text/css">')
document.write('#' + idx + '{display:block;}')
document.write('<\/style>')
}
This code, for instance, will hide all members of the class "switchcontent," except for the one with the id "sc1". So, if javascript or css is broken, all these entities will be visible. Note that these tags conflict, but that the style closest to the element takes precedence. Corresponding div tags for this code might look like:
<div id="sc1" class="switchcontent">
something visible by default
</div>
<div id="sc2" class="switchcontent">
something invisible
</div>
<div id="sc3" class="switchcontent">
something invisible
</div>
Calling command line tools from a web application
Occasionally, it's convenient (or practically necessary) to have a web application call a command line tool. If not done wisely, it can open up a huge security risk. For example, suppose we are using a simple command line tool that excutes a command like:
Now suppose someone creates a new user named "bill;rm -rf /" and passes it to a command line utility which executes:
This will of course wipe everything out under /. Not good! It's not hard, if these interfaces have not been thought through, to find a string that does anything we want. Quotes, single quotes, and other special chars are easy to slip through and create major security holes. Buffer overflows could also be a problem... the command line can only accept a string of some finite length.
But while it's not ideal, it's not a huge security risk as long as there's some special safety considerations when handling user input. Here's a short list of security principles when using system calls:
After authentication and authorization is handled:
./simpletool $username
Now suppose someone creates a new user named "bill;rm -rf /" and passes it to a command line utility which executes:
./simpletool bill; rm -rf /
This will of course wipe everything out under /. Not good! It's not hard, if these interfaces have not been thought through, to find a string that does anything we want. Quotes, single quotes, and other special chars are easy to slip through and create major security holes. Buffer overflows could also be a problem... the command line can only accept a string of some finite length.
But while it's not ideal, it's not a huge security risk as long as there's some special safety considerations when handling user input. Here's a short list of security principles when using system calls:
After authentication and authorization is handled:
1. for all data, limit strings to a known set of characters
2. limit all strings to known sizes
3. limit all hashes of user input to known fields
4. avoid passing any data to the command line which isn't
programatically generated by you. If possible write user data to file, and pass your file names around. Otherwise, escape the data properly ... especially non-alpha-numeric chars like " ' ; \ ` $() which have meaning on the command line! Or better yet, just don't pass it on the command line.
5. escape all data that has special meaning (or could have special meaning) in the context in which it is used. For example, in a tab-delimited file, tab chars have special meaning.
6. limit file permissions to bare minimum ... nothing can be executable.
7. keep log of all interactions (leave the created files around for reference)
Friday, October 12, 2007
Using an SSL certificate for IIS under JBoss/Tomcat
If your certificate was requested for IIS, it will likely throw a pop up warning on pages if you install it under JBoss. Although there is a way to fix this.
For different servers, often the CA will use a different chain to sign your SSL cert. The only trick is to explicitly chain these together when building a keystore. This takes a little guesswork, but there are a limited number of intermediate and root certs.
To test out a configuration, it's probably best to add an entry in the local hosts file on the machine, and use a local (or development) server that can be started and stopped quickly.
For example, if it's a go daddy certificate, google for "go daddy root ca". You might get this page:
https://certificates.godaddy.com/Repository.go
Download them all for testing.
in my case, these worked:
intermediate: gd_intermediate.crt
root: gd-class2-root.cer
But overall, use the same instructions below as below:
For different servers, often the CA will use a different chain to sign your SSL cert. The only trick is to explicitly chain these together when building a keystore. This takes a little guesswork, but there are a limited number of intermediate and root certs.
To test out a configuration, it's probably best to add an entry in the local hosts file on the machine, and use a local (or development) server that can be started and stopped quickly.
For example, if it's a go daddy certificate, google for "go daddy root ca". You might get this page:
https://certificates.godaddy.com/Repository.go
Download them all for testing.
in my case, these worked:
intermediate: gd_intermediate.crt
root: gd-class2-root.cer
But overall, use the same instructions below as below:
Setting up SSL in JBoss/Tomcat with an Intermediate SSL CA
Verisign has switched to using a "intermediate" certificate authority (CA). These are a little tricker to install. The trick is getting the appropriate intermediate and root CA files from verisign, and "chaining" together into one file. Basically just concatenating them... one after the other with a header.
-----
General explanation ... Assuming you have these files:
* server.key - your certificate's private key
* server.crt - your certificate
* inter.crt - the intermediate CA that signed your certificate
* root.crt - the root CA that signed the intermediate CA
First, concatenate the CA certs. Be sure the intermediate CA goes first:
$ cat inter.crt root.crt > chain.crt
Next, export the pkcs12 file:
$ openssl pkcs12 -export -chain -inkey server.key -in server.crt\
-name "server" -CAfile chain.crt -out server.p12
You'll be prompted for a password ... this the the one referenced by the server.xml config .
Enter something ... don't leave it empty.
Now, you can use keytool to verify:
$ keytool -list -v -storetype pkcs12 -keystore server.p12
Requires the password entered above... Then you should see a line like:
....
Certificate chain length: 3
....
That's it. Since this is complex, Here's a simple script that should work, with minimal editing:
#!/bin/sh
# this script creates keystores for domains
# notes on script setup
# server_key - The file name of the private key for server.
# server_crt - The file name of the certificate for server.
# cert_name - Something unique, can be anything, just
# a friendly name.
# inter_crt - The file name of the intermediate
# certificate authority (CA)
# The intermediate CA can be downloaded from Verisign.
# although it might take a bit of googling to figure out where
# it is. Try searching for "Verisign intermediate certificate"
# for example.
# root_crt - The file name of the root certificate (from verisign)
# which signed the intermediate CA
# This either needs to be .cer or b64 format.
# The only difference is a header footer
# which may need to be added (see below echo's).
# The package of roots can be downloaded from verisign.
# Good luck guessing which one it is! :)
# Usually the error message ...
# or the certificate information in the browser will give a clue.
# Again, google for this. Try searching for (for example):
# "Verisign root certificate"
# chain_crt - The file name where intermediate and root
# is concatenated. Can be anything really.
# Well almost anything ...
# just don't overwrite some important system file :)
# out_file - The file name where the keystore file is saved
#set up your file paths and variables ...
server_key=yoursite.net.key
server_crt=yoursite.net.cert.2007
cert_name=yoursite_net
inter_crt=verisign_int_ca.cert
root_crt=../roots/VeriSign_Roots/Pca3ss_v4.b64
chain_crt=chain.crt
out_file=keystore_yoursite_2007.pkcs12
echo "creating $out_file ..."
echo "remember"
echo "1. Change owner and permissions"
echo "2. move to jboss/server/default/conf"
echo "3. update jboss/server/default/deploy/jbossweb-tomcat55.sar/server.xml"
echo "4. restart jboss"
echo ""
echo "on errors check $chain_crt ... certs should appear one after the other with header and footer."
echo "the second most likely problem is just having the wrong intermediate and root certs"
## clean up
# rm $out_file
# rm $chain_crt
# build chain certificate
cat $inter_crt > $chain_crt
# may need headers if simply b64
echo "-----BEGIN CERTIFICATE-----" >> $chain_crt
# might need extra line feed ... check $chain_crt
# echo "" >> $chain_crt
cat $root_crt >> $chain_crt
# may need footer if simply b64
echo "-----END CERTIFICATE-----" >> $chain_crt
# create keystore
openssl pkcs12 -export -chain \
-inkey $server_key \
-in $server_crt \
-name $cert_name \
-CAfile $chain_crt \
-caname root \
-out $out_file
-----
General explanation ... Assuming you have these files:
* server.key - your certificate's private key
* server.crt - your certificate
* inter.crt - the intermediate CA that signed your certificate
* root.crt - the root CA that signed the intermediate CA
First, concatenate the CA certs. Be sure the intermediate CA goes first:
$ cat inter.crt root.crt > chain.crt
Next, export the pkcs12 file:
$ openssl pkcs12 -export -chain -inkey server.key -in server.crt\
-name "server" -CAfile chain.crt -out server.p12
You'll be prompted for a password ... this the the one referenced by the server.xml config .
Enter something ... don't leave it empty.
Now, you can use keytool to verify:
$ keytool -list -v -storetype pkcs12 -keystore server.p12
Requires the password entered above... Then you should see a line like:
....
Certificate chain length: 3
....
That's it. Since this is complex, Here's a simple script that should work, with minimal editing:
#!/bin/sh
# this script creates keystores for domains
# notes on script setup
# server_key - The file name of the private key for server.
# server_crt - The file name of the certificate for server.
# cert_name - Something unique, can be anything, just
# a friendly name.
# inter_crt - The file name of the intermediate
# certificate authority (CA)
# The intermediate CA can be downloaded from Verisign.
# although it might take a bit of googling to figure out where
# it is. Try searching for "Verisign intermediate certificate"
# for example.
# root_crt - The file name of the root certificate (from verisign)
# which signed the intermediate CA
# This either needs to be .cer or b64 format.
# The only difference is a header footer
# which may need to be added (see below echo's).
# The package of roots can be downloaded from verisign.
# Good luck guessing which one it is! :)
# Usually the error message ...
# or the certificate information in the browser will give a clue.
# Again, google for this. Try searching for (for example):
# "Verisign root certificate"
# chain_crt - The file name where intermediate and root
# is concatenated. Can be anything really.
# Well almost anything ...
# just don't overwrite some important system file :)
# out_file - The file name where the keystore file is saved
#set up your file paths and variables ...
server_key=yoursite.net.key
server_crt=yoursite.net.cert.2007
cert_name=yoursite_net
inter_crt=verisign_int_ca.cert
root_crt=../roots/VeriSign_Roots/Pca3ss_v4.b64
chain_crt=chain.crt
out_file=keystore_yoursite_2007.pkcs12
echo "creating $out_file ..."
echo "remember"
echo "1. Change owner and permissions"
echo "2. move to jboss/server/default/conf"
echo "3. update jboss/server/default/deploy/jbossweb-tomcat55.sar/server.xml"
echo "4. restart jboss"
echo ""
echo "on errors check $chain_crt ... certs should appear one after the other with header and footer."
echo "the second most likely problem is just having the wrong intermediate and root certs"
## clean up
# rm $out_file
# rm $chain_crt
# build chain certificate
cat $inter_crt > $chain_crt
# may need headers if simply b64
echo "-----BEGIN CERTIFICATE-----" >> $chain_crt
# might need extra line feed ... check $chain_crt
# echo "" >> $chain_crt
cat $root_crt >> $chain_crt
# may need footer if simply b64
echo "-----END CERTIFICATE-----" >> $chain_crt
# create keystore
openssl pkcs12 -export -chain \
-inkey $server_key \
-in $server_crt \
-name $cert_name \
-CAfile $chain_crt \
-caname root \
-out $out_file
Setting up SSL in JBoss/Tomcat
For whatever reason, I think setting up SSL in JBoss is a major pain. It's hard to find good documentation, and the steps that are required seems over-complicated.
For now, JBoss / tomcat only supports JKS (the format java had to invent) and PKCS12 format (which is somewhat of the general standard). JKS is better supported in java tools, PKCS better supported generally outside java. So, ptobably painful either way. I'd recommend PKCS12.
REQUIRED TOOLS:
openssl -- for windows users, i installed this tool under cygwin
REQUIRED FILES:
cert and key files from these will need to be converted into a keystore file for jboss/tomcat.
HOWTO:
1. convert these two files into a pkcs12 file ... this will prompt for a password.
openssl pkcs12 -export \
-in YOUR_CERT_FILE.cert \
-inkey YOUR_KEY_FILE.key \
-out keystore.pkcs12
2. config jboss/tomcat.
you'll need to edit this file (tomcat 5)
jboss/server/default/deploy/jbossweb-tomcat50.sar/server.xml
and uncomment the lines that refer to SSL.
note, ny default, jboss is configured for port 8443.
by default, https: goes over 443, similar to http over 80.
The configured settings might look like:
<Connector port="443" address="${jboss.bind.address}"
maxThreads="100" minSpareThreads="5" maxSpareThreads="15"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/keystore.pkcs12"
keystoreType="PKCS12" keystorePass="" sslProtocol = "TLS" />
3. meta security
save any copies of the key and cert as root:root, with 400 permissions.
the keystore file should have as few permissions as needed to run.
In Linux, as a security precaution built into the kernel, only the root user can bind to a port below 1024. this means that either,
A. you leave the port set at 8443. of course, since this is not the defualt port, it will need to be specified in all URL requests. or,
B. configure the server for 443, and run the server as root, (not recommended for production server) or
C. might use iptables to route traffic from 8443 to 443.
FOR MORE EXAMPLES SEE:
http://mortbay.com/jetty/faq?s=400-Security&t=ssl
http://tomcat.apache.org/tomcat-5.0-doc/ssl-howto.html
http://mail-archives.apache.org/mod_mbox/tomcat-users/200409.mbox/%3C4150BB34. 3010905@ddai.net%3E
For now, JBoss / tomcat only supports JKS (the format java had to invent) and PKCS12 format (which is somewhat of the general standard). JKS is better supported in java tools, PKCS better supported generally outside java. So, ptobably painful either way. I'd recommend PKCS12.
REQUIRED TOOLS:
openssl -- for windows users, i installed this tool under cygwin
REQUIRED FILES:
cert and key files from these will need to be converted into a keystore file for jboss/tomcat.
HOWTO:
1. convert these two files into a pkcs12 file ... this will prompt for a password.
openssl pkcs12 -export \
-in YOUR_CERT_FILE.cert \
-inkey YOUR_KEY_FILE.key \
-out keystore.pkcs12
2. config jboss/tomcat.
you'll need to edit this file (tomcat 5)
jboss/server/default/deploy/jbossweb-tomcat50.sar/server.xml
and uncomment the lines that refer to SSL.
note, ny default, jboss is configured for port 8443.
by default, https: goes over 443, similar to http over 80.
The configured settings might look like:
<Connector port="443" address="${jboss.bind.address}"
maxThreads="100" minSpareThreads="5" maxSpareThreads="15"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/keystore.pkcs12"
keystoreType="PKCS12" keystorePass="" sslProtocol = "TLS" />
3. meta security
save any copies of the key and cert as root:root, with 400 permissions.
the keystore file should have as few permissions as needed to run.
In Linux, as a security precaution built into the kernel, only the root user can bind to a port below 1024. this means that either,
A. you leave the port set at 8443. of course, since this is not the defualt port, it will need to be specified in all URL requests. or,
B. configure the server for 443, and run the server as root, (not recommended for production server) or
C. might use iptables to route traffic from 8443 to 443.
FOR MORE EXAMPLES SEE:
http://mortbay.com/jetty/faq?s=400-Security&t=ssl
http://tomcat.apache.org/tomcat-5.0-doc/ssl-howto.html
http://mail-archives.apache.org/mod_mbox/tomcat-users/200409.mbox/%3C4150BB34. 3010905@ddai.net%3E
Subscribe to:
Comments (Atom)