Building Secured Web Services

BUILDING SECURED WEB SERVICES

 

Overview

 

Web services are used by an increasing number of companies as they expose products and services to customers and business partners through the Internet and corporate extranets. By exposing to the external world it has its own potential threats.

 

Threats and Counter Measures

 

Top threats directed at web services are

 

1.       Unauthorized access

2.       Parameter Manipulation

3.       Network eavesdropping

4.       Disclosure of configuration data

5.       Message replay

 

 

 

Unauthorized Access

 

Vulnerabilities

Counter Measures

1.       No Authentication used

2.       Passwords passed in Plain Text in Soap Headers

3.       Basic Authentication used over an encrypted communication channel

 

Use password digests in SOAP headers for authentication.

Use Kerberos tickets in SOAP headers for authentication.

Use X.509 certificates in SOAP headers for authentication.

Use Windows authentication.

         Use role-based authorization to restrict access to Web services. This can be done by using URL authorization to control access to the Web service file (.asmx) or at the Web method level by using principal-permission demands.

 

 

Parameter Manipulation

 

Vulnerabilities

Counter Measures

1.       Messages that are not digitally signed to provide tamper proofing.

  1. Messages that are not encrypted to provide privacy and tamper proofing.

 

          Digitally sign the message. The digital signature is used at the recipient end to verify that the message has not been tampered with while it was in transit

.       Encrypt the message payload to provide privacy and tamperproofing.

 

 

 

 

 

Network Eavesdropping

 

Vulnerabilities

Counter Measures

1.       Credentials passed in PlainText in SOAP Headers

2.       No message level encryption is used

  1. No transport level encryption is used.

 

          Use Transport level encryption such as SSL or IPSec.This is appreciable only if you control both endpoints

o     Encrypt the message payload to provide privacy. This approach works in scenarios when your message travels through intermediary nodes route to the final destination.

 

 

 

Disclosure Of Configuration Data

 

Vulnerabilities

Counter Measures

1.       Unrestricted WSDL Files available for download from the web server

2.       A restricted web service supports the dynamic generation of WSDL and allows unauthorized consumers to obtain web services characteristics

3.       Weak exception handling.

          Authorize access to WSDL files using NTFS permissions.

          Remove WSDL files from web server

          Disable the documentation protocols to prevent the dynamic generation of WSDL

          Capture exceptions and throw a SoapException or SoapHeaderException that returns only minimal and harmless information.

 

 

Message Replay

 

Vulnerabilities

Counter Measures

1.       Messages are not encrypted

2.       Messages are digitally signed to prevent tampering.

3.       Duplicate messages are not detected because no unique message ID is used.

          Use Encrypted communication channel for example SSL

          Use a Unique message ID

          Encrypt the message payload to provide message privacy and tamper proofing.

 

 

Design Considerations

 

1.       Authentication Requirements

2.       Privacy and Integrity Requirements

3.       Resource Access Identities

4.       Code Access Security

 

Authentication Requirements

 

Please refer Authentication Section to get more information.

 

Privacy and Integrity Requirements

 

 WSE provides integrity checking through digital signatures, and it also supports XML encryption to encrypt sensitive elements of the entire message payload. The advantage of this approach is that it is based on the emerging WS-Security standard and that it provides a solution for messages that pass through multiple intermediate nodes. The alternative is to use transport level encryption through SSL or IPSec channels.

 

Resource Access Identities

 

We can use ASPNET process account to access remote network resources such as SQL Servers that require Windows authentication, by creating a mirrored local account on the database server.

 

Code Access Security

 

Consider the trust level defined by security policy in your target deployment environment. Web services trust level defined by its <trust> element configuration, affects the types of resources that it can access and the other privileged operations it can perform.

 

Also, if you call a Web service from an ASP.NET Web application, the Web applications trust level determines the range of Web services it can call. For example, a Web application configured for Medium trust, by default, can only call Web services on the local computer.

 

Authentication

 

A number of authentication schemes are available which are divided in three categories mentioned below.

 

1.       Platform Level Authentication

2.       Message Level Authentication

3.       Application Level Authentication

 

Platform Level Authentication

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish