Implementing Database Security and Auditing phần 6 docx

Many extended stored procedures provide access to operating systemfacilities from within SQL Server in addition to xp_regread.. 206 7.1 Don’t use external proceduresTable 7.1 Extended st

Using the Database To Do Too Much

For many years Sun’s tagline was “the network is the computer.” Looking atsome of the latest database products, you can’t help but wonder if the ven-dors think that “the database is the computer.” Well, it’s not, and it shouldnot be used as such The database is not an operating system It is not aWeb server It is not an application server It is not a Web services provider

It is a database, and managing data is hard enough

In this chapter you’ll see many of the advanced features that databaseshave today—features that allow you to call functions deployed on theoperating system through the databases, to call stored procedures using aWeb interface, and more These functions will become increasingly main-stream—even though from a security perspective they introduce addi-tional problems and complexities The goal of this chapter is to make youaware of potential risks, convince you to stay away from some of the moredangerous ones, and give you enough information so that if you decide toenable these features anyway, you will pay more attention to the securityaspects of these features

All databases have a query language and a procedural language (well,almost all of them—MySQL before version 5 actually doesn’t have the lat-ter) Each of the procedural languages of the main database servers ishighly functional and robust In addition, all of the databases have a largeset of built-in procedures that you can use when writing programs How-ever, the database vendors often go an extra step and provide you withmechanisms for invoking functions that reside outside the database runt-ime This can cause many problems that are related to elevated privileges,

as you’ll see in the next few sections

204 7.1 Don’t use external procedures

Extended stored procedures are DLLs that can be installed by a SQL Serveradministrator to provide enhanced functionality within SQL Server SQLServer extended stored procedures are dangerous for several reasons Themain risk has to do with their power and their ability to access and invokeactions at the operating system level Using these procedures blurs theboundary between the database and the operating system and can give toomany privileges to a user signed on to the database After seeing so manysecurity issues in previous chapters, and especially application vulnerabilities

as described in Chapter 5,a clear separation between the host and the base should be on your mind Another risk has to do with vulnerabilitiesthat have been found in these procedures In this section I will try to con-vince you that they are just not worth it and that you should remove them.Some extended procedures allow a SQL Server user to have broad access

data-to the operating system As an example, the extended procedures

xp_regread and xp_instance_regread allow the PUBLIC role to readfrom the system registry This means that I can get useful informationwhich tells me where the SQL Server 2000 instance is installed by issuingstatements of the form:

exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\MSSQLServer\Setup', 'SQLPath'

exec xp_instance_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\MSSQLServer\Setup', 'SQLPath'

To get the default login (and see if guest has been removed or not):

exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\ MSSQLServer\MSSQLServer', 'DefaultLogin'

exec xp_instance_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\ Microsoft\MSSQLServer\MSSQLServer', 'DefaultLogin'

Here is one final example showing how vulnerable extended procedurescan make you There really is a lot in the registry—data that you may noteven be aware of This information is useful to an attacker For example, ifyou are using IPSec to encrypt data in transit (see Chapter 10), then an

7.1 Don’t use external procedures 205

attacker can see what your active policy is and what it entails by issuing thefollowing sequence of commands:

exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local', 'ActivePolicy'

This returns a policy name, for example:

SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\

ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}

The attacker can then execute:

exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\

ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}', 'description'

exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\

ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}', 'ipsecData'

exec xp_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local\

ipsecPolicy{7238523c-70fa-11d1-864c-14a300000000}', 'ipsecISAKMPReference'

These are two powerful extended procedures an attacker can use to get afull snapshot of your Windows host and everything that is installed there.You should either completely remove these procedures or limit their access

to privileged accounts Providing PUBLIC role access to them is completelyunacceptable If you really don’t want to sleep at night, remember that there

is also an equivalent xp_regwrite extended stored procedure

