SQL Server Security

Sunday, September 28, 2008

Microsoft Silverlight security

Good first on view on latest Microsoft Silverlight security bloghttp://blogs.msdn.com/shawnfa/archive/2007/05/09/the-silverlight-security-model.aspx

Labels:

Wednesday, January 30, 2008

Windows Communication Foundation Security guide

Here is good link related to WCF security

http://www.theserverside.net/tt/articles/showarticle.tss?id=WCFSecurityLearningGuide

Wednesday, September 26, 2007

Encrypting connections in SQL Server 2005 & SQL Native Client with SSL

The following Link summarize settings for SQL server 2005 for protecting sensitive data in transit using SSL.


http://blogs.msdn.com/sql_protocols/archive/2005/11/10/491563.aspx

Labels:

Thursday, August 23, 2007

Code Module Signing in SQL Server 2005

SQL Server 2005 is that it provides the ability to digitally sign code modules to SP,triggers,functions with digital certificate. we sign the code with the private key contained within the certificate which means access to the tables are only provisioned to the certificates that have been used to sign the module. it is true for SPs too.


If it has an unbroken ownership chain, you carefully control which users get EXECUTE permission on the procedure, and you deny direct access to the underlying tables. But this doesn’t help in situations such as when the procedure has a broken ownership chain or executes dynamic SQL, requiring that the user executing the procedure have permissions to the underlying tables. Another way to achieve the same effect is to use EXECUTE AS, but this changes the security context under which the procedure executes. This may not be desirable, for example, if you need to record in the table the user who actually caused the procedure to run (short of requiring a user name as a parameter to the procedure).
Signing code modules has the additional benefit of protecting against unauthorized changes to the code module. Like other documents that are digitally signed, the certificate is invalidated when the code changes. The code doesn’t execute under the context of the certificate, so any objects that have their access provisioned to the certificate will not be accessible.
To do this, you create a certificate, associate it with a new user, and sign the procedure with the certificate. Grant this user whatever permissions are necessary to execute the stored procedure. In essence, this user is added to the security context of the stored procedure as a secondary identity. Then grant execute permissions to whatever users or roles need to execute the procedure. The following code shows these steps. Assume that you want to sign the mySchema.GetSecretStuff procedure, and that all of the referenced objects already exist in the database:


CREATE CERTIFICATE certCodeSign
ENCRYPTION BY PASSWORD =
'asdf@#$kdkf"
WITH SUBJECT = 'Codesigncertificate'
GO

-- Sign the stored procedure
ADD SIGNATURE TO mySchema.GetSecretStuff BY CERTIFICATE certCodeSign
WITH PASSWORD = 'asdf@#$kdkf'
GO

-- Map a user to the certificate
CREATE USER certUser FOR CERTIFICATE certCodeSign
GO

--Assign SELECT permissions to new certUser
GRANT SELECT ON SocialSecurity TO certUser
GO

-- Grant execute permission to the user who will run the code
GRANT EXECUTE ON mySchema.GetSecretStuff TO ProcedureUser
GO


Now only users explicitly granted EXECUTE permission on the stored procedure are able to access the table’s data.

Labels: ,

Monday, August 20, 2007

Status of various SQL services after initial Installation

Lists the various SQL Server services, and the default state upon installation. For certain services, you can elect during installation to auto-start the service when Windows restarts, which affects the initial Windows service startup state

Service Startup---------->[AutoStart State] ---------->Default State

Analysis Services----------> Automatic---------------> Started

Full-Text Search----------> Automatic---------------> Stopped

Integration Services-------> Automatic---------------> Started

Notification Services-----> Unconfigured----------> Unconfigured

Reporting Services-------> Automatic---------------> Started

SQL Browser-------------> Disabled ---------------->Stopped

SQL Server--------------> Automatic---------------> Started

SQL Server Agent-------> Manual ------------------> Stopped

SQL Writer-------------> Disabled------------------> Stopped

SQL Server AD Helper -->Disabled----------> Stopped

Labels:

Friday, August 17, 2007

