›› Client-Server application: It is a client server application or application component for communication.
›› Method of communication: Its method of communication between two devices over the network.
›› Protocol for exchanging information between two applications.
Why do we need Web services?
- Exposing the existing function on to the network.
- connecting different Applications I.e. Interoperability
- standardized protocol
- Low Cost of communication
Web Services Types:
- SOAP web services
- RESTful web services
|SOAP (Simple Object Access Protocol)||REST (REpresentational State Transfer)|
|SOAP is a protocol||REST is an architectural style.|
|SOAP can’t use REST because it is a protocol||REST can use SOAP web services because it is a concept and can use any protocol like soap, HTTP.|
|SOAP uses services interface to expose the business logic.||REST uses URI to expose business logic.|
|SOAP defines standards to be strictly followed.||REST does not define too much standards like SOAP.|
|SOAP permits XML data formats only.||REST permits diff. data formats such as .txt, html, xml etc.|
|SOAP is less preferred than REST.||REST more preferred than SOAP.|
Web services components: –
Three major components have web services: –
As we have already discuss about SOAP so next we start with WSDL: –
- WSDL: – WSDL is a web services description language. WSDL is an XML document containing information about web services such as method name, method parameter and how to access it. WSDL is a part of UDDI. It acts as an interface between web service applications. It is pronounced as “wiz-dull”.
- UDDI: – UDDI is a Universal Description, Discovery, and Integration. UDDI is an XML based framework for describing, discovering and integrating web services. It is a directory of web service interfaces described by WSDL, containing information about web services.
Tools used to test Web services: –
- SoapUI: – tool for testing SOAP and RESTful web services
- Poster: – add on in Firefox browser
- Postman: – extension for Chrome
SoapUI: – SoapUI is a free and open source cross-platform Functional Testing solution. With an easy-to-use graphical interface and enterprise-class features, SoapUI allows you to easily and rapidly create and execute automated functional, regression, compliance, and load tests. In a single test environment, SoapUI provides complete test coverage and supports all the standard protocols and technologies. There are simply no limits to what you can do with your tests.
Poster: – A developer tool for interacting with web services and other web resources that lets you make HTTP requests, set the entity body, and content type.
POSTMAN or POSTMASTER:
Postman features include:
- History of sent requests
- Create requests quickly
- Replay and organize
- Switch context quickly
- Built-in authentication helpers
- Customize with scripts
- Robust testing framework
- Automate collections
Web Services Technologies and Attacks:
- XML Based Attacks
- Discovery Methods
- Traditional Attacks
SOAP Attacks: There are different types of attacks of SOAP web services.
- SOAP Header: – Provide instructions on how a message should be handled. Often not necessary in basic applications. Still parsed/obeyed by WS frameworks. So many standards, so many attack surfaces. Header allows arbitrarily complex XML to support future standards
- Source routing used to bypass security checks.
- Routing will become more common as companies provide unified WS interfaces to multiple machines. Possibly provided by “XML Firewall” devices.
- XML Complexity DoS in SOAP Header
- Not checked against XSD
2. SOAPAction Header:
Sometimes needed, sometimes filtered to attempt to remove soap requests. Often not required at all. Configurable in .NET with Routing Style attributes.
- Bypass protections that rely on SOAPAction
3. Session management:
- SOAP, like HTTP, is stateless!
- Developers need to program their own state mechanism. Options include:
- In-line SessionID, defined
- Cookie in header
- SOAP is transport independent, so a message should be able to be passed without session information from the transport, such as a HTTP cookie
- Often used, but it’s a hack
- Cookies might be stripped at the web server, or not properly routed to the part of the app where decisions are being made.
- New WS-I cryptographic standards might allow developers to bootstrap state.
- Classic state attacks work.
- Predictable IDs are still predictable.
- But, XSS cannot easily access in-band stateID.
- SOAP, being stateless, might make applications vulnerable to replay attacks.
- Need to make sure XML cryptographic protections also include anti-replay.
4. Soap Array Attack
Red box = attacked web service component
Black box = attacker location
blue box = other web service components not actively used in the attack
- The attack can be stopped by using strict schema validation. In most cases, the maximum number of array elements is known. Let’s make an example. We assume that only 10 elements are allowed, not more.
- If we cannot limit the number of maximal elements per default, another solution has to be found. In this case, it is best to compare the number of declared elements in the “soapenv_arrayType” attribute with the number of actual existing array elements. In case they don’t match, the SOAP message is discarded. This feature has to be implemented by hand by the web service developer.
SOAP error from XPATH Injection:
RESTful Web Services:
Compared to SOAP-Based Web services, which face many limitations discussed above and are somewhat difficult to implement, a REST-based approach to Web services is much easier to implement since its design simply relies on the HTTP protocol. It uses:
- URIs (Uniform Resource Identifiers) to identify resources
- GET, PUT, POST and DELETE actions to retrieve, update, create, and delete the resources remotely through Web servers.
Data transfer security in a single REST-based Web service can be easily achieved by encryption using HTTPS. In a server providing sophisticated REST-based Web services, such as Facebook, Google, and Twitter, Auth is a popular solution for authorizing third-party applications and so the application’s user session can obtain a credential once and use it whenever the access to server resources is necessary.
Pen Testing RESTful Web Services:
1. Inspecting the application does not reveal application attack surface:
- None Web applications
- Not all Web Service functionality actually used by application
2. Fuzzing standard parameters not sufficient anymore:
- Uses none standard parameters.
- Serialized inputs as JSON or XML
3. Custom authentication and session management breaks common cookie sharing practices.
4. Unauthorized Privileged actions and sensitive resource collections.
5. Invalid incoming content-types
1. Look for none standard headers.
2. Determine if URL segments have a pattern.
- Numerical values
- Well known templates
3. Look for structures in parameter values
- JSON, XML, YAML or other
4. Look for irregular 404 responses
- Including site specific “file not found” messages.
5. Brute force
- Change methods
- Attack any URL segment
Automated RESTful Penetration Testing: –
- Determining attack surface
- Historically only links based
- Parameter based
- Sending known attack vectors
- Fuzzing parameters
- Comparing behaviour for different users or before and after login
- Understanding request generation (i.e. links)
- Understanding parameters
- Understanding session management
Web Services: Discovery Methods
- Registries that list web services across multiple servers.
- Auto-magically works on some systems, such as .Net
- Multiple authorities have created classification schemes.
- UDDI servers support authentication and access control, but this is not always the default (or common) configuration for Internet-accessible services.
- UDDI points an attacker to all the information they need to attack a web service.
2.UDDI Business Registry (UBR)
- Four major servers, run by IBM, Microsoft, SAP, and NTT
- Has beautiful, searchable interface to find targets.
- Obviously, also searchable by web services.
- No binding authentication of registry
- New WS-Security standards are building a PKI to authenticate UBR->Provider->Service
- Confusion might be an attackers friend