Many extended stored procedures provide access to operating systemfacilities from within SQL Server in addition to xp_regread Some of themare extremely dangerous because they fully expose the operating system tothe SQL Server instance All of these are in most cases an unnecessary vul-nerability, and you should remove them or limit access to them Table 7.1details these problematic SQL Server 2000 extended procedures

Three more undocumented extended procedures that can be readilyused by an attacker to run arbitrary dynamic SQL without having properprivileges are:

206 7.1 Don’t use external procedures

Table 7.1 Extended stored procedures that provide access to operating system features

Extended Procedure Description

sample output looks like:

operating-system command shell and returns any output as rows of text When you grant execute permissions to users, the users can execute any operating-system command at the Windows command shell that the account running SQL Server has the needed privi- leges to execute This is arguably the most dangerous procedure.

spe-cific directory passed in as a parameter, for example: exec xp_dirtree 'c:\Windows'

(DSN) on the system.

time.

example, my list includes ORA_DBA group, because I also have Oracle installed on my machine.

Win-dows level.

drives only.

7.1 Don’t use external procedures 207

xp_execresultset

xp_printstatements

xp_displayparamstmt

file and in the Windows Event Viewer.

Server as running on Windows.

privi-lege level of the account, the mapped login name of the account, and the permission path by which an account has access to SQL Server.

addi-tion to version informaaddi-tion regarding the actual build number of the server, various environment information is also returned—a little too much for comfort from a security perspective.

Server This is a very dangerous procedure.

Win-dows services.

directo-ries that have a depth of 1.

Table 7.1 Extended stored procedures that provide access to operating system features (continued)

Extended Procedure Description

208 7.1 Don’t use external procedures

Using these to run SQL is normally limited to privileged users nately, these three extended stored procedures contain vulnerabilities thatallow this even for a low-privileged user You can get a patch from Microsoftfor these vulnerabilities at www.microsoft.com/technet/security/bulletin/MS02-043.mspx Interestingly enough, I did a search on Google for thesestrings, and apart from the many vulnerability notices, I didn’t find a singlelink for someone describing actual usage—so hopefully there aren’t toomany of you out there using these undocumented features

Unfortu-Another patch you should apply for extended stored procedure involves

a buffer overflow vulnerability From the amount of bad press they havereceived, you would think that extended stored procedures have morebuffer overflow vulnerabilities than other built-in procedures and functions.This is a result of a few vulnerabilities that are “reused” by many of theseprocedures

srv_paraminfo() is a common function used to parse input parametersfor extended procedures The signature for this method is:

int srv_paraminfo ( SRV_PROC * srvproc, int n,

BYTE * pbType, ULONG * pcbMaxLen, ULONG * pcbActualLen, BYTE * pbData,

BOOL * pfNull );

This function has a flaw that could result in a buffer overflow condition.The function is designed to locate the nth parameter in a string and put itinto a buffer provided by the extended procedure By design, the functiondoes not provide a way for an extended procedure to indicate the length ofthe buffer; instead, the extended procedure is expected to ensure that thebuffer will be large enough to hold the parameter However, not all extendedprocedures provided by default in SQL Server perform this checking A mali-cious user who provides a sufficiently long parameter to an affected extendedprocedure could cause a buffer overflow within the function in order toeither cause the SQL Server to fail or to execute arbitrary code

The following extended procedures are all affected by the

srv_paraminfo vulnerability:

xp_controlqueueservice

7.1 Don’t use external procedures 209

In order to lessen your liability, you should make sure your system ispatched with fixes to these vulnerabilities, and you should make sure youeither remove these from your system altogether or at least provide access tothem only to privileged accounts You should also track their usage by mon-itoring all calls to these procedures If you are unsure whether these proce-dures are being used (and thus are worried that removing or changing theirprivileges may affect an application), you should trace their usage for aperiod of one to four weeks and then take action If you find that an appli-cation is using these procedures, you should bring the topic to the attention

of the application owner and try to work a schedule for rewriting the codeusing these procedures so that you may disable them

If they are not used simply remove them To remove an extended dure (e.g., xp_regread), use the following command:

