Web forms with digital signatures provide a secure way to meet the authentication requirements of e-commerce apps.

November 01, 2004
URL:http://www.drdobbs.com/jvm/secure-web-forms-struts-extensions/184405885

Hari is a technical architect for Infosys Technologies Limited. He can be contacted at [email protected].

The role of the Web continues to grow in terms of commerce, banking, and enterprise financial applications. Privacy, authenticity, integrity, and nonrepudiation are key requirements to be addressed by such web applications where a face-to-face interaction is not possible. Privacy (confidentiality) is generally addressed through a secure communication protocol like Secure Sockets Layer (SSL). However, SSL does not address message nonrepudiation.

Nonrepudiation is the process of ensuring that the participants in a communication don't deny their commitments at a later time. In a paper-based world, nonrepudiation is addressed through handwritten signatures and receipts. Many web-based solutions use logs and audit trials to achieve this. But as audit logs cannot withstand as valid legal proof, service providers typically enter into private service agreements with users of systems to protect their interests. However, most of these service agreements generally claim no liability of service providers in case of any loss.

Digital signatures are a proven solution to address authentication and nonrepudiation. Digital signatures are based on public key cryptography and are electronic equivalents of handwritten signatures. Many countries have standardized the use of digital signatures into their legal infrastructure. However, currently not many web applications use digital signatures. From a developer's perspective, there are three primary reasons for this low adoption of digital signatures on the Web:

• Lack of a uniform client-side technology to digitally sign transaction-related text on the Web.
• Lack of direct support for digital signatures in popular web application frameworks.
• Lack of awareness among the developer community on browser support for digital signatures.

To popularize the adoption of digital signatures into web applications, we need a uniform cross-browser digital signature library, possibly delivered as an integral feature of web application frameworks. In this article, I introduce one approach—secure web forms that provide a simple way of using digital signatures in web applications built using the Struts framework. A secure web form is a standard web form with contents that are digitally signed. Secure web forms provide form-level authentication and nonrepudiation.

Digital Signatures

Digital signatures let recipients of information verify the authenticity of the information's origin, integrity of content, and provide a mechanism for nonrepudiation. Fundamentally, a digital signature serves the same purpose as a handwritten signature.

Creating digital signature involves several steps, as illustrated in Figure 1:

1. Sender (signer) calculates a mathematical summary (also called "hash code/ message digest") of the data to be signed. This hash code is a unique digital fingerprint of the data to be signed.
2. Sender encrypts (signs) the digest generated in step 1 with the sender's private key. This encrypted digest forms the digital signature of the sender for that data.
3. Sender appends the signature generated in step 2 to the actual data to form a digitally signed message.

Likewise, digital signature verification involves several steps, as in Figure 2:

1. Recipient takes data part of received message and generates a digest at its end running the same hashing algorithm.
2. Recipient decrypts signature part of signed message using the sender's public key to retrieve the digest sent by sender.
3. Recipient compares the digests from the above two steps.

If both digests match, then the data has not been altered. The recipient also knows that the correct sender has signed the data because only the sender has access to the corresponding private key used for this signature. This proves authenticity of source. Digital signatures stored persistently along with transactional data can be used as nonrepudiation proof.

(A general misconception is that digitally signed transactions provide confidentiality of data also, which is not true. Digitally signed data is just like a paper with a handwritten signature. Anyone can read the content but everyone knows who the owner of the content is by verifying that signature. As we do protect sensitive content on paper by properly sealing it in an envelope, encryption has to be applied on top of digitally signed data to protect it from intruders.)

Browser Support For Digital Signatures

Digital signatures are typically supported in Internet Explorer through COM components. Microsoft's CAPICOM COM component provides wrapper functionality for high-level digital signature creation/verification, as well as support for encryption/decryption and certificate management functionality. This uses the underlying Microsoft Cryptography API (CAPI). CAPICOM can be easily used in scripting languages such as JavaScript, VB Script, and the like to build secure web form applications (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/ Security/capicom_reference.asp).

CAPICOM supports digital signatures in PKCS#7 format. PKCS#7 (Cryptographic Message Syntax Standard) provides general syntax for representing data that may have cryptography applied to it, such as digital signatures and digital envelopes. Public Key Cryptography Standards (PKCS) are specifications produced by RSA Labs in cooperation with worldwide security experts and vendors and they are widely supported by major vendors (http://www.rsasecurity.com/rsalabs/pkcs/).

Netscape introduced a JavaScript function called crypto.signtext(...) with Netscape 4.04 (and higher) that lets users digitally sign web forms (http://developer .netscape.com/docs/manuals/security/sgntxt/index.html). This function works only with early versions of Netscape browsers (< 6.0). The crypto.signText method lets a JavaScript script ask users to digitally sign text strings. If the user approves the operation, signText returns a base-64-encoded PKCS #7 signed object.

Because this feature is missing in newer versions (6.0+) of Netscape browser, web application developers who want to develop cross-browser secure web form applications are limited in what they can do. However, this gap is filled by Mozilla's open-source SECCLAB component, which is a Cross Platform COM (XPCOM) component that implements a clone of the crypto.signText function named CLABSignString. SECCLAB is available for all flavors of Netscape browsers on all major platforms and can be downloaded from Mozilla's SECCLAB site (http://secclab.mozdev.org/installation.html).

Design Details

Browser support for digital signatures is nonuniform and inconsistent across different browser versions. This constrains developers needing to develop cross-browser secure web forms due to the specializations in each implementation, besides learning the digital signature concepts. A cross-browser JavaScript library providing these functionalities, yet hiding all the variations, would be useful.

With this in mind, I developed just such a JavaScript library called "signscript.js." This library consists of functions wrapping up Microsoft's CAPICOM and Mozilla's SECCLAB functionalities. The main features the library includes are:

• fsSignData (tbsForm, signatureHolder), called by the form to initiate the signing process. It detects the client browser type and internally calls the appropriate signing function. The first argument, tbsForm, holds the HTML FORM. The second attribute, signatureHolder, is the hidden variable that receives the PKCS#7 signature.
• fsClientBrowser returns the client browser type. fsGetTBSData(tbsForm) returns the string representation of the HTML FORM field values entered by the client. This concatenates user-entered FORM field values and returns it. The returned string is the actual data that will be digitally signed. Fields currently recognized by this function include text, textarea, password, select-box, checkbox, and radio button. This does not currently support File and Button fields.
• fsIsCAPICOMInstalled determines if the Microsoft CAPICOM component is installed on the client machine.
• fsCapicomSignData(tbsData) instantiates the CAPICOM component objects and gets the data signed by CAPICOM in Microsoft IE. The lone argument tbsData is the actual data to be signed.
• fsNSSignData(tbsData) is responsible for getting the digital signature in Netscape browsers using SECCLAB components' functionality. The lone argument tbsData is the actual data to be signed.

The other functions display errors (fsShowError(message, reason)), get user confirmation (fsIsConfirmed(title,message,note)), and convert the raw signature to Base64-encoded format (fsBase64ToAscii(c), and so on).

I've tested the library with IE 6.0 and Netscape 7.0 browsers on Windows XP. It should work smoothly for different versions of these browsers on other platforms provided the appropriate environments (suitable versions of CAPICOM and SECCLAB plug-in) are available on client machines.

Listing One demonstrates a sample web-based leave application that uses this cross-browser library. The complete working example (js-leaveform.jsp) is available electronically; see "Resource Center," page 5. Listing One shows how a secure web forms application can be developed. You only need to call a single function (fsSignData) and define one additional hidden variable to hold digital signatures.

When this power is delivered as part of a popular web framework, it reaches most developers; hence, more secure web applications are possible. Consequently, I decided to integrate this JavaScript library with Jakarta's Struts Web Application Framework.

Struts

Jakarta Struts is an open-source framework for building web applications with Java Servlet and Java Server Pages (JSP) technologies (http://jakarta.apache.org/struts/). It encourages software development to follow the MVC design pattern, which divides applications into three main components:

• The Model is the representation of the data and state of the application.
• The View handles the representation of model to users.
• The Controller lets users interact with applications.

In Struts, the View is handled by JSPs and a set of presentation components such as tag libraries, the Model is represented by JavaBeans, and the Controller uses servlets to perform actions. The core of the Struts framework is a flexible control layer based on standard Java and XML technologies.

As secure web forms require client-side user interaction, the Struts View component forms a natural choice for integrating the client-side JavaScript library into Struts.

Struts distribution includes a comprehensive JSP HTML tag library that provides support for interacting with input forms. These tags let you define HTML forms, checkboxes, input text fields, text areas, radio buttons, and the like. From Listing One, you can see that integration requires two things be done:

• Calling JavaScript library's fsSignData function in HTML form's onSubmit event.
• Defining a hidden variable to receive PKCS#7 digital signature.

HTML TagLib's form tag handles the rendering of HTML forms in the Struts framework. I introduced a new tag called signform that extends the functionality of the form tag to handle the just mentioned changes. For this, I created a new Java Class called SignFormTag in the org.apache.struts.taglib.html package that extends and overwrites some of the methods of the class FormTag, which is also in the same package. Methods renderFormStartElement() and renderSignFormScript() are overwritten to call the fsSignData function on HTML form's onsubmit event handler. Method doEndTag() is overwritten to introduce the hidden variable that receives the returned digital signature. Figure 3 depicts the UML class diagram.

This tag creates the hidden variable <formname>_signature into which the digital signature is stored. For example, if the form name is leaveform as defined in Listing One, this tag introduces a hidden variable named leaveform_signature, which can be accessed in the server-side script (Controller).

Further, the SignForm tag generates a JavaScript function named <formname_sign(form, sigHolder)>, where formname is the name of the form defined as part of the <html:signform> tag. form and sigHolder are variables representing HTML form and hidden variable to store a digital signature, respectively. It also creates a suitable form onsubmit event handler that calls the formname_sign function when users press the Submit button on form. Any onSubmit function that is defined as part of the Struts framework will be internally called by this new generated function. This is done behind the scenes and Struts developers are completely oblivious from this. The only modification that you have to do is to use the <html:signform> tag in place of the <html:form> tag to design signed web forms. This greatly simplifies the development effort required to create secure web form applications. Listing Two demonstrates the aforementioned leave example in Listing One, but is now using the extended Struts framework.

Listing Two shows that you can now directly design secure web forms without any prior knowledge of digital signatures and browser PKI features.

Limitations

There are a few limitations in the current version of this system:

• The FORM has to be defined using the <html:signform> tag and should contain a Submit button defined using <html:submit/>. An HTML form without a Submit button does not support digital signatures. This is primarily because the signing function fsSignData is called on Form's onSubmit event handler.
• The onsubmit handler (if any) declared by developers must contain only a single JavaScript function. Any additional JavaScript statements defined will be ignored by the signform tag.
• The JavaScript function defined by developers as part of the onsubmit event handler should have only absolute parameters as its arguments. For example, consider a specific client validation is needed on the HTML form and implemented as myValidation(form) where form is the HTML FORM variable. For this FORM to be digitally signed using this framework, this has to be represented as in Listing Three(a). Listing Three(b) is incorrect because this cannot be used as an argument in the onSubmit event handler.

This framework can be used in any potential web application that requires message-level authentication such as e-commerce applications. This can also be used as a potential mechanism to build a PKI-based login authentication mechanism.

I've only presented the client-side framework here. For this to be complete, a server-side component has to be developed to receive and verify the digital signatures on form submission. This work includes building certificate path validation, certificate status verification against a published CRL and/or online certificate status protocol (OCSP), and so on. Struts form validation parts are a good place to integrate such a server-side digital signature verification framework into.

Conclusion

Web forms using digital signatures are a more secure way of addressing the authentication, integrity, and nonrepudiation requirements of many e-commerce and e-business applications. Secure web forms delivered as an integral feature of Struts allow easy development of web applications that run in different browsers on multiple platforms. Secure web forms do not require you to be aware of digital signature concepts. They help in drastically reducing the development time required for building web-based PKI solutions.

Acknowledgments

Thanks to Deependra Moitra, Dr. Srinivas Padmanabhuni, Naqvi Khushnood, Abhijit Belapurkar, Raghavan S., and Anirban Chakrabarti of Infosys Technologies Limited for their valuable feedback.

DDJ

Listing One

 ...
 ...
<!-Use of OBJECT tag in HTML to access Microsoft CAPICOM component -- >
<object
       id="oCAPICOM"
       classid="clsid:A996E48C-D3DC-4244-89F7-AFA33EC60679"
       codebase="capicom.cab#version=2,0,0,0">
</object>

<!-Inclusion of signscript library into HTML -- >
<script src="signscript.js"></script>

</head>
<body bgcolor="#ffffcc">

<!- calling signing functionality on the form's onSubmit event -- >

<form action="js-leaveprocess.jsp" method="post" name="leaveform" 
                    onsubmit='return fsSignData(this,this.signatureData);'>
 ...
 ...
 ...
<!- Hidden variable that holds the PKCS#7 signature datat -- >
<input type="hidden" name="signatureData" value=""> 
 ...
 ...
 ...
</body>
</html>

<! - including appropriate tag libraries.  In this case 
     struts -html.tld is updated with signform tag information as well-- >
<% taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<% taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>

<html:html>
<head>
<title>Eazy Leave - Struts Sample</title>

</head>
<body bgcolor="#ffffcc">
<html:errors/>
 ...
 ...
 ...
<! - defining signform tag -- >

<html:signform action="/leave"
    name="leaveForm"
    type="com.infosys.strutsample.eazyleave.LeaveForm"
    >
 ...
 ...
 ...
<! - closing of signform tag -- >
</html:signform>

</center>
</body>
</html:html>

<html:form action="/actionname"
        name="formName"
        type="actionType"
onSubmit="myValidation(document.formName) ">

<html:form action="/actionname"
        name="formName"
        type="actionType"
        onSubmit="myValidation(this)">

Figure 1: Creating digital signatures.

Figure 2: Verifying digital signatures.

Figure 3: SignForm tag's class diagram.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.