security fundamentals for e commerce phần 8 pot

restricted to the query-processing programs (e.g., SQL (Structured Query Language)) so mechanisms enforcing access, flow, and inference control can be placed in these programs [12]. Unfortunately, it has been shown that tracker attacks, which are based on inference, are practically always possible, at least to some extent. 16.5 Copyright Protection Web servers distribute or sell information in digital form, such as computer software, music, newspapers, images, or video. Unfortunately, digital content can be copied very easily without the origin servers ever noticing unless spe- cial measures are taken. Digital watermarks serve to protect intellectual prop- erty of multimedia content [13]. Technically, a digital watermark is a signal or pattern added to digital content (by the owner) that can be detected or extracted later (by the recipient) to make an assertion about the content. A watermark extraction method helps to extract the original watermark from the content, but it is often not possible to extract it exactly because of, for example, loss of data during image compression, filtering, or scanning. Therefore, it is often more suitable (i.e., robust) to apply a watermark detec- tion method, which examines the correlation between the watermark and the data (i.e., computes the probability that a watermark is embedded in the con- tent). The general requirement is that a watermark be robust (i.e., recoverable despite intentional or unintentional modification of the content [14]). Fur- thermore, watermarks must not change the quality of the watermarked con- tent, and must be nonrepudiable (i.e., it must be provable to anybody that they are embedded and what they mean). The name watermark comes from the technique, which has been in use since ancient times, to impress into paper a form, image, or text derived from the negative in a mold [15]. Digital watermarking has its roots in steg- anography, whose goal is to hide the existence of confidential information in a message. The oldest steganographic techniques were based on, for example, invisible ink, tiny pin pricks on selected characters, or pencil marks on type- written characters [16]. Newer techniques hide messages in graphic images, for example by replacing the least significant bit of each pixel value with a bit of a secret message. Since it is usually possible to specify more gradations of color than the human eye can notice, replacing the least significant bits will not cause a noticeable change in the image. This technique could also be used to add a digital watermark, but it is unfortunately not robust, since the watermark can be easily destroyed. Watermarking techniques have their 280 Security Fundamentals for E-Commerce background in spread-spectrum communications and noise theory [13] as well as computer-based steganography. When watermarking is used to pro- tect text images, text line coding (i.e., shifting text lines up or down), word space coding (i.e., altering word spacing), and character encoding (i.e., alter- ing shapes of characters) can be applied in such a way that the changes are imperceptible. No watermarking technique can satisfy all requirements of all applica- tions. Digital watermarks can be used for different digital media protection services [14]: • Ownership assertion to establish ownership over content; • Fingerprinting to discourage unauthorized duplication and distribu- tion of content by inserting a distinct watermark into each copy of the content; • Authentication and integrity verification to inseparably bind an author to content, thus both authenticating the author and ensuring that the content has not been changed; • Usage control to control copying and viewing of content (e.g., by indicating in the watermark the number of copies permitted); • Content protection to stamp content and thus disable illegal use (e.g., by embedding a visible watermark into a freely available content pre- view and thus make it commercially worthless). Some watermarking techniques require a user key for watermark inser- tion and extraction/detection [14]. Secret key techniques use the same key for both watermark insertion and extraction/detection. Obviously, the secret key must be communicated in a secret way from the content owner to the receiver. Public key techniques are similar to digital signature: private key is used for watermark insertion, and public key for watermark extraction/detec- tion. This technique can be used for ownership assertion service or authenti- cation and integrity service. Digital watermarks must withstand different types of attacks [17]. For example, robustness attacks are aimed at diminishing or removing the pres- ence of a watermark without destroying the content. Presentation attacks manipulate the content so that the watermark can no longer be extracted/detected. Interpretation attacks neutralize the strength of any evi- dence of ownership that should be given through the watermark. Technical Web Server Security 281 descriptions of various attacks are given in [18]. More information about digital watermarking can be found in [19-20]. References [1] Garfinkel, S., and G. Spafford, Practical Unix and Internet Security, Sebastopol, CA: OReilly & Associates, Inc., 1996. [2] Karro, J., and J. Wang, Protecting Web Servers from Security Holes in Server-Side Includes, Proc. 14 th Annual Computer Security Applications Conference (ACSAC 98), Dec. 711, 1998, Scottsdale, AZ, IEEE Computer Society Press, 1998, pp. 103111. [3] Northcutt, S., Network Intrusion Detection: An Analysts Handbook, Indianapolis, IN: New Riders Publishing, 1999. [4] Robinson, D., and K. Coar, The WWW Common Gateway Interface Version 1.1, The Internet Engineering Task Force, Internet Draft, <draft-coar-cgi-v11-03.txt>, Sept. 1999. [5] Christiansen, T., and N. Torkington, Perl Cookbook, Sebastopol, CA: OReilly & Associates, Inc., 1999. [6] Oppliger, R., Security Technologies for the World Wide Web, Norwood, MA: Artech House, 1999. [7] Wagner, B., Controlling CGI Programs, Operating Systems Review (ACM SIGOPS), Vol. 32, No. 4, 1998, pp. 4046. [8] Garfinkel, S., and G. Spafford, Web Security & Commerce, Cambridge: OReilly & Associates, Inc., 1997. [9] Son, S. H., Database Security Issues for Real-Time Electronic Commerce Systems, Proc. IEEE Workshop on Dependable and Real-Time E-Commerce Systems (DARE98), Denver, Colorado, June 1998, pp 2938, http://www.cs.virginia.edu/~son/ publications.html. [10] Lampson, B. W., A Note on the Confinement Problem, Communications of the ACM, Vol. 16, No. 10, 1973, pp. 613615. [11] George, B., and J. R. Haritsa, Secure Concurrency Control in Firm Real-Time Data- base Systems, International Journal on Distributed and Parallel Databases, Special Issue on Security, Feb. 2000, http://dsl.serc.iisc.ernet.in/publications.html. [12] Denning, D. E. R., Cryptography and Data Security, Reading, MA: Addison-Wesley Publishing Company, Inc., 1982. [13] Zhao, J., Look, Its Not There, Byte, Vol. 22, No. 1, 1997, pp. 712, http://www. byte.com/art/9701/sec18/art1.htm. 282 Security Fundamentals for E-Commerce [14] Memon, N., and P. W. Wong, Protecting Digital Media Content, Communications of the ACM, Vol. 41, No. 7, 1998, pp. 3543. [15] Berghel, H., Watermarking Cyberspace, Communications of the ACM, Vol. 40, No. 11, 1997, pp. 1924, http://www.acm.org/~hlb/col-edit/digital_village/nov_97 /dv_ 11-97.html. [16] Schneier, B., Applied Cryptography,2 nd edition, New York, NY: John Wiley & Sons, Inc., 1996. [17] Craver, S., and B L. Yeo, Technical Trials and Legal Tribulations, Communications of the ACM, Vol. 40, No. 11, 1997, pp. 4554. [18] Petitcolas, F. A. P., R. J. Anderson, and M. G. Kuhn, Attacks on Copyright Marking Systems, In Second Workhop on Information Hiding, pp. 218238, D. Aucsmith (ed.), LNCS 1525, Berlin: Springer-Verlag, 1998, http://www.cl.cam.ac.uk/~fapp2/papers/ ih98-attacks/. [19] Katzenbeisser, S., and F. A. P. Petitcolas (eds.), Information Hiding Techniques for Steg- anography and Digital Watermarking, Norwood, MA: Artech House, 2000. [20] Hartung, F., WWW References on Multimedia Watermarking and Data Hiding Research & Technology, 1999, http://www-nt.e-technik.uni-erlangen.de/~hartung/ watermarkinglinks.html. Web Server Security 283 17 Web Client Security The following chapter discusses the security issues concerning Web users and their Web browsers (i.e., Web clients). Although it is possible for a Web cli- ent to strongly authenticate a Web server and communicate privately with it (e.g., by using SSL and server-side certificates by VeriSign, 1 BelSign, 2 or Thawte 3 ; not all security problems are solved. One reason is that access con- trol management can only be really efficient for a small number of client- server relationships. Even in such a limited scenario, it requires some security expertise to recognize and manage good certificates. Another problem is user privacy and anonymity, which is addressed in Sections 17.2 and 17.3. There are at least three good reasons for ensuring privacy and anonymity in the Web: to prevent easy creation of user profiles (e.g., shopping habits, spending patterns), to make anonymous payment sys- tems possible, or to protect a companys interests (e.g., information gathering in the Web can reveal its current interests or activities) [1]. 285 1. http://www. verisign.com 2. http://www. belsign.com 3. http://www. Thawte.com 17.1 Web Spoofing IP spoofing and DNS spoofing were discussed in Part 3. Through Web spoof- ing an attacker can create a convincing but false copy of the Web by redirect- ing all network traffic between the Web and the victims browser through his own computer [2]. This allows the attacker to observe the victims traffic (e.g., which Web sites are visited, which data is entered in Web forms) and to modify both the requests and the responses. A basic attack scenario is shown in Figure 17.1 [2]. The attacker can first make the victim visit his Web page, for example, by offering some very interesting or funny contents. His Web page is actually a trap, because when the victim tries to go to some other Web page afterwards (by clicking on a link on the page), the victim will be directed to a fake Web page because the link has been rewritten by the attacker. For example, http://home.realserver.com/file.html becomes http://www.attacker.org/http://home.realserver.com/file.html Another possibility for the attacker is to rewrite some of the victims URL directly (e.g., in the bookmark file). When the victim wants to go to the Web page of a real server, the spoofed URL brings him to the attackers machine (1). The attacker may either send him a fake page immediately, or pass on the original URL request to the real Web server (2). The attacker then intercepts the response (3) and possibly changes the original document (4). The spoofed page is sent to the victim (5). If the page that the victim requested is the login page of his bank, the attacker can obtain the victims account number and password. Or the attacker may send spoofed stock 286 Security Fundamentals for E-Commerce Victims browser 1. Request spoofed URL 2. Request original URL 3. Original page contents 4. Change page 5. Spoofed page contents Attacker Web server Figure 17.1 Web spoofing. market information so that the victim makes investment decisions that bring profit to the attacker. The victim cannot recognize that he is in the fake Web, not even by checking the status line or the location line of his browser: the status line can be changed by JavaScript, and the location line can be covered by a window created by JavaScript and showing the URI what the victim believes was requested. The basic way to protect against this is to check the document source and the unspoofable areas in the browser. SSL offers no help either, because the victim may establish an SSL con- nection to the attacker. If the victim does not check the SSL certificates owner carefully, he may believe that a secure connection with the real server has been established. Such fake certificates can look very similar to the real ones, perhaps containing misspelled names that are difficult to notice. 17.2 Privacy Violations Web-specific privacy violations can in general be caused by • Executable content and mobile code (addressed in Section 17.2); • The Referer header (addressed Section 15.2.2); • Cookies (described in this section); • Log files (also in this section). Cookies are HTTP extensions for storing state information on the client for servers. HTTP is normally a stateless protocol. The original cookie pro- posal came from Netscape for HTTP/1.0. Implementations based on HTTP/1.1 should use cookies as described in [3]. By using cookies it is possible to establish a session (or a context, i.e., a relation between several HTTP request/response pairs that do not necessarily belong to the same virtual connection (see Section 15.2)). This concept is useful for supporting personalized Web services such as a servers keeping track of items in a customers shopping chart or targeting users by area of interest. Cookies can also be added to embedded or in-lined objects for the purpose of correlating users activities between different Web sites. For exam- ple, a malicious Web server could embed cookie information for host a.com in a URI for a CGI script on host b.com. Browsers should be implemented in such a way as to prevent this kind of exchange [3]. Web Client Security 287 In the above-mentioned examples of cookie use, the Web server main- tains a database with a user profile, so the cookie information only helps the server identify a specific user. Clearly, such databases may be used to vio- late a users privacy. There is also a scenario for using cookies that does not violate privacy. In this scenario both the identifying information and any other user-specific information is stored in the cookie. Consequently, it is not necessary that the Web server maintain a database [4]. Obviously, infor- mation of a personal or financial nature should only be sent over a secure channel. A cookie is a set of attribute-value pairs which an origin server may include in the Set-Cookie header of an HTTP response. The client stores the cookie in a local file (cookies.txt). When a user wants to send an HTTP request to the origin server, the client (i.e., the browser) checks the cookie file for cookies corresponding to that server (i.e., host and URI) which have not expired. If any are found, they are sent in the request in the Cookie header. If the cookie is intended for use by a single user, the Set-cookie header should not be cached by an intermediary. Cookies can be totally disabled, or accepted only if they are sent back to the origin server. In addition, the user may be warned each time before accepting a cookie. Also, if the cookie file is made read-only, the cookies can- not be stored. Each time a Web client (i.e., a browser) downloads a page from a Web server, a record is kept in that Web servers log files [4]. This record includes the clients IP address, a time stamp, the requested URI, and possibly other information. Under certain circumstances such information can be misused to violate the users privacy. The most efficient technique to prevent that is to use some of the anonymizing techniques described in the following section. 17.3 Anonymizing Techniques Even if an HTTP request or any other application layer data is encrypted, an eavesdropper can read the IP source or destination address of the IP packet and analyze the traffic between the source and the destination (see Chapter 12). Also, URIs are normally not encrypted, so the address of the Web server can easily be obtained by an eavesdropper. Web anonymizing techniques in general aim at providing • Sender anonymity (i.e., client in an HTTP request, sender in an HTTP response); 288 Security Fundamentals for E-Commerce TEAMFLY Team-Fly ® • Receiver anonymity (i.e., server in an HTTP request, client in an HTTP response); • Unlinkability between the sender and the receiver. In this section we will look at the techniques providing client anonym- ity with respect to both an eavesdropper and the server, server anonymity with respect to an eavesdropper, and unlinkability between the client and the server by an eavesdropper. The problem of server anonymity with respect to the client was discussed in Section 16.3. Additionally, anonymizing mechanisms such as onion routing (Section 17.3.2) or Crowds (Section 17.3.3) can generally provide a filtering proxy that removes cookies and some of the more straightforward means by which a server might identify a client. However, if the browser permits scripts or executable content (e.g., JavaScript, Java applets, ActiveX), the server can easily identify the IP address of the clients machine regardless of the protections that an anonymizing technique provides. In general, a clients identity can potentially be revealed to a server by any program running on the clients machine that can write to the anonymous connection opened from the client to the server. Most anonymizing services require that a proxy be installed on the users computer. If, however, the users computer is located behind a firewall, the firewall must be configured to allow the anonymizing services inbound and outbound traffic. This is normally allowed only for well-known serv- ices, which does not apply to most anonymizing services yet (i.e., they are still experimental, and mostly free of charge). Another possibility is that the anonymizing proxy is installed on the firewall. In this case the user cannot be guaranteed anonymity in the internal network behind the firewall (i.e., VPN), but only to the outside network. In most anonymizing systems, untraceability improves as more and more people use it because traffic analy- sis (eavesdropping) becomes more difficult. 17.3.1 Anonymous Remailers Remailers are systems supporting anonymous e-mail. They do not provide Web anonymity but are predecessors of the Web anonymizing techniques. One of the oldest anonymous remailers, anon.penet.fi (out of operation now), gave a user an anonymous e-mail address (pseudonym). Other senders could send a message to the user by sending it to the remailer system, which Web Client Security 289 [...]... the network (including the same jondos) The same holds for the end-server replies The messages exchanged between two jondos are encrypted with a key shared between them Only the initiating jondo knows the sender’s address, but this is usually trustworthy (i .e. , trusted by its users) An eavesdropper cannot see either the sender’s or the receiver’s address because they are encrypted An attacker eavesdropping... also be generated for other possibly unsafe languages Therefore, the first Java security checks are performed by the bytecode verifier to verify whether the Java bytecode conforms to Java language rules (format checks, and static type checking; see the previous section), see (1) in Figure 18. 2 The role of the class loader is to create a namespace for the applet and to instantiate the applet into objects... satisfies either of the conditions, access may be denied or allowed, depending on the local security policy (e. g., Netscape denies access, and Microsoft allows it) • revertPrivilege(resource) is called when the external code no longer needs the resource and wishes to remove annotations from the current stack frame • disablePrivilege(resource) is called by the external code to deny a privilege enabled earlier... names may differ for browsers from different vendors): • enablePrivilege(resource) is called by external code (e. g., an applet) wishing to use a protected resource The method checks whether the local security policy allows access If it does, an enabledprivilege(resource) annotation is made on the current stack frame • checkPrivilege(resource) is called by the system before accessing the resource This... and use of e- commerce technologies Some solutions are based on filtering out executable content on a security gateway They are not very helpful unless all types of executable content are filtered out (see Section 18. 5) All other filtering criteria will always have a security hole that may be exploited by an attacker In the following sections the security concepts of the widely used executable content... selected as the proxy In other words, the jondo receives a request from a client process before the request leaves the user’s computer The initiating jondo randomly selects a jondo from the crowd (it can be itself), strips off the information potentially identifying the user from the request, and forwards the request to the randomly selected jondo The next jondo that receives the request will either • Forward... not be defined by an applet, for obvious reasons The applet’s methods can now be executed by JVM (3) If a method is potentially dangerous (e. g., delete a file), the security manager is consulted before the method is actually invoked (4) The security manager performs runtime checks based on the calling class’s origin The security manager may also forbid some activities attempted by the applet (see the... the receiver, and untraceability of a user’s machine can be achieved, unless someone eavesdrops on the connection between the user and the anonymizer URLs are sent in the clear, so no receiver anonymity is provided A Web anonymizer must be trusted by its users Web anonymizers use a technique called URL rewriting The same technique is used in the Web spoofing attack described earlier in this chapter All... unauthorized access to certain resources In some cases, however, it is necessary that a method temporarily exercise its own permissions although the calling method is not granted these permissions Such exceptions are handled by the static method AccessController.doPrivileged() for some PrivilegedAction The doPrivileged()method effectively tells JVM to ignore the caller’s permissions for the piece of code specified... permissions defined by these entries, so all these entries determine the applet’s protection domain In JDK 1.2.x the security manager is replaced by the access controller (see also Figure 18. 2) The security manager is kept for compatibility with older JDK versions In JDK 1.2.x, instead of the security manager, the access 3 http://developer.netscape.com/docs/manuals/signedobj/capsapi.html Mobile Code Security . server. Subsequent requests launched by the same initiating jondo (and intended for 292 Security Fundamentals for E- Commerce the same end server) use the same path through the network (including the same. jondos). The same holds for the end-server replies. The messages exchanged between two jondos are encrypted with a key shared between them. Only the initiating jondo knows the senders address, but. receiver, and untraceability of a users machine can be achieved, unless someone eavesdrops on the connection between the user and the ano- nymizer. URLs are sent in the clear, so no receiver