Article
Search Engines Expose Web Services
For several years, search engines such as Google have been automatically finding, indexing, and serving web pages that developers never intended anyone to see. The developers reasoned that if no one could see the pages, the contents of those pages didn’t matter. Malicious hackers have abused this “security through obscurity” approach to attack poorly protected and often unsuspecting web sites.
The same search engine techniques can also be used to identify poorly secured web services.
Unsecured web administration interfaces are a classic example of this problem. Unsuspecting developers still continue to place powerful yet vulnerable system administration interfaces on public web sites that allow any user to make system configuration changes. Entire resources such as Johnny Long’s website (http://johnny.ihackstuff.com) have sprung up and are dedicated to finding vulnerable and interesting sites through the use of Google. More recently the Santy worm used Google to compromise many thousands of computers around the world.
Web services have special “formulas” by which they are activated. Unless this information is known it is very difficult to induce web services into producing useful results. The Web Services Description Language (WSDL) was created and standardised as a method for easing this interoperability problem. In most cases publicly sharing such a description will quite deliberately allow entities to use a particular web service.
In cases where the developer is unaware of the automatic publishing of WSDL documents under an environment, or where the web service is intentionally being kept secret, information disclosure problems can arise. For example, entering the keyword "asmx?wsdl" into Google searches for a file that .Net uses to locate web services. Google yields an amazing ten thousand three hundred (10,300) results generated by the .Net platform. Most of the results have been intentionally made public but a significant proportion of these results identify an unwanted exposure of web services that are assumed by developers to be private.
Publishing WSDL documents may introduce unnecessary risk exposure to organisations. Decisions to publish these documents should be examined closely for security issues and weighed up against usability gains. A worthwhile alternative may be for organisations to deliver WSDL files to entities requiring use of the web service in an out-of-band manner instead (eg. email, mail, or ftp). Through using such an approach, the risk exposure from the WSDL being available will be reduced. It should be noted however that this method alone should not be considered a complete solution - defence-in-depth best practices also need to be implemented.
Awareness of the power of search engines such as Google is crucial to the security of all web applications. In the wrong hands, sophisticated search engines can be used as excellent target discovery tools for web services. Until stakeholders in web services fully consider the information being made available to the Internet, these systems will suffer a similar fate to standard web applications – continual security breaches with the aid of search engines.
For more information see the following resources:
Google Hacks:
http://johnny.ihackstuff.com
Google Search:
http://www.google.com.au/search?hl=en&q=%22asmx%3Fwsdl%22
The same search engine techniques can also be used to identify poorly secured web services.
Unsecured web administration interfaces are a classic example of this problem. Unsuspecting developers still continue to place powerful yet vulnerable system administration interfaces on public web sites that allow any user to make system configuration changes. Entire resources such as Johnny Long’s website (http://johnny.ihackstuff.com) have sprung up and are dedicated to finding vulnerable and interesting sites through the use of Google. More recently the Santy worm used Google to compromise many thousands of computers around the world.
Web services have special “formulas” by which they are activated. Unless this information is known it is very difficult to induce web services into producing useful results. The Web Services Description Language (WSDL) was created and standardised as a method for easing this interoperability problem. In most cases publicly sharing such a description will quite deliberately allow entities to use a particular web service.
In cases where the developer is unaware of the automatic publishing of WSDL documents under an environment, or where the web service is intentionally being kept secret, information disclosure problems can arise. For example, entering the keyword "asmx?wsdl" into Google searches for a file that .Net uses to locate web services. Google yields an amazing ten thousand three hundred (10,300) results generated by the .Net platform. Most of the results have been intentionally made public but a significant proportion of these results identify an unwanted exposure of web services that are assumed by developers to be private.
Publishing WSDL documents may introduce unnecessary risk exposure to organisations. Decisions to publish these documents should be examined closely for security issues and weighed up against usability gains. A worthwhile alternative may be for organisations to deliver WSDL files to entities requiring use of the web service in an out-of-band manner instead (eg. email, mail, or ftp). Through using such an approach, the risk exposure from the WSDL being available will be reduced. It should be noted however that this method alone should not be considered a complete solution - defence-in-depth best practices also need to be implemented.
Awareness of the power of search engines such as Google is crucial to the security of all web applications. In the wrong hands, sophisticated search engines can be used as excellent target discovery tools for web services. Until stakeholders in web services fully consider the information being made available to the Internet, these systems will suffer a similar fate to standard web applications – continual security breaches with the aid of search engines.
For more information see the following resources:
Google Hacks:
http://johnny.ihackstuff.com
Google Search:
http://www.google.com.au/search?hl=en&q=%22asmx%3Fwsdl%22