CF: New version of BonCode PGP library released

I had a few request to look into the PGP library I released for ColdFusion and Railo last year. It took me a while to understand my own code, then, a while longer to implement the features that I wanted to add ;o)

The main add on this time is the ability to create single pass signed files. This allows you to create a file where you are assured that only the authorized receiver can read them, while the receiver is assured that the sender is authentic as well.  Yep, I know sound like cold-war stuff, but it is quite common scenario in financial exchanges to assure both sides that everything is the way it should be.

To a lesser level some other additions and bug fixes were completed as well.
All this, as usual is open source.

You can download code, examples, and implementation from here:

https://github.com/Bilal-S/cfpgp/releases/tag/2.0.0



Best,
B.

CF: Setting up the OWASP ESAPI Library for use with ColdFusion and Railo

If you are taking application security seriously or have been curious about it you know by now that the native tools built into ColdFusion and Railo are not sufficient to hinder the serious hacker from making headway.

To truly use best practices you can do a lot of code development, or, fall back to a project that has already proven its merit through many years of practical use.

I am referring to the OWASP Enterprise Security API (ESAPI). Unfortunately, getting this puppy running in any shape requires some reading muscle and some luck and some powers of deduction.

I am summarizing here the findings, so you don't have to run through the maze of options and boiling it down to something simple.

First, you will have to download the jar file (as of this writing it would be esapi-2.0.1). The download is around 14MB but you only need the esapi-2.0.1.jar file. Copy the jar file to (backup any esapi file that already exists in there first):
[cfroot]/wwwroot/WEB-INF/lib in Adobe Coldfusion.
WEB-INF/lib in Railo

Then, download a good ESAPI.properties file. Most of my head banging and hair ripping surrounds finding the property definitions. Can't stress this enough. Start with the one from source code it has good comments. Go through this file carefully and make needed changes. Make sure all directories referenced in the properties file actually exist on your drive system and also change default Encryptor.MasterKey and Encryptor.MasterSalt to something you are comfortable with, e.g. do not use something like this:


Encryptor.MasterKey=changeme
Encryptor.MasterSalt=blah

After you made changes save it (e.g. c:\esapi\files).

Thirdly, make environment start up changes.
If you are using Adobe Coldfusion you will need to change the JVM startup properties in CF Administrator to add a property and point to place where you placed ESAPI.properties file. E.g.:
-D org.owasp.esapi.resources=c:\esapi\files

For Railo, the above is done in Tomcat/Jetty startup parameters.

Fourthly, change classpath (Yep, you heard right change JAVA classpath): Add the directory you placed the properties file in to Java classpath. This is something that had me stumped as well.

After all of the above, give your server a good schake (restart), and then test whether all works.
Simple code snippet:

<cfset esapi = CreateObject("java","org.owasp.esapi.ESAPI")>

<cfset encoder = esapi.encoder()>

<cfoutput>

 <cfset myInput="<script>some input for html context; 

  alert('doing something you don't want');</script>">

  #now()# <br/>

  #encoder.encodeForHTML(JavaCast("string", myInput))#

</cfoutput>

The good news is that Adobe is looking into bundling this in the future so you don't have to. However, in the meantime this is good practice ;o)

Best,
B.

Internet Explorer and the case of the vanishing Forms

So we ran into the problem of a customer's users' not being able to use our application. The users happen to use Internet Explorer and IIS (Internet Information Server) and the behavior was intermittend.
We thought, this is a network issues for sure; so we put sniffers on client and servers sides and observed that nothing was conclusive.
Another thing that threw us was that using an alternate browser such as Chrome everything seemed to be working.
When things did not work, however, we saw that IE (version 6 through 9) would not send any HTTP form information along. So even with simple HTML page that had two form fields "FirstName" and "LastName", we would see through the protocol capture that IE started an HTTP post, but no form fields and values. They had vanished. Poof !
Our further suspicion of maybe a plugin, proxy or firewall stripping this data out was also eliminated and we started staring at each like we are all going crazy. And, of course, we googled. Nothing there either. (Google, oh Google, why did you fail us!)...
Then, a little break, we discovered, that everytime things stopped working and Forms started vanishing, the user had just entered a secured area of the site and returned to an unsecured area. The security access was transparent as IIS was setup to use "Windows Authentication" similar to "Integrated Authentication"; thus, IE was doing this in the background. Thereafter, even if the user returned to the non-secure areas of the site, IE would refuse to send Form data. After more digging we found that this seems to be intentional; we even found an old web-page that descibed this as good feature for IE6. The behavior is this: after, IE authenticates to a site via NTML / Kerberos (i.e. some integrated way), all traffic to that site has to be secured and as part of the security mechanism no plain text form submission is allowed. Great !
The solution to this was to move the secure portions to a seperate site on IIS and thus everything started working as it should. IE was happy, customer was happy, and we could go to sleep.

Hope you don't have to spent as much time on troubleshooting knowing this.

B.