A very typical scenario is that by default the Tomcat Servers tend to have a 404 Error page that displays the name of the file that was requested and not found. It seems to me that though display of such pages might be considered as merely an informational item for the purpose of any security test…this definitely presents a risk.
E.g., take this scenario.
1. The attackers has a SQL injection vulnerability in an application
2. The App server and DB can reach each other
3. The DB cannot directly reach the attacker and his system (on any port outbound)
4. The app server issues 404 error messages with the name of the file being disclosed in the 404 error message (e.g., The requested resource indexblah.html was not found).
5. The attacker can see the responses to the injected SQL queries (i.e., the injection is not blind).

Assuming that the DB accesses have been tightly controlled and you can’t get much access to any tables except the current one. This can be exploited as follows:
Invoke a SQL query (in the injection string) on the DB to request a page from the app server based on the contents of the DB such as send me /blahusername, /blahpassword where /blah is a string the attacker’s put in to make sure that such a resource doesn’t actually exist on the app server and username and password are columns or DB names from the DB. These error messages will be reflected in the response to the SQL query to the attacker. This could create an interesting side-channel attack whereby even though the data from the DB doesn’t actually reach the attacker, it can be inferred from the 404 – error messages.


___________       ______________        __________
| Attacker| <===> | App server | <=====>|  DB    |
___________       ______________        __________
      1  ----------> 2  -----------------> 3
                     5  <----------------  4
                     6  -----------------> 7
      10 <---------- 9 <-----------------  8   
1. Attacker sends sql to make the db query the app server for a non-existent page
2. The app server sends this sql query to the DB
3. The DB receives this SQL query and acts on it
4. The HTTP query for a missing resource is sent to the app server
5. App server looks up the resource and can't find it
6. The App server responds with a 404 /blahusername not found
7. The response recd is put in the SQL query response
8. The SQL query response is sent to the app server
9. The App server received the SQL query response (404 /blahusername not found as a line in there)
10. The attacker receives the 404 response with the data from the username in the 404 error message

An interesting attack vector to say the least!