proce-exec sp_dropextendedproc 'xp_regread'

210 7.1 Don’t use external procedures

To revoke PUBLIC role permissions, use the following command:

revoke execute on xp_regread to PUBLIC

To monitor all executions of these extended procedures, you can eithercreate a trace within SQL Server or use an external monitoring tool

Oracle’s PL/SQL provides an interface for calling external functions thatcan be written in any library and compiled into a shared library (or dynam-ically linked library) This is done through a mechanism called external pro-cedures or EXTPROC If you have a Java method called void foo(int) in

a class called Bar, you can define a PL/SQL wrapper using:

CREATE PROCEDURE pl_foo (i NUMBER)

AS LANGUAGE JAVA NAME 'Bar.foo(int)';

And then call it using a PL/SQL block as follows:

DECLARE

j NUMBER;

BEGIN pl_foo(j);

LIBRARY fooLib LANGUAGE C;

END;

7.1 Don’t use external procedures 211

In the example shown, the functions are in an external library that needs

to be available to the server In order for such an external function to beavailable, you have to register the shared library with PL/SQL You tell PL/SQL about the library using the LIBRARY clause in the EXTERNAL defi-nition The actual loading of the library happens through a session-specificagent called EXTPROC that is invoked through the listener As shown inFigure 7.1, when the wrapper is called, PL/SQL calls the listener process,which spawns EXTPROC The shared library is loaded in an externaladdress space and the call to the function is performed The reply thencomes back through EXTPROC, which keeps running to serve up addi-tional calls so that loading overhead occurs only once

Because the invocation process is initiated through the listener, the tener configuration would typically have the following entry in

lis-listener.ora:

SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = C:\oracle\product10g\10.1.0\Db_1) (PROGRAM = extproc)

) )

and the following in tnsnames.ora:

EXTPROC_CONNECTION_DATA = (DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(KEY = EXTPROC)) )

Figure 7.1

EXTPROC

invocation process.

212 7.1 Don’t use external procedures

(CONNECT_DATA = (SID = PLSExtProc) (PRESENTATION = RO) )

)

Depending on the actual operating system and the version of the base, entries may reference PLSExtProc, extproc, or icache_extproc.These all refer to the same external procedure module for PL/SQL

data-As with extended procedures in SQL Server, external procedures in cle are a powerful feature that can be dangerous There may be conditions

Ora-in which they can offer you Ora-increased performance and/or functionality, butyou should be fully aware and prepared for the added complexity and,unfortunately, possible security issues

In terms of complexity, any scheme that involves multiple address spaceswith multiple calling schemes, different variable layout, and multiple pro-gramming languages is complex and hard to troubleshoot In terms of secu-rity issues, the main one is documented in Oracle Security Alert #29 andinvolves a serious high-risk vulnerability in EXTPROC on Oracle 8i and 9i.The vulnerability is based on the fact that the loading of the external code

by EXTPROC requires no authentication, and therefore an attacker canmasquerade as the Oracle process and cause arbitrary code to be loaded andrun on the operating system with the Oracle user privileges Because EXT-PROC is defined and managed through the listener, the attacker can eveninitiate this attack over a TCP/IP connection from a remote system The simplest fix to this problem is simply to remove EXTPROC fromyour system, and even Oracle recommends this action You should editboth listener.ora and tnsnames.ora and remove the extproc entries.You should then delete the EXTPROC executable in the bin directory ofyour Oracle installation

If you still haven’t used EXTPROC but contemplate using it, youshould rethink this option The security issue is just one problem—themain issue is the added complexity involved If you are already using EXT-PROC, take the following steps to better secure your environment:

1 Separate EXTPROC by creating two listeners: one for the worked database and one for EXTPROC Do not specify anyEXTPROC entries in the main listener file

net-7.1 Don’t use external procedures 213

2 Configure the listener for EXTPROC for IPC only: (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)) This means that EXT-PROC will only be activated using local IPC mechanisms andwill not be available for invocation over the network