Why I Can Hack Your Network in a Day!

Marcus Murray´s Blog

TechNet Webcast: Why I Can Hack Your Network in a Day! [A live demonstration of techniques and tools used by hackers to compromise your network]

Labels:

Wednesday, August 15, 2007

SQL Server 2005 Endpoint authentication



SQL Server 2005 supports both the traditional, binary Tabulate Data Stream for client access to data as well as native XML Web service access using HTTP. The primary benefit of allowing access via HTTP is that any client software and development tools that understand Web service protocols can access data stored in SQL Server. This means SQL Server 2005 can provide standalone Web service methods as well as be a complete endpoint in a Service Oriented Architecture (SOA).
Using SQL Server 2005 as a Web service host requires two general steps, each with plenty of possible variations: defining stored procedures and user-defined functions that provide the Web service methods, and defining an HTTP endpoint that receives method calls via HTTP and routes them to the appropriate procedure.

Because XML Web services in SQL Server uses HTTP and, by default, port 80, most firewalls are configured to allow the traffic to pass. But an unprotected endpoint is a potential vector for attacks and must be secured, so SQL Server is designed with strong authentication and authorization. No endpoints are installed by default with SQL Server and you have to have a high level of permissions to create, alter, and enable HTTP endpoints.
SQL Server 2005 provides five different authentication types, similar to those used by IIS for Web site authentication.
Basic authentication
Basic authentication is defined as part of the HTTP 1.1 protocol, which transmits the login credentials in clear text that is base-64 encoded. The credential must map to a Windows login, which is then used to authorize access to database resources. If you use Basic authentication, you cannot set the PORTS argument to CLEAR but must instead set it to SSL and use a digital certificate with SSL to encrypt the communication with the client software.
Digest authentication
Digest authentication is also specified as part of the HTTP 1.1 protocol. It hashes the credentials with MD5 before sending to the server so that they are not sent across the wire, even in encrypted form. The credentials must map to a valid Windows domain account; you cannot use local user accounts.
NTLM authentication
NTLM uses the challenge-response protocol originally introduced in Microsoft Windows NT® and supported in all client and server versions of Windows since. It provides secure authentication when both client and server are Windows systems, and requires a valid domain account.
Kerberos authentication
Kerberos authentication is available with Windows 2000 and later, based on an industry-standard protocol available on many operation systems. It allows for mutual authentication in which both the client and server are reasonably assured of the other’s identity and provides a highly secure form of authentication. To use Kerberos on Windows Server 2003, you must register the Kerberos Service Principal Name (SPN) with Http.sys by using the SetSPN.exe utility that is part of the Windows Support Tools.
Integrated authentication
Integrated authentication provides the best of NTLM and Kerberos authentication. The server uses whichever of the two authentication types the client requests, allowing the most secure authentication the client supports while making the service available to older versions of Windows. You can configure Http.sys in Windows 2003 to negotiate with the client which protocol to use.
The authentication method used for an endpoint is set with the AUTHENTICATION attribute of the CREATE or ALTER ENDPOINT statement. For example, the following code creates an endpoint that uses Kerberos for authentication:
CREATE ENDPOINT myEndpoint
STATE=STARTED
AS HTTP (PATH = '/JainHttpEndpoint',
AUTHENTICATION = (KERBEROS),
PORTS = (CLEAR),
SITE = 'JainSqlServer')
FOR SOAP (WSDL = DEFAULT,
DATABASE = 'Jain',
NAMESPACE = 'http://example.com/jainSqlServer/myDB/WebService')
SQL Server 2005 supports endpoints that listen both to HTTP as well as a user-defined port on TCP. You can also format requests using a variety of formats: SOAP, Transact-SQL, a format specific to Service Broker, and another used for database mirroring. When using SOAP you can take advantage of WS-Security headers to authenticate SQL Server logins.
Microsoft has implemented Web service endpoint authentication to support a wide variety of protocols and specifications, of which this paper has touched on just a few. You’ll need to explicitly enable your authentication option and ensure that clients are able to provide the type of credentials required.