Oracle XSQL- P4 ppsx

</head> <body class=”page”> <center></center> <xsl:apply-templates select=”ROWSET”/> </body> </html> </xsl:template> </xsl:stylesheet> You will learn more about XSLT stylesheets in Chapter 13. For now, you should focus on getting the example working. Most important, if you didn’t create the example in the xdk/demo/java/xsql directory, this example won’t work. The xsl:import element references another stylesheet in the xdk/demo/java/ xsql/common directory. A lot of the complex work is done in that stylesheet. In this file, you can see the basics of how XSLT works. First, notice that the XSL stylesheet is almost entirely HTML. The idea is that the stylesheets describe how the XML elements should be rendered in HTML. If you look back at the XML file, you will see that it has a ROWSET element that contains ROW elements. Now, look at the line <xsl:apply-templates select=”ROWSET”>. When the XSLT processor encounters this element, it selects the ROWSET element in the XML file and renders it according to the ROWSET template contained in the rowcol.xsl file. The in-depth discussion is later. Your work isn’t finished until you tie the stylesheet to the helloworld.xsql file. You can do this by adding the following as the second line in the helloworld.xsql file: <?xml-stylesheet type=”text/xsl” href=”helloworld.xsl”?> After saving the file, you should be able to access http://localhost/xsql /momnpup/helloworld.xsql and see the following results as shown in Figure 3.3. Figure 3.3 Helloworld.xsql with stylesheet. 40 Chapter 3 XSQLConfig.xml At this point, you have at least done a little work in the XSQLConfig.xml file. If your environment was unorthodox, you may have already spent more time with this file than you would like. Now you are going to learn more about this configuration file and the role that it plays. First, you will learn it’s overall purpose and place in the XSQL architecture. Then you will look at the individual settings available, one by one. Because the config file is an XML document, it has a tree structure and resembles a file system. There are top-level elements that contain second-level elements, the second-level elements contain third-level elements, and so forth. XML is ideal for configuration files. It allows related configuration parameters to be grouped together and makes it easy to configure an indeterminate number of the same entities. For this section, you cover the configuration elements from the top down using a depth-first approach. This means that you will go all the way down one branch of the tree then recurse back up the tree and go all the way down the next branch. XSQLConfig Element This is the top-level element that contains all other elements. It is required but has no configuration options. Servlet Element This element has several children elements that configure the behavior of the XSQL servlet. The servlet element itself has no configuration options. Table 3.1 shows the two children elements that can be configured. Table 3.1 Servlet Configuration Elements ELEMENT NAME DESCRIPTION CHILDREN ELEMENTS? EXAMPLE output-buffer- Size in bytes of the No <output-buffer- size buffered output size> 10000</ stream of the output-buffer- servlet. Set to 0 size> if your servlet engine buffers. <suppress-mime- For the given mime Media-type <suppress-mime- charset> type, charset charset><media- won't be set. type>image/svg+ Needed for SVG. xml</media- type><media- type>image/svg< /media-type> Hello, XSQL! 41 Processor Element This section covers database caching, file caching, and security-related parameters. The processor element has no configuration options. Table 3.2 details the immediate children that have direct configuration parameters. Beyond these elements, there are several that are more complex. The first is the stylesheet-pool element. This element defines the characteristics the individual pools, while the stylesheet-cache-size parameter described in Table 3.2 specifies the number of individual pools. Table 3.3 details the options of the children of the stylesheet-pool element. The stylesheet-pool element itself takes no parameters. Here is an example of the stylesheet-pool element: <stylesheet-pool> <initial>1</initial> <increment>1</increment> <timeout-seconds>60</timeout-seconds> </stylesheet-pool> Table 3.2 Processor Configuration Elements ELEMENT NAME DESCRIPTION EXAMPLE reload-connections- If yes, the XSQLConfig. <reload-connections- on-error xml is reloaded if a on-error>yes</reload- connection can't be found connections-on-error> in memory. This is useful during development when you might be adding connection definitions, but is inefficient in a production system. default-fetch-size The default value of the <default-fetch- Row Fetch Size, the size>50</default- number of rows fetched fetch-size> from the database at a time. Requires the Oracle JDBC Driver. result-cache-size The size of the LRU <result-cache- cache of XSQL page size>50</result- fragment results. cache-size> page-cache-size The size of the LRU <page-cache-size> cache for XSQL files. 25</page-cache-size> stylesheet-cache- The size of the cache for <stylesheet-cache- size pools of XSL stylesheet size>25</stylesheet- instances. These instances cache-size> are defined by the stylesheet-pool element. 42 Chapter 3 Table 3.3 Stylesheet-Pool Elements ELEMENT NAME DESCRIPTION initial The initial size of a pool increment The size by which the pool should increase when it needs to grow timeout-seconds The number of seconds of inactivity that will cause a particular stylesheet to be dropped out of the pool The connection-pool element controls the behavior of the JDBC connections. By pooling the connections, database transactions can complete much more efficiently. Table 3.4 details the options of the children of the connection-pool element. The connection-pool element itself takes no parameters. The connection-manager element controls the XSQL Configuration Manager Fac- tory class. There is little reason to use a connection manager other than the one that is used by default. If you happen to find a reason to use another one, simply replace the value of the factory element to the fully qualified class name of the factory class you desire. The class must implement the oracle.xml.xsql.XSQLConnectionMan- agerFactory interface. <connection-manager> <factory>oracle.xml.xsql.XSQLConnectionManagerFactoryImpl</factory> </connection-manager> The next element to explore is the security element. The configuration elements here will factor heavily into our security discussion at the end of the chapter. Here we detail the various elements and the effect they have. The security element has one child element, stylesheet. Neither of these elements have any configuration options. The interesting elements are children of stylesheet. All of the following examples should be included between <security><stylesheet> and </stylesheet></security>. Table 3.4 Connection-Pool Elements ELEMENT NAME DESCRIPTION initial The initial size of a pool. increment The size by which the pool should increase when it needs to grow. timeout-seconds The number of seconds of inactivity that will cause a particular connection to be dropped. dump-allowed If yes, a browser-based status report of the current state of connections is enabled. Hello, XSQL! 43 The first element to examine is allow-client-style. When set to “yes,” the HTTP client can specify the stylesheet that should be used for transformation, includ- ing none. Setting this element to “yes” is slightly helpful during development because you can easily see the raw XML. There is no reason to have it set to “yes” in a production environment. In fact, this configuration caused a security alert in 2001 because it allowed the execution of arbitrary Java code on the server. Here is how you set the allow-client-style element: <defaults> <allow-client-style>no</allow-client-style> </defaults> The next element, trusted-hosts, is related to the allow-client-style element. Generally, stylesheets should be referenced with relative URIs and reside on the same Web server. If, for some reason, you want to access a stylesheet from another Web server, it must be from a trusted host. A trusted host appears as the value of a host element as shown in the following code. It is also possible to trust all hosts by making a <host>*</host> entry, but you really shouldn’t do this. <trusted-hosts> <host>127.0.0.1</host> <host>trustedHost.trustedDomain.com</host> </trusted-hosts> Http Element The http element is a very simple element. It allows for the definition of an HTTP proxy server for use by the XSQL servlet. If you are going to grab documents from beyond your firewall and need to use a proxy server to access them, you define it here. Here is an example: <http> <proxyhost>your-proxy-server.yourcompany.com</proxyhost> <proxyport>80</proxyport> </http> Connectiondefs Element The connectiondefs element describes the connections to the database. Each XSQL page specifies the connection that should be used to process the SQL statements contained in that page. The connectiondefs element and the connection element itself has no configuration options. Table 3.5 describes the child elements of the connection element. 44 Chapter 3 Table 3.5 Connection Elements CHILD ELEMENT DESCRIPTION username User name for the connection password Password for the user name dburl JDBC URL for the connection Driver Fully qualified class name for the Oracle driver Generally, you set up a new connection because you need to access the database as a different user or you need to access a different database. To access as a different user, simply copy and paste a working connection element and change the user name and password. Configuring access to a different database is more complex. Actiondefs Element The actiondefs element configures action handlers that can be called from an XSQL page. You will learn more about action handlers in Chapter 8. Here is an example showing how to configure a new action handler: <action> <elementname>current-date</elementname> <handlerclass> oracle.xml.xsql.actions.ExampleCurrentDBDateHandler </handlerclass> </action> Serializerdefs Element The serializerdefs element configures serializers that can be called from an XSQL page. You will learn more about serializers in Chapter 19. Here is an example showing how to configure a new serializer: <serializer> <name>FOP</name> <class> oracle.xml.xsql.serializers.XSQLFOPSerializer </class> </serializer> Hello, XSQL! 45 Security Issues Now that you have a new package installed and understand how it works, it is a good time to consider the security implications. XSQL doesn’t introduce grave and complex security concerns. However, it is a new window onto your system from a public network. This gives hackers a new avenue of attack not only on your system but also your entire enterprise. Because XSQL attaches directly to the database, the potential of information compromise is especially high. We can’t promise that reading the next few pages will prevent hackers from pene- trating your system. The very nature of Internet security dictates that you have to insu- late yourself from vulnerabilities that aren’t currently known. What you will learn here is what the current vulnerabilities are and what some past weakness have been. By using these known issues as a case study, we will explore various strategies to protect yourself from XSQL-based attacks. Known Issues There are a couple of current and known issues involving XSQL. These are issues, not security holes. A security hole is a flaw in the design and implementation of a product that isn’t documented. It gives hackers a secret route to exploit your system. The issues that you are going to learn about here are: the need to protect the XSQLConfig.xml file, the problem of SQL poisoning, and the implications of denial-of-service (DOS) attacks. You will also see a true security hole that was found in 2001, which has subse- quently been resolved. The ability to pull in stylesheets from other hosts meant that it was possible to execute arbitrary Java code on the Web server machine. Though not a problem now, it is valuable to know how XSQL was compromised in the past so that you can think about the overall architecture in terms of security. The XSQLConfig.xml File When you are setting up XSQL it is easy to put the XSQLConfig.xml file into a directory that is accessible from the Web. This is a big mistake. The XSQLConfig.xml file contains all of the information that someone needs to be able to access your database. They have the user name, the password, and even the host and the System Identifier (SID). After you have the XSQLConfig.xml file configured as you like, the file only needs to be readable by the XSQL servlet, or more specifically, by the user that XSQL Servlet runs as. The XSQL servlet is run by the user, which runs the servlet engine. You’ll need to consult the documentation of your servlet engine to determine the user. Then you can limit the availability of the file at an operating system level. Under no circumstances should the XSQLConfig.xml reside in a virtual directory or otherwise be publicly available. 46 Chapter 3 SQL Poisoning One thing that makes XSQL great is that it is very easy to create Web pages that are based on SQL queries. This also is a security issue. As you will learn in detail in Chapter 6, it is easy to plug parameters into your queries. Without jumping ahead too much, let’s look at an example of this functionality and then discuss the security ramifications of it: <?xml version=”1.0”?> <xsql:query connection=”demo” xmlns:xsql=”urn:oracle-xsql”> SELECT {@field} FROM EMP WHERE ENAME = ‘{@name}’ </xsql:query> You can use this XSQL page to provide the data of a particular employee by name. The name parameter can be specified in the URL embedded in the query string. If the preceding example is saved as hack.xsql into the momnpup directory created earlier, you should get the output that is shown in Figure 3.4 when you access http: //localhost/xsql/momnpup/hack.xsql?name=ADAMS&field=job. If your users are clever, they can even do their own queries. The URL http: //localhost/xsql/momnpup/hack.xsql?field=ename,job&name=ADAMS’%2 0OR%20ENAME=’ALLEN can select a couple of employees at once, as shown in Figure 3.5. However, it is easy to abuse this. In the next example, your user goes from benignly saving himself or herself some time to getting information that he or she shouldn’t see. In this example, the hacker uses knowledge of the EMP table combined with a clever “where” clause to get the salaries of all of the workers. The URL used is http: //localhost/xsql/momnpup/hack.xsql?field=ename,sal&name=ADAMS’% 20OR%20NOT%20ENAME=’ZZZZ. The result is shown in Figure 3.6. Figure 3.4 Unpoisoned XSQL access. Hello, XSQL! 47 Figure 3.5 Benign SQL poisoning. Figure 3.6 Malignant hack. 48 Chapter 3 It’s important to note that the programmer that created this code walked right into this kind of attack. By parameterizing too much of the SQL statement, hackers are able to access secret information through a Web browser by coming up with their own SQL statements. Even though this example may look a bit contrived, it’s important to note that this is only one example of this type of hack. XSQL yields a great deal of power in this regard, but as you design and implement XSQL pages, you should think about the security implications. In Chapter 6, you will see how to use the flexibility safely. Denial-of-Service Attacks The first thing that should be said about denial-of-service (DOS) attacks is that it is hard to prevent them at the application level. The strategy behind DOS attacks is to so overwhelm your servers that it puts you out of business. They don’t exploit a particular hole in your application that you can plug. Instead, they attempt to overwhelm your system through a mass of legitimate requests. The best you can do at an application level is attempt to sense that you are being attacked and then try to block the individual attackers, but this is risky. If you try to do this based on IP, for instance, you might find yourself cutting off all AOL users from your system. AOL tends to proxy lots of users through the same IP. Instead of attempting to block DOS attacks, let’s look at how to sustain them and min- imize their impact on your operations. You should assume that your firewall engineers will ultimately defeat a DOS attack, after some good sleuthing as to their origins and some cooperative action with the ISPs from where the attacks originated. As an XSQL application developer, your responsibility is to survive the (hopefully temporary) siege. During a DOS attack, your Web performance to legitimate users will suffer. Stopping that suffering is the responsibility of your security engineers. Because XSQL applications are database driven, your responsibility is to protect the database. DOS attacks have two avenues of attack on your database: (1) resource overload and (2) data overload. A DOS attack pointing at your database will slow the database down for legitimate users. It could even cripple it. This is unfortunate for your legitimate Web-based users. After all, during the initial siege you can’t tell the difference between your legitimate Web-based users and the Web-based hackers. However, it is likely that your database has more than one face. It may have multiple distinct Web faces, and internal users may use non-Web tools to access it. Therefore, the contingency strategy is to sustain an attack on one front while still operating relatively well on the other fronts. Oracle’s distributed database technology is very good at providing this if implemented correctly. While the attack pegs the central processing units (CPUs) on the machines that service the Web, other machines that comprise the same distributed database can serve their users more or less nor- mally. This also makes it easier on everyone if you have to shut down the besieged Web interface for a while. Along the same lines, you can take a data warehousing approach. In some cases, this can be a little simpler than implementing a full-blown distributed database. If your Web interface mainly provides querying and the data doesn’t need to be synchronized Hello, XSQL! 49 [...]... database Since the XSQL page processor interfaces with JDBC, you can actually use any database with XSQL for which there is a JDBC driver The best driver to use with XSQL is the Oracle Type 4 JDBC driver that installs with Oracle 9i This driver does a direct connection to the database without any intermediary client interface, and it is superior to the more primitive JDBC drivers that sit on top of... unnecessary network services running on your production machines This doesn’t make your actual application any less vulnerable, but it does increase your overall security On this same strategy, there are some XSQL-specific steps that you should take All those demos install by default You shouldn’t have them on your production machines They represent a well-known access point that is asking for someone to find... XSQLConfig.xml file Keep Up-to-Date A lot of attacks, such as the popular e-mail worms, are exploits of known vulnerabilities You can save yourself a lot of pain and embarrassment simply by keeping up-to-date Oracle is highly committed to keeping its customers secure, so you can count on them to be proactive in addressing concerns Still, someone in your organization will have to watch for the emails and apply... you’re ready to go! The next four chapters cover the workings of XSQL and the details of all of the XSQL features With this base knowledge, you’ll branch out to the other key technologies, starting with Oracle SQL You’ll then learn all about XSLT The book wraps up by showing you how to extend XSQL with Java Now that you have a development environment set up, it’s time to put XSQL to work! CHAPTER 4 XSQL... reached, no more data for that user can be entered However, that may be preferable to preventing other database applications from working More information about setting quotas for users can be found in your Oracle Database Administrator’s Guide An Example Security Hole This section documents a security hole that was found in January 2001 by Georgi Guninski The hole was patched almost immediately It is discussed . class you desire. The class must implement the oracle. xml.xsql.XSQLConnectionMan- agerFactory interface. <connection-manager> <factory> ;oracle. xml.xsql.XSQLConnectionManagerFactoryImpl</factory> </connection-manager> The. for which there is a JDBC driver. The best driver to use with XSQL is the Oracle Type 4 JDBC driver that installs with Oracle 9i. This driver does a direct connection to the database without any. for the user name dburl JDBC URL for the connection Driver Fully qualified class name for the Oracle driver Generally, you set up a new connection because you need to access the database as a

Định dạng
Số trang	20
Dung lượng	347,27 KB