3 Run the EXTPROC listener as an unprivileged user

4 Use tcp.validnode_checking and tcp.excluded_nodes (as tioned in Chapter 5) to exclude all networked access to this listener

men-Finally, one other best practice that you should consider when usingEXTPROC is to closely monitor and report on all usage of procedure cre-ation when using an external library and language such as C or Java Thisadded monitoring will give you better control over what developers mayhave injected into the database

runtime environments

With DB2 UDB 8.2, IBM no longer requires you to compile stored dures using an external C compiler This is a welcome feature and one wehave all been waiting for There are, however, some additional new features

proce-in 8.2 that provide broad flexibility proce-in terms of a callproce-ing and runtime ronment for procedures but that, as in the previous two subsections, blurthe line between the database and the operating system and are potentiallydangerous

envi-UDB 8.2 LUW (Linux/UNIX/Windows) allows you to run externalcode inside the DB2 engine This code could be Java classes or code written

to Microsoft’s Common Language Runtime (CLR) Both of these follow a

virtual machine architecture (see Chapter 5 for more details), and UDB 8.2

hosts both a Java virtual machine as well as a CLR This means that you canwrite Java, VB, or C# code and run it directly within the UDB process

As an example, let’s look at CLR support Using Visual Studio NET,you can write a C# method, compile it using the NET compiler, create theMicrosoft Intermediate Language (MSIL) assembly, and generate a DLL,which you place within the SQLLIB directory Then, register the codeusing a create command similar to the following syntax:

CREATE PROCEDURE (IN T VARCHAR(12)) LANGUAGE CLR

FENCED EXTERNAL NAME 'foo.dll:ns.Bar:foo';

214 7.2 Don’t make the database a Web server and don’t promote stored procedure gateways

Inside your C# code you can reference UDB constructs by importingthe IBM.Data.DB2 DLL, which gives you access to the DB2 NET pro-vider Because these are CLR routines, this will only work on the Windowsoperating system

DB2 UDB 8.2 for LUW is very new—it was released in the second half

of 2004 There are no vulnerabilities associated with this advanced feature

at the time of writing this chapter And yet, this advanced feature has thesame level of complexity as the features shown previously, and you shouldtread carefully or prefer using SQL/PL

don’t promote stored procedure gateways

In Chapter 5 you already learned that separation between the database

server and the Web/application server is a healthy thing This is an tant guideline and is worth stressing here again Unfortunately, databasevendors try to make the database an architecture for any development anddeployment pattern and in doing so include servers that are really not thefocus of database operations and that introduce unnecessary vulnerabilities.The prime example for this is the embedding of the Oracle HTTPServer with the Oracle 9i database The Oracle HTTP Server is a brandedApache Web server that is installed on your behalf as part of the database It

impor-is located under $ORACLE_HOME/Apache This added server can createnumerous problems—some due to simple vulnerabilities in the Apacheserver and some that occur when the Web server is allowed broad access tothe database In either case, the recommendation is to not use these fea-tures; it is better to have a full-blown application server make “traditional”calls to the database and have security built into both the application layerand the database

The first set of issues involves known (and unknown) Apache server nerabilities As an example, Oracle Security Alert #45 discusses a whole set

vul-of vulnerabilities present in the Oracle HTTP Server released with the cle database releases 8.1.7.x, 9.0.1.x, and 9.2.x

Ora-The more complex issue involves the Oracle HTTP Server allowing you(and actually encouraging you) to expose stored procedures to be executedthrough HTTP requests coming in through the Web server In effect, theWeb server becomes a gateway for database-stored procedures This is gen-erally not a good thing Most stored procedures are built as part of a data-base application and do not have the right level of validation and testing to

7.2 Don’t make the database a Web server and don’t promote stored procedure gateways 215

make them reusable functional elements that should be exposed to any gram that can make an HTTP request A lot of hard work is involved inmaking published APIs that are stable, robust, and secure Taking existingprocedures and making them callable from the Web does not ensure all ofthese things

