I am testing web service on production. There is a standard SVC web page available like the example below (another randomly selected webpage, just for example). Is it ok to have this page available on the production environment?
The Web Services Definition Language (WSDL) provides all details necessary for binding to the service and is considered an information disclosure finding when the target of a pen test. While the following is dated, they still hold true today.
The following was taken from a Black Hat Europe 2007.
As with any other web application attack, the first step in formulating an attack on a web service is discovery and fingerprinting of the service deployment. The information gathered at this first stage is crucial to identifying possible entry points and carrying out an attack that is directed at the heart of the web service.
Luckily for today's hackers, web services are often deployed with what many refer to as a 'blueprint for attack'. The WSDL file is a web services deployment descriptor that outlines not only the functionality provided by the web service, but also the expected syntax, the input and output points, and the location to access the service. In other words, the web service is announcing to the world its location, the methods it provides and assumptions it is making regarding its input points -- a goldmine for anyone with malicious intent.
This snippet was taken from OWASP Europe Conference, Leuven, Belgium, May 30-31, 2006.
WSDL and Access Scanning
A WSDL document contains information pertaining to the Web service such as available operations, the content of the messages each of these operations accept and return, and the endpoints that are available to invoke the operations. Securing a Web service should rely on cryptographic measures to fully protect information rather than obscurity (security by obscurity should be avoided), because the information that a WSDL provides can expose certain architectural aspects about the Web service that could make it easier for an unauthorized user to mount an attack.
For example, attackers can determine valid request formats by examining the schemas and message descriptions in the WSDL that can contain operations such as getItemByTitle, getItemById, placeOrder, getPendingOrders, etc. Knowing this information, the attacker may be able to guess other possibly hidden operations such as updateItem, and perhaps use this information to place items on sale and then place orders using newly discounted prices. In fact, it is easy for a developer to introduce such vulnerabilities to a Web service since WSDLs are mostly generated automatically and contain a full description of the available operations. Developers may later comment out the operation section to hide it the service, but leave related information such as the message descriptions and schema types of these operations intact.
The only thing I would add is that public and private services should be handled differently.
Public Service - If the WSDL describes only publicly accessible content and the service is publicly accessible, there's no risk having it remain public.
Private Service - A service requiring authentication/authorization of any kind should have it's WSDL protected in a similar manner.