A Novel Client-Based Approach for Signing and CheckingWeb Forms by Using XML Against DoS Attacks

Kaziim Sarikayaa, Duygu Sarikayaa, Tamer N. Jaradab, Shang Gaob

Tansel Özyera and Reda Alhajjb,c

aDept of Computer Engineering bDept of Computer Science cDept of Computer ScienceTOBB ETÜ University University of Calgary Global University

Ankara, Turkey Calgary, Alberta, Canada Beirut, Lebanon

ABSTRACTIn parallel to rapid growth of internet technologies, secu-rity becomes more critical in various real life applicationssuch as e-finance, e-health, and e-government. These appli-cations strictly require data authentication mechanisms. Toaddress this essential issue, we grasp the idea of client basedauthenticity for interactive web technologies. We proposed anovel client based web form signing and checking with XMLdata structure method. Our method specifically uses XMLstructure for the involvement of data exchange between webapplications. Our method curbs the DoS (Denial of Service)attacks for protection of the server. In order to illustrate ourideas, we adapted our digital signature mechanism on healthrelated forms with two commonly used web browsers.

KeywordsXML, Web forms, client puzzle, digital signature, DoS (De-nial of Service)

1. INTRODUCTIONThe recent advances in web technologies alleviated users

to work in an interactive and dynamic way. Web users havebecome active participants on the internet. They share data;send and receive. Regardless of some specific platforms andarchitectures it is the main concern that dynamic web formsare utilized for this purpose. In this way, all the requireddata are exchanged. At the same time, this approach has-sles with some problems as system security and reliabilitymostly.

There is an inherent risk of data to be lost, stolen, deleted,or broken during the transmission. In case the data hasn’tbeen accurately received by the right receiver, there may beseveral reasons: It might have been received by the wrongparty; or data might have been received after it has beenconfiscated by the third party. Critical and private dataneed security prominently. This is the by-product of the

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.iiWAS2010, 8-10 November, 2010, Paris, France.Copyright 2010 ACM 978-1-4503-0421-4/10/11 ...$10.00.

content of especially medical information, research data, in-vestment decisions for a company, data and customer profilesbelonging to various business enterprises and foundationslike banks and hospitals.

When the critical data is stolen by unauthorized people,the system is no longer secure and reliable. In additionto stealing some information, an impostor can introducehim/herself as the real person and make operations on be-half of the information holders. In lights of these problems,we can easily claim that the security and reliability in webapplications bear importance.

Messages are transmitted through insecure channels andsecurity problems can be solved by digital signatures thatare sent by clients. In this way, the receiver is convincedto believe the message was sent by the real person. Digitalsignatures are equivalent to handwritten signatures on paperand less susceptible to forgery.

On the Internet, digital signatures [11] are transferred invarious formats. Among them, p7m and p7s formats areused widely. In the case of the p7m format. the message iscarried with the signature, while in the case of the p7s formatonly the signature itself is carried. S/MIME [5] (Secure /Multipurpose Internet Mail Extensions) function, which istoday broadly used in most email applications, is a standarddeveloped to provide public key encrypting and signing theemails encapsulated with MIME.

S/MIME provides services such as authentication, mes-sage integrity, privacy, data security as well as preventingdenial of the source. S/MIME defines pkcs 7 - mime as theformat of data encryption. The MIME element, which isbasically the data, is encrypted and packaged in an objectenclosed in the pkcs-7 mime application before being encap-sulated.

The forms filled by the client are posted to the serverafter being signed in various ways. Today, a variety of algo-rithms are used for encrypting and signing web forms. RSA,DES/3DES, BLOWFISH, IDEA, SEAL and RC4, GOST28147-89, Serpent, AES, CAST are some of the algorithmsused for this matter while RSA and DSA algorithms are themost used algorithms for signing.

It is very advantageous that client side applications runat the machines of users; and the server only steps in whenit is necessary. This means when most of the operations areprocessed in a client side fashion, the overhead on the serverdecreases, so that it is made possible for the server to workmore efficiently and response to all the clients in a shorterperiod of time.