pro-Two Apache modules are delivered with the Oracle HTTP Server andused to extend the Web server with functions that run within the Oracledatabase:

mod_plsql (The Oracle PL/SQL Toolkit) Allows you to directly cute stored procedures through Web server calls

exe-
mod_ose (The Oracle Servlet Engine) Allows you to call Java servletsthat are stored and executed in the database

mod_plsql is a dangerous option, and you should be aware of the issuesbefore you decide to use it Unfortunately, even if you have not thoughtabout this issue, the default installation will have activated this feature foryou—and with fairly broad access privileges Modules are loaded throughthe Apache configuration files In $ORACLE_HOME/Apache/Apache/conf, youhave a file called httpd.conf—Apache’s main configuration file At the veryend, the Oracle-specific configuration file is included, which in turnincludes the plsql configuration file

#

# include "C:\oracle\ora92\xdk\admin\xml.conf"

#

include "C:\oracle\ora92\Apache\modplsql\cfg\plsql.conf"

include "C:\oracle\ora92\Apache\jsp\conf\ojsp.conf"

216 7.2 Don’t make the database a Web server and don’t promote stored procedure gateways

#

include "C:\oracle\ora92\sqlplus\admin\isqlplus.conf"

# include "C:\oracle\ora92/oem_webstage/oem.conf"

In plsql.conf:

#

# Directives added for mod-plsql

# LoadModule plsql_module C:\oracle\ora92\bin\modplsql.dll

#

# Enable handling of all virtual paths

# beginning with "/pls" by mod-plsql

#

<IfModule mod_plsql.c>

<Location /pls>

SetHandler pls_handler Order deny,allow Allow from all

</Location>

</IfModule>

When mod_plsql is active, the plsql module is loaded into Apache andthe Oracle PL/SQL Web Toolkit (OWA PL/SQL packages) is loaded intothe database OWA PL/SQL packages are installed into the SYS databaseschema, making any potential vulnerability that much more dangerous

At this point you make calls using URLs of the form:

http://<hostname>:<port>/pls/<dad>/<package>.<proc>?<name1>=<val1>&

Hostname is the server on which the Oracle HTTP Server and the base are both running, and the port is that to which the HTTP server lis-tens Pls tells Apache to delegate the request to the mod_plsql module.Next comes the Database Access Descriptor (DAD) The DAD is defined

data-in the wdbsvr.app file in the mod_plsql config directory and specifies nection details such as a username and password to connect to, the number

con-of open connections to maintain in the pool, and so on After that come thepackage name and the procedure name, and finally the arguments to bepassed as parameters

7.2 Don’t make the database a Web server and don’t promote stored procedure gateways 217

The risk you face with mod_plsql is twofold: As mentioned, moststored procedures were not built as services that should be open for accessover the Web and may not have enough validation and exception handlingfunctions Exposing them to HTTP-based calls can make your environ-ment less secure Secondly, mod_plsql has several security issues that youshould care about:

DAD information is maintained in the sql/cfg/wdsvr.app file and user/password information is kept inclear text You should never keep user information in this file because

$ORACLE_HOME/Apache/mod-it creates too large of an exposure If you specify no username andpassword, the HTTP client will be challenged to provide these

By default there is no administrator password required for tering DADs, and an attacker can go to the following URL andadminister mod_plsql:

adminis-http://<host>:<port>/pls/admin_/

There are many procedures in the DBMS_%, UTL_% packages, and

in the SYS schema that may have been granted to PUBLIC becausethey were used by other stored procedures Many of these proceduresallow you to access sensitive information and will be very useful to anattacker You must remember to set up your DAD configuration file

to exclude these procedures from Web invocation so that an attacker

is not able to call them from outside the database This is done usingthe exclusion_list parameter in the wdsvr.app config file, for example:

exclusion_list=sys.*,dbms_*,utl_*

Unfortunately, this parameter is not even present in the sample

wdbsvr.app file that comes with the default installation

