After the discussion on client configurations betraying your infrastructure choices, my talk with Sim Pul Simon (my corrected spelling) turned to other server examples.
It was a good discussion with Sim Pul Simon, our talk on how our system tool choices provide so much information about our clients and their vulnerabilities. After that, it was time to examine our server 'broadcasts,' broadcasts that key the hacker into our vulnerabilities.
It's more than Office-generated webpages that holler your problems. There are two wonderful vulnerability websites I discussed with Sim Pul: Open Source Vulnerability DataBase and the National Vulnerability Database that NIST.gov provides. (I'll discuss these in another blog.)
Do a search on .Net/ASP or Java or PHP. You will find LOTS of entries for those tools. When the world navigates to your website and sees *.jsp, *.asp|*.aspx, *.cfm, or *.php; the world is given a clue about your infrastructure, including the information in web server headers.
Unlike so many application platforms before it, websites are good about offering the 'view source' option. To what degree is your app logic stuffing important information into 'hidden' fields? If your technology supports something as sweet as transactional signing, are your developers using it?
Maybe your application is some binary and classes distributed with it. If so, load it up, read-only, into some editor like edit.com. Does your binary betray that it was built with an early version of Visual Studio?
More and more, obfuscation is used to 'hide' code's purpose, by hacker and commercial coders alike. Too much, however, remains in the code. Do you strip debug values from your final code? While viewing a binary in edit.com, does the attacher see online help and function names in plain english? Yes, all of this information is easily disassembled, but the stacking of small tools like this can get many to go on to some other piece of software.
There is no security in obscurity, so obsfuscation is no comprehensive security plus. It is a small part of a total security package. If there's anything I'd hope you the reader would do, I'd hope you would update your infrastructures quickly and effectively. Also, write your code with the idea the source is open, even if it is a commercial project. Much like a good wine, your code will betray any traces of poor preparation and worst ingredients shoveled into the work vat.
P.S. I do not represent or have any relationship with OWASP.org. I do encourage you to check out the site and the many resources they provide the conscientious coder.