iiWAS2010 Proceedings Security Issues

202

Digital signatures at client site get over the security prob-lem and processing overhead but yet another problem arises:sometimes malicious people commit DoS attacks [1] to ob-struct the function of the servers temporarily or perma-nently. These attacks usually cause an overhead on theserver by sending automatic and continuous requests, whichlead to the consumption of the resources such as disk area,processor and bandwidth. They keep the server busy, whichlead to the situation that the functions of the server are para-lyzed temporarily or permanently. In order to prevent thesemalicious attacks, the clients could be given extra overheadbefore the interaction with the server. It is made possibleto prevent the automatic attacks as well as transferring theoverhead of this function to the client instead of the server.One of the methods to provide this is to give ”client puz-zles”. Different studies have adopted the idea of using clientpuzzles in [2], [3], and [4].

Based on the points mentioned above, it is possible to useClient puzzles to prevent DoS attacks against the server.The reason for using client puzzles is to make all the clientssolve mathematical puzzle before the connection or at thestages when data transfer occurs densely. The aim of solv-ing the client puzzles, which are usually not complicated, isto make the client consume a period of time before carry-ing on the client’s request. This situation will cause datatransmission to decrease rather than having an insecure andunreliable medium.

The rest of this paper builds on the above overview ofthe problem. Section 2 briefly covers the related technol-ogy. Section 3 summarizes the proposed solution. Section 4presents the system description. Test results are reported inSection 5. Section 6 is conclusions and future research.

2. RELATED TECHNOLOGIESTwo web browsers that are popular and commonly used

by large number of people are Internet Explorer and Firefox.Here, we describe the related technologies.

OpenSSL [7] provides a general-purpose cryptographic li-brary as well as being a toolset that is implemented on thebasics of SSL (secure socket layer v2 / v3) and TLS (trans-port layer security v1) protocols. It is possible to use thebasic cryptographic and standard functions in various com-puter languages with the help of this open source applica-tion.

JavaScript is a scripting language generally used in client-side web applications. The crypto object that is added inthe year 1997 with JavaScript version 1.2 by the NetscapeNavigator provides access to the browser’s encryption fea-tures. With this improvement, Windows objects have begunto nestle crypto objects. JavaScript, whose usage area keepsgrowing up, is today used in adaption of graphic interfacesand most plug-ins of the Firefox browser which is developedby Mozilla platform.

VisualBasic Script is a language like JavaScript. It is usedby Microsoft products like Internet Explorer. It is more flex-ible than JavaScript if ActiveX components are used insidescripts. Base64 coding format ensures the binary data to betransferred and saved only by using ASCII characters. Atthe coding stage, 3-byte data is distributed in 6-bit quartetgroups. Every one bit group generates a number between 0and 63 (26=64). Every number is ensured that it matchedan ASCII character according to the matching rules in thetable defined. The length of the base64 coding is always as

many as multiples of 4, otherwise invalid. In this case, theoutcome is completed to multiples of 4 by appending ’=’characters at the end.

ASP.NET is a server-side scripting language which is gen-erally used to create dynamic and interactive web pages.Also, it contains a lot of API for programming.

It is possible to use OpenSSL with ASP.NET as well asFirefox. OpenSSL gives a widespread of functionalities forsecurity operations.

CAPICOM is an API that can be used in Internet Ex-plorer and ASP.NET. It provides several security functional-ities. Signing at Internet Explorer and verifying at ASP.NETCAPICOM is used. On the other hand, Firefox uses itsembedded OpenSSL functions. Internet Explorer lacks anyfunction for signature; CAPICOM ActiveX components canbe used for security functions. CAPICOM is also being usedfor signature verification.

2.1 Related WorkA framework for client based digital signature for web