CERT vulnerability note VU#193523 shows how an attacker can use

a DAD that does not require the caller to be authenticated beforegaining access to procedures that the developer intended to requireauthentication This is a logical flaw in the mod_plsql design and notsomething that you can install a patch for

218 7.2 Don’t make the database a Web server and don’t promote stored procedure gateways

Oracle Security Alert #28 reports on eight different mod_plsql nerabilities, including several buffer overflow vulnerabilities, DoSvulnerabilities, and unauthorized access vulnerabilities

vul-
Mod_plsql adds procedures that help you produce Web pages as put (more on this in the next subsection) Once installed these can becalled from the Web through mod_plsql Some of these proceduresprovide powerful tools to an attacker For example,OWA_UTIL.SHOWSOURCE allows an attacker to view sourcecode of a package and is a good starting point to launch a Trojanattack (see Chapter 9)

Mod_ose is similar to mod_plsql but uses a Java servlet engine as the way to PL/SQL procedures It is similar to mod_plsql in its configuration(it also uses DADs), administration, and runtime Oracle suggests usingmod_plsql for stateless processing and mod_ose for stateful processing.However, mod_ose is not used as often as mod_plsql; if you’re going to use

gate-a servlet engine, you might gate-as well use Orgate-acleAS or gate-another J2EE gate-applicgate-a-tion server Many of the security issues present in mod_plsql are alsopresent in mod_ose

or remove the HTTP server

Unless you have a good reason to use the mod_plsql or mod_ose features,you should completely disable them by removing the loading of the mod-ules from the configuration file In fact, you would be even better offremoving the Oracle HTTP Server from your database host altogether,because it really doesn’t belong there and can probably at some point beused by an attacker

If you take another look at oracle_apache.conf, you will see thatremoving the server means that you will no longer have the benefit of usingiSQL*Plus iSQL*Plus is a Web-enabled version of SQL*Plus that allows aDBA or a developer to use SQL*Plus–like functionality using a Webbrowser rather than having to install an Oracle client and using SQL*Plus.From a security perspective, removing iSQL*Plus is a good thing.iSQL*Plus provides less control and identification options than SQL*Plusbecause all requests will now be coming from the same host—the database

host, actually The same problems reviewed in Chapter 6 related to

applica-7.3 Don’t generate HTML from within your stored procedures 219

tion-server architectures will now be introduced into DBA and applicationdeveloper access Finally, to make matters even worse, iSQL*Plus has a vul-nerability reported in Oracle Security Alert #46 relevant to Oracle 9iReleases 1 and 2 (9.0.x, 9.2.0.1, and 9.2.0.2) You can download a patch forthis problem (bug 2581911)

stored procedures

Mod_plsql offers several packages to help you respond to HTTP requestsand write HTML pages, including the following:

HTP Including procedures for writing HTTP responses

HTF Including functions for querying HTTP requests

OWA_COOKIE Including procedures that help you manage ies

cook-
OWA_UTIL Utility procedures

It is simple to write a procedure that generates and returns HTML pageswhen called through mod_plsql For example, a Hello World programusing mod_plsql that also sets a cookie valid for a day would look like:

CREATE OR REPLACE PROCEDURE HelloWorld AS BEGIN

220 7.4 Understand Web services security before exposing Web services endpoints

such as browsers A script can accept parameters, query or update the base, and then display a customized page showing the results

data-During development, PSPs can act like templates with a static part forpage layout and a dynamic part for content You can design the layoutsusing an HTML editor, leaving placeholders for the dynamic content.Then, you can write the PL/SQL scripts that generate the content Whenfinished, you simply load the resulting PSP files into the database as storedprocedures

Both of these features are another example of doing the right thing inthe wrong place Oracle is not unique in this—most of the latest releases inall databases support generating HTML pages from within procedures.However, database procedures should not be generating HTML pages; that

is just not what they were made for and what they excel at

