McClure S., Shah S., Shah S. Web Hacking(c) Attacks and Defense / Advanced Techniques for Technology Identification

Computers & Technology
Education & Reference
Business & Investing
Science & Math

Web Hacking(c) Attacks and Defense
Authors: McClure S., Shah S., Shah S.
Published year: 2005
Pages: 55-56/156

<< Previous page
Table of contents
Next page >>

Advanced Techniques for Technology Identification

If HTTP headers, file extensions, URL signatures, HTML comments, and cookies are insufficient to identify Web application server technologies, the only remaining approach is to force the application to generate an error. Not only do error messages give away the type of application server being used, but they also reveal other sensitive data, including physical path mappings, references to files and library files, and even entire SQL queries!

We can force a Web application server to return an error by using:

· Truncated URLs

· Requests for nonexistent files

· Parameter tampering

Let's find out whether we can use error forcing to determine the type of application servers being used in the following two examples.

Examples

URL: http://www8.example.com/webapp/wcs/stores/servlet/Display?storeId= 10001&langId=-1&catalogId=10001&categoryId=10052&clearance=0&catTree= 10052

Instead of sending the full URL, we send a truncated URL: http://www8.example.com/webapp/wcs/stores/ . The resultant error is shown in Figure 6-9 .

Figure 6-9. Forcing an error on www8.example.com

graphics/06fig09.gif

The error messages states that the application server being used on www8.example.com is IBM WebSphere.

URL: https ://www9.example.com/OA_HTML/store.jsp?section=101&prod_ses=j= 4081:Guest:US:jtfpfalse:jtfpi-1:671:504:75123~zv=75123~zs=t~zp=504~zo=2~zm= 101~zj=Guest~zi=504

The front-end server in this case is Apache. Sending a request with multiple combinations of truncated URLs didn't work. All we got back was a 404 File not found error, which said nothing about the application server type. The HTTP 404 error message was being served by the front-end Web server when it couldn't find the resource. Hence we have to devise a URL that forces an error out of the application server but that is not touched by the front-end Web server itself.

Let's think about interfacing the application server with the front-end Web server for a minute. Of the various interfacing techniques we discussed earlier in the chapter, this URL suggests that the front-end Web server is be using URL rewriting and internal proxying to execute .jsp files. Keeping this in mind, if we make a request for a nonexistent .jsp file called x.jsp, we should bypass the front-end Web server, because all requests for .jsp are handed to the application server. When we do so, we get the error message returned by the application server shown in Figure 6-10 .

Figure 6-10. Forcing an error on www9.example.com

graphics/06fig10.gif

The trick worked! We now have an error returned by an Oracle application server running behind an Apache Web server. The error message also discloses the physical path, /u01/prodcomm/portal/, which is mapped to the JSP directory.

Identifying Database Servers

Identifying database servers is even trickier than identifying front-end and internal application servers. Identifying front-end and internal application servers is easier because both communicate in HTTP. Their signatures work their way into various elements of HTTP, such as the URL, HTTP header, and cookies.

In contrast, database servers communicate with internal application servers in SQL. The only elements of a URL that get passed to the database interface are the values being exchanged by means of various input fields and URL parameters. Thus the only way to identify back-end databases through URLs is to force them to generate errors that are reflected by the application server and end up being sent back to the Web browser.

Let's consider two URLs:

· http://www.example.com/public/index.php?ID=27

· http://www.example.org/Profile.cfm?id=3&page=1

The first URL has a PHP script, index.php, which seems to make use of a database as suggested by the URL parameter " ID=27. " The second URL is a ColdFusion application, which again seems to perform database queries based on the parameter id.

To force the database servers to return an error involves tampering with the values passed to the parameters in both cases. For the first URL, we substitute a nonnumeric ID value for " 27. " For the second URL, we prematurely truncate the query by replacing the value 3 with a single quotation mark. Figures 6-11 and 6-12 , respectively, show how the errors appear.

Figure 6-11. Forcing a database error with PHP

graphics/06fig11.gif

Figure 6-12. Forcing a database error with ColdFusion

graphics/06fig12.gif

We leave it to you to figure out how much damage is done by simply obtaining the types of information displayed in these error messages! Hint: The ColdFusion SQL Server error message contains enough information to launch a URL request that possibly could cause remote command execution with Administrator privileges on the database server of the Web application.