forms has been introduced in [10]. XML documents can beencrypted and signed while being transferred. Reference [6]demonstrates a research about this matter. Ekelhart atal. [17] provides an overview of XML security issues; XML-based control aspects are discussed in [18, 24] by Abadi et al.and Murata et al.; in [19] a language support mechanism isintroduced in operational models; Thuraisingham integratesthe standards for the semantic web in [20]. With regard tothe data sources, [21] discusses the protection of XML datasources; Kleiner et al. [22] and Carminati [23] focus on theprotocol issues with web services from both client and serversides. Marmol et al. [25] illustrates scenarios for securitythreats in distributed system environment in general.

3. SUMMARY OF THE SYSTEMIn this study, we aim to develop a system capable of pro-

viding the security for the content of client web forms andmaking the signing process work on the client browser. Atthe same time, it prevents the delivery of missing/incompleteor authentically unverified data. Its advantage is the avoid-ance of misused network (server resources such as band-width, request buffer, etc.). The DoS attacks carried outby saboteurs in an automatic fashion are blocked.

Our system works as follows:

• Client requests, our system can start with a preparedpuzzle to be solved by the client. One similar typeof client puzzle is the second puzzle algorithm men-tioned in [8]. The difference between the abovemen-tioned study and this research is that our method doesnot generate a client RSA key. This puzzle is optionaland it is used for DoS attacks.

• The first n bits of the randomly generated number arewithheld and the remaining bits and the hash of therandomly generated number are sent to the client.

• Before signing the form, the client solves the puzzle.It composes an XML file consisting of form elementcontents and the solution of the puzzle attached.

• The hash value of the file content is computed andsigned. The XML file is sent to the server with theproduced signature. The server verifies whether the

Security Issues iiWAS2010 Proceedings

203

solution is correct or not. If correct, next, the correct-ness of the digital signature is verified.

4. SYSTEM DESCRIPTIONThe general overview of the system is depicted in Figure 1.

According to this figure, there are two parties, client andserver. Messages are transmitted in enumerated order.

Figure 1: - Overview of Message Traffic Betweenclient and server

The steps 1-2, 3-4, 5 in Figure 1 are further analyzed inthe next section.

4.1 Random Number GenerationIn our system, the server uses OpenSSL [12] to generate

random numbers. OpenSSL provides a library for imple-menting SSL (Secure Sockets Layer) and TLS (TransportLayer Security). A variable byte random number is gener-ated. The generated number is hashed with SHA-256 (Se-cure Hash algorithm) function that is compatible with UTF-8 encoding; Assume the value of hashed number is M, whichis N bits.

M is separated in two parts T and P. The length of T is nand the length of P is N-n bits. For encoding P is completedwith zeros at the left side to make the length of P divisiblewith 8.

Figure 2: Random Number Generation

The (M,T) pair is saved at the server and (M,P) is sentto the client. The composition of the puzzle is done at theserver side. The entire processes regarding the preparationof the puzzle and sending it to client are given in Figure 2.

4.2 Puzzle Solving and Form SignatureIn our study, we have implemented the methods to gather

all the data within a form entered by the client, then sign andsave them properly. According to this, data is carried by thegeneral form elements and the file contents that the clientuploads by using the form as binary data; and it is addedto the form data and signed together. This part has beenimplemented with both JavaScript and Visual Basic Script.

It is necessary to solve the client puzzle before signing theform if it exists. Solving the client puzzle is done as follows:

iiWAS2010 Proceedings Security Issues

204

Figure 3: - Message 3: Puzzle Solving

• The server sends the hash value of the bit number withthe known bits of remaining part, which is coded inbase64 in the form.

• In order to solve the puzzle, the client gains the partthat does not contain added zeros.

• The client produces an array of bits which contains allzeros to make an estimate of the bit number.

• Then, this array is combined with N minus n bits inevery increase of the number represented by the arrayelements.

• The hash of the N bits produced are calculated andcompared to the hash sent by the server. This op-eration continues until the n bit is found. The stepstaking place in this part are shown in Figure 3.

• After the n bit is found, the transformation of the webform to the XML document is done. The JavaScriptfunction that has been implemented for transformationscans all the form elements according to their parent-child relations and takes the element types, their ids,the values in their fields and then wraps them in therelated xml element’s name, the value (which is codedwith URI and base64 encodings). This wrapping isdone according to the specification below:

For the Text, password, hidden (the ones not re-lated to the client puzzle), textarea elements<element id type=”text”> value </ element id>

For Select<element id type=”list”><values> <value0> se-lected value0 </value0></values></element id>

For File<element id type=”file”> the base64 coded ver-sion of the byte array of the file </element id>

For Checkbox<element id type=”checked”> if chosen ”true”oth-erwise”false” </element id>

For the Radiobox element which have the samename value<element name value value=”text”> radio value</element name value>

• With Firefox, file reading is provided by Firefox meth-ods; however this is not possible with IE. File is readby ActiveX components. For reading and encodingto base64 ADODB.Stream and DOMDocument havebeen used.

• After the XML elements are arranged for each of theform elements, all of them together are enclosed usingthe pair <form></form>.

The hash value used while solving the puzzle and the 12bit string which is the result of the puzzle are arranged asfollows:

<puzzle>

<hash>

hash_value

</hash>

<result>

a byte array with comma delimiters

</result>

</puzzle>

The XML data related to the form and the puzzle resultis placed between <form puzzle></form puzzle> tags.

The hash of the XML document, which assumes the<form puzzle> tag as the root tag, is calculated by us-ing SHA-256. This value is coded as fixed length 64 withbase64. The calculated hash value is signed by the win-dow.crypto.signText method which is provided by javascript1.2 standards at Firefox side. In this process, a hash is cal-culated with SHA1 and encoded with a fixed length. AtIE side, the hash of the form puzzle contents is signed withCAPICOM with Visual Basic Script. In this process, a hashis also calculated; however this hash is not of fixed length.Hence, there will be a difference at verification. The signa-ture value is then placed between <signature></signature>tags.<form puzzle> and <signature> tags with the values theycarry are wrapped between <data></data> tags.

Security Issues iiWAS2010 Proceedings

205

Figure 4: - Form Signing and XML Document Cre-ation

The XML document which assumes <data> tag as theroot tag is sent to the server as the only property of theform. While this process takes place, the elements includedin the form are cleaned with the help of JavaScript. All theprocesses are shown in Figure 4.

A sample web form is shown in Figure 6. The XML docu-ment of this form is shown in Figure 7 According to Figure 5,before verifications at server side, if a client puzzle is neededthen client puzzle result at xml document is checked. Afterthat, the kind of browser is checked to determine the kind ofverification to be done. If the browser is IE, CAPICOM isused for verification of signature. If the browser is Firefox,the xml document will be converted to a P7M format thenthe signature is verified with OpenSSL .

The signed form is protected by digital signature, i.e., itscontents can not be modified anyone while transmission. Itis true that this system does not provide any confidentially.However, when HTTPS is required, it is provided by bothFirefox and Internet Explorer.

5. EXPERIMENTAL ANALYSISTo test the applicability and effectiveness of the proposed

Figure 5: - Signature Verification at the Server

iiWAS2010 Proceedings Security Issues

206

Figure 6: A Sample Form adapted from (http://creativecommons.org/licenses/by/3.0/)

Table 1: - Processing Time with Client PuzzleForm Name Firefox (seconds) IE (seconds)

Form 1 16 15Form 2 10 17Form 3 14 19Form 4 5 10

approach, we used four medical web forms obtained from dif-ferent medical web sites. We transformed the paper formatinto W3C approved XHTML compliant format. Form 1 [13]is related with medical care second payer; Form 2 [14] is re-lated with patient registration form, Form 3 [15] is relatedwith another form of patient registration at another hospital;and Form 4 [16] is related with daily pain log. We measuredtwo different types of processing times on computer havingIntel 2GHz processor and 512 MB Ram configuration. Theversion of Firefox used is 3.5 and IE is 6.0. Also IE stopsand queries if a script works so long. Hence it has effectson performance. In the first case, client puzzles are enabled.The results are given in Table 1.

In the second group of test, we extended form sizes withbulk data up to 10, 25, 50, 100 KB extra garbage data. Theyare used for uploading to the server. We tested two forms,when client puzzle is enabled and disabled, respectively. Theresults are reported in Table 2.

6. CONCLUSIONSWe have proposed a protocol that provides signing of the

one-side signed forms between clients and the server. Themain feature is that the proposal includes a defense systemagainst DoS attacks. The system is usable with both Fire-fox and Internet Explorer which are widely used browsers.Also the proposed system uses common APIs that are insideoperating systems and the browser. Further, the proposedsystem does not needs any third party application for anykind of setup. Here, we try to cope with the burden of anyinstallation at local computers. The proposed system imple-ments one side contract signing. However it is extendable;it is possible to add to the system a feature to support two-side contract signing. Also it is possible to encrypt the formsigned by the client while sending to the server and this en-cryption could be valid for all forms sent with the help ofthe http and https protocols. The system could be changedas a way to send the client forms with the XForms to theserver after XForms become widespread in many kinds ofbrowsers.

7. REFERENCES[1] Stephen de Vries, 03-03-04 ”A Corsaire White Paper:

Application Level DoS Attacks”, v0.4.doc, V1.0Released, 1 April 2004(research.corsaire.com/whitepapers/040405-application-level-dos-attacks.pdf)

Security Issues iiWAS2010 Proceedings

207

<?xml version="1.0" encoding="utf-8"?> <data>

<form_puzzle>

<form>

<radioDefault_0 type="text">Ae1...JTIwU</radioDefault_0>

<Field0 type="text">SGVhbH...TIwU2FmZXR5</Field0>

<Field1 type="list">

<values>

<value>Ae1BJK==</value>

<value>UXVhcn...wUmFmZmxl</value>

</values>

</Field1>

<radioDefault_3 type="text">AyJTIw...hcnMlMj=</radioDefault_3>

<Field3 type="text">MyU...GhvdXJz</Field3>

<Field5 type="checked">false</Field5>

<Field6 type="checked">true</Field6>

<Field7 type="checked">false</Field7>

<Field8 type="checked">true</Field8>

<Field9 type="checked">false</Field9>

<Field10 type="checked">false</Field10>

<Field11 type="checked">false</Field11>

<Field2 type="text">SSUyMGhhd...BpbiUyMFdITy4=</Field2>

<radioDefault_115 type="text">mUlM...jB3b3</radioDefault_115>

<Field115 type="text">T25saW5lJTIwU2VhcmNo</Field115>

<Field104 type="text">U3Vl</Field104>

<Field105 type="text">U21pdGg=</Field105>

<Field120 type="file">/9j/4AAQSkZJR...gABAQEAS2TR</Field120>

<Field106 type="text">QmFyYmFkb...ERpdmlzaW9u</Field106>

<Field107 type="text">Q29sZ...3RyZWV0</Field107>

<Field108 type="text">QnJpZG...biUyMDI=</Field108>

<Field109 type="text"/>

<Field110 type="text">MTIzNDU=</Field110>

<Field111 type="list">

<values>

<value0>QmFyYmFkb3M=</value0>

</values>

</Field111>

<Field113 type="text">c3VlLnNtaXRoQGVtYWlsLmNvbQ==</Field113>

<Field112 type="text">ODA5</Field112>

<Field112-1 type="text">NDM2</Field112-1>

<Field112-2 type="text">NjA4</Field112-2>

<comment type="text"/>

</form>

<puzzle>

<hash>08290...3c7e0</hash>

<result>1001...0011</result>

</puzzle>

</form_puzzle> <signature>MIII2AYJ...wSZZZSChlWNy8B2L</signature>

</data>

Figure 7: The XML document for the form shown in Figure 6

Table 2: – Bulk Data LoadFile Size (KB) Client Puzzles Enabled No Client Puzzle

Firefox (s) IE (s) Firefox (s) IE (s)10 4 7 4 825 8 9 6 1050 11 22 11 19100 44 43 19 31

iiWAS2010 Proceedings Security Issues

208

[2] Ari Juels and John Brainard, ”Client Puzzles: ACryptographic Defense Against ConnectionDepletion”. Proceedings of 5th Network andDistributed Systems Security Symposium, 1999.

[3] Drew Dean and Adam Stubblefield, ”Using ClientPuzzles to Protect TLS”. Proceedings of the 10thUSENIX Security Symposium, 2001.

[4] Brent Waters, Ari Juels, J. Alex Halderman, EdwardW. Felten, ”New client puzzle outsourcing techniquesfor DoS resistance”. Proceedings of ACM Conferenceon Computer and Communications Security, 2004.

[5] Secure/Multipurpose Internet Mail Extensions(S/MIME) Version 3.1 Message Specification, (can bedownloadable fromhttp://www.ietf.org/rfc/rfc3851.txt)

[6] Davis don, Defective Sign & Encrypt in S/MIME,PKCS#7, MOSS, PEM, PGP, and XML Source,Proceedings of the General Track: 2002 USENIXAnnual Technical Conference, pp.65-78, 2002.

[7] OpenSSL Library, Available athttp://www.openssl.org.

[8] Kemal Bicakci and Bruno Crispo and Andrew S.Tanenbaum, “Reverse SSL: Improved ServerPerformance and DoS Resistance for SSLHandshakes”, Cryptology ePrint Archive, Report2006/212.

[9] http://www.w3.org/XML/

[10] Mikko Honkala and Petri Vuorimaa, “Secure WebForms with Client-Side Signatures”, Proceedings of theFifth International Conference on Web Engineering(ICWE2005), Sydney, Australia, pp.340-347, July2005.

[11] Michael J. Ganley, “Digital Signatures”, InformationSecurity Technical Report, Vol. 2, No. 4 (1998) 12-22.

[12] OpenSSL: Open source toolkit for ssl and tls (can bedownloadable from: http://www.openssl.org/)

[13] http://www.nova.edu/smc/forms/Medicare_

Secondary_Payer_Form.pdf

[14] http://www.imaginghss.org/forms/MRI\

%20PatientRegistrationForm.pdf

[15] http://www.emoryhealthcare.org/departments/

ortho/pdf/BRADBURYNPF.PDF

[16] http://www.imaginghss.org/pdfs/Daily\%20Pain\

%20Log\%20\%20FINAL.pdf

[17] Andreas Ekelhart, Stefan Fenz, Gernot Goluch,Markus Steinkellner, and Edgar Weippl. “XMLsecurity - A comparative literature review.” Journal ofSystems and Software 81:1715-1724, October 2008.

[18] Mart?n Abadi and Bogdan Warinschi. “Securityanalysis of cryptographically controlled access to XMLdocuments.” Journal of the ACM, 55:1-29, 2008.

[19] Gwan-Hwan Hwang and Tao-Ku Chang. “Anoperational model and language support for securingXML documents,” Computers & Security, 23:498-529,2004.

[20] Bhavani Thuraisingham. “Security standards for thesemantic web,” Computer Standards & Interfaces,27:257-268, 2005.

[21] Elisa Bertino, Silvana Castano, Elena Ferrari andMarco Mesiti. “Protection and administration of XMLdata sources,” Data & Knowledge Engineering,43:237-260, 2002.

[22] E. Kleiner and A.W. Roscoe. “On the RelationshipBetween Web Services Security and TraditionalProtocols,” Electronic Notes in Theoretical ComputerScience, 155:583-603, 2006.

[23] Barbara Carminati, Elena Ferrari, Patrick C. K.Hung. “Security Conscious Web Service Composition,”Proceedings of International Conference on WebServices. ICWS ’06., pp.489-496, 2006.

[24] Makoto Murata, Akihiko Tozawa, Michiharu Kudo,and Satoshi Hada. “XML access control using staticanalysis.” ACM Transaction on Information SystemsSecurity, 9:292-324, 2006.

[25] Felix G. M?rmol and Gregorio M. Perez. “Securitythreats scenarios in trust and reputation models fordistributed systems.” Computers & Security,28:545-556, October 2009.

Security Issues iiWAS2010 Proceedings

209