From a security perspective, once you start writing the Web applicationwithin your procedures, you will have to start dealing with issues that arenormally classified as Web application security This complex topic willrequire you to learn and deal with many additional techniques, includingcross-site scripting, cookie poisoning, and more A study on Web applica-tion security done by Imperva during 2002–2003 shows that almost 80%

of Web applications are susceptible to cross-site scripting attacks and morethan 60% to parameter tampering You should assume that your Web

applications—now running inside the database—will have similar

prob-lems Appendix 7.A gives you a quick overview of cross-site scripting(XSS) and cookie poisoning It is not my intent to make you an expert onthe topic of application security Rather, you should understand that if youadopt Web page generation within the database, you will have to startdealing with another set of issues

exposing Web services endpoints

Web services have become one of the hottest topics these days (seeAppendix 7.B for a brief introduction to Web services) Web services seem

to be everywhere, and the database vendors just can’t help but add thisfunction into the database In the same way that the mod_plsql moduledescribed in the previous subsection creates a dangerous gateway directlyinto your database, such new functionality being introduced into the data-base servers creates a gateway exposing your procedures to a new populationand a new access pattern This is dangerous and risky, but it is difficult tofight against progress, especially when Web services are so dominant

7.4 Understand Web services security before exposing Web services endpoints 221

Therefore, you should understand what Web services are, be aware of

exactly what support your database is including for Web services, and

evalu-ate what you can safely use versus enabling access to everything

SQL Server 2005 supports Web services extensively and probably has themost functional such model today In fact, anything you’ve been used towith traditional clients can now be performed using a Web services inter-face Any types of queries and calls to stored procedures that were possible

in versions before 2005 using the Tabular Data Stream (TDS) over TCP/

IP, Named Pipes, or other protocols are now possible as SOAP over HTTP(over TCP/IP)

To set up this capability you need to create HTTP endpoints withinSQL Server 2005 Endpoints expose server functions as HTTP listeners.For example, to expose a procedure called FOO in the master database as aWeb service that will be called using a URL of the form http://<host>/ sql/foo, use the following DDL command This is similar to the way youdefine webmethods when creating Web services from VB or C# methods inVisual Studio NET:

CREATE ENDPOINT FOO_ENDPOINT STATE=STARTED

AS HTTP ( AUTHENTICATION=(INTEGRATED), PATH='/sql/foo',

PORTS=(CLEAR) )

FOR SOAP ( WEBMETHOD 'http://tempura.org'.'foo' (NAME='master.dbo.FOO'), BATCHES=ENABLED,

WSDL=DEFAULT )

Web methods have been successful in Visual Studio NET, and theirsuccess is now being replicated within SQL Server

You can inspect all HTTP endpoints using master.sys.http_endpoints

Once the endpoint is defined, you need to activate it by giving connection missions This looks similar to grants on a procedure:

per-222 7.4 Understand Web services security before exposing Web services endpoints

GRANT CONNECT ON HTTP ENDPOINT::foo_endpoint TO <DOMAIN/USER>

You can also set IP-based restrictions for endpoints to further limit whocan call which Web services endpoint

SQL Server 2005 supports four authentication options: basic, grated, digest, and SQL Authentication Authentication is first done at thetransport level as with Web servers If that is successful, the user’s SID isused to authenticate with SQL Server 2005 This is true for all optionsexcept SQL Authentication, which is the equivalent to mixed authentica-tion, in which case the login to SQL Server occurs separately In this casethe credentials are sent as part of the SOAP packet using WS-Security tokenheaders Integrated is based on Windows authentication

inte-Once the endpoint has been defined and connect permissions enabled,you can call the stored procedure by sending a SOAP request over HTTP.The request takes a form similar to the following:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body>

<sqlbatch xmlns="http://schemas.microsoft.com/SQLServer/ 2001/12/SOAP">

7.4 Understand Web services security before exposing Web services endpoints 223

an HTTP POST This servlet implements the Web service by accessingDB2, invoking the SQL operation defined in the DADX file, and returningthe results as a SOAP response The scheme is shown in Figure 7.2