Hi,
Major Thread to Web Service :-
The top threats directed at Web services are:
- Unauthorized access
- Parameter manipulation
- Network eavesdropping
- Disclosure of configuration data
- Message replay
- Unauthorized access – Web services that provide sensitive or restricted information should authenticate and authorize their callers
Solution – You can use the following countermeasures to prevent unauthorized access:
o Use password digests in SOAP headers for authentication.
o Use Kerberos tickets in SOAP headers for authentication.
o Use X.509 certificates in SOAP headers for authentication.
o Use Windows authentication.
o Use role-based authorization to restrict access to Web services.
- Parameter manipulation - Parameter manipulation refers to the unauthorized modification of data sent between the Web service consumer and the Web service.
Solution – You can use the following countermeasures to prevent this:
o 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.
o Encrypt the message payload to provide privacy and tamperproofing.
- Network eavesdropping – With network eavesdropping, an attacker is able to view Web service messages as they flow across the network
Solution – You can use the following countermeasures to prevent this:
o Use transport level encryption such as SSL or IPSec. This is applicable only if you control both endpoints.
o Encrypt the message payload to provide privacy. This approach works in scenarios where your message travels through intermediary nodes route to the final destination.
- Disclosure of configuration data
There are two main ways in which a Web service can disclose configuration data.
o First, the Web service may support the dynamic generation of WSDL or it may provide WSDL information in downloadable files that are available on the Web server. This may not be desirable depending on your scenario.
o Second, with inadequate exception handling the Web service may disclose sensitive internal implementation details useful to an attacker.
Solution – You can use the following countermeasures to prevent this:
o Authorize access to WSDL files using NTFS permissions.
o Remove WSDL files from Web server.
o Disable the documentation protocols to prevent the dynamic generation of WSDL.
o Capture exceptions and throw a SoapException or SoapHeaderException — that returns only minimal and harmless information — back to the client.
- Message replay
Web service messages can potentially travel through multiple intermediate servers. With a Message Replay Attack, an attacker captures and copies a message and replays it to the Web service impersonating the client. The message may or may not be modified.
The most common types of message replay attacks include:
o Basic replay attack. The attacker captures and copies a message, and then replays the same message and impersonates the client. This replay attack does not require the malicious user to know the contents of the message.
o Man in the middle attack. The attacker captures the message and then changes some of its contents, for example, a shipping address, and then replays it to the Web service.
Solution – You can use the following countermeasures to prevent this:
o Use an encrypted communication channel, for example, SSL.
o Encrypt the message payload to provide message privacy and tamperproofing.
o Use a unique message ID or nonce with each request to detect duplicates, and digitally sign the message to provide tamperproofing.
Authentication
If your Web service outputs sensitive, restricted data or if it provides restricted services, it needs to authenticate callers.
A number of authentication schemes are available and these can be broadly divided into three categories:
- Platform level authentication
- Message level authentication
- Application level authentication
- Platform level authentication
o If you are in control of both endpoints and both endpoints are in the same or trusting domains, you can use Windows authentication to authenticate callers.
- Message level authentication
o You can use WSE to implement a message level authentication solution that conforms to the emerging WS-Security standard.
o This approach allows you to pass authentication tokens in a standard way by using SOAP headers.
The following types of authentication token can be used and are supported by WSE:
§ User name and password
§ Kerberos ticket
§ X.509 certificate
§ Custom token
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:UsernameToken>
<wsse:Username>Bob</wsse:Username>
<wsse:Password>YourStr0ngPassWord</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken ValueType="wsse:Kerberosv5ST" EncodingType="wsse:Base64Binary">
U87GGH91TT ...
</wsse:BinarySecurityToken>
</wsse:Security>
<wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">
<wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary">
Hg6GHjis1 ...
</wsse:BinarySecurityToken>
</wsse:Security>
- Application level authentication
o Here you can design and build your own custom authentication by using custom SOAP headers for your application. If you must use a custom authentication mechanism, and you need to use cryptography, then use standard encryption algorithms exposed by the System.Security.Cryptography namespace.
Security Design Considerations
Before you start to develop Web services, there are a number of issues to consider at design time. The key security considerations are:
- Authentication requirements
- Privacy and integrity requirements
- Resource access identities
- Code access security
- Authentication requirements
o If your Web service provides sensitive or restrictive information, it needs to authenticate callers to support authorization.
o In Windows environments, you can use Windows authentication.
o However, where you are not in control of both endpoints, WSE provides authentication solutions that conform to the emerging WS-Security standard. I,e you can use the ‘Unauthorized access’ thread mentioned above.
- Privacy and integrity requirements
o If you pass sensitive application data in Web service requests or response messages, consider how you can ensure that they remain private and unaltered while in transit.
o To provide security against these, best is to use ‘XML Encryption’ or use transport level encryption through SSL or IPSec channels.
- Resource access identities
o Ensure that the least privileged ASPNET process account is used for local and remote resource access
- Code access security
o Your Web service’s 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.
o Similarly, the Web application’s 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.
Input Validation At Web Service Level
- Web services must validate the data that is passed to them to enforce business rules and to prevent potential security issues.
- Web methods which are the Web service entry points, can accept strongly typed input parameters or loosely typed parameters that are often passed as string data.
Below are the factors to be considered for input validation.
- Strongly Typed Parameters
- Loosely Typed Parameters
- XML Data
- SQL Injection
- Cross Site Scripting (XSS)
- Strongly Typed Parameters
- If you use strongly typed parameters that are described by the .NET Framework type system, for example integers, doubles, dates, or other custom object types such as Address or Employee, the auto-generated XSD schema contains a typed description of the data. Consumers can use this typed description to construct appropriately formatted XML within the SOAP requests that are sent to Web methods.
- The benefit of this strong typing approach is that the .NET Framework parses the input data for you and validates it based on the type definition. However, inside the Web method you might still need to constrain the input data.
- Loosely Typed Parameters
- If you use string parameters or byte arrays to pass arbitrary data, you lose many of the benefits of the .NET Framework type system. You must parse the input data manually to validate it because the auto-generated WSDL simply describes the parameters as string input of type xsd:string.
- XML Data
- Web method can use the System.Xml.XmlValidatingReader class to validate the input XML data.
- SQL Injection
- If your Web methods access the database, they should do so using SQL parameters and ideally, parameterized stored procedures to avoid SQL Injection attacks.
- Cross Site Scripting
Thanks & Regards,
Arun Manglick || Senior Tech Lead
No comments:
Post a Comment