Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

As a person who is learning pentesting, I want to know if it is possible to predict the underlying technology used for the developement of the site from the URL?

For example: This is the URL of the site

https://www.somesite.com/cgi-bin/bv60.dll/somesite/services/history.do?click=true&LinkValue=2&BV_SessionID=@@@@1169531050.1338361729@@@@&BV_EngineID=ccdeadfglgghiigcefecehidfgmdfil.0&canhistory=3&voucher=5

What does the cgi-bin & bv60.dll & BV_EngineID tell us?

In information gathering every piece of information is valuable but how come we usually don't consider URL the key information for predicting. I never read any chapter (from any book) on the knowledge from URLs

share|improve this question
    
WAHH specifically talks about analyzing URLs when mapping out an application in chapter 4. Granted all the information could be faked; e.g., its trivial to create a python based site that has URLs ending in 'php', though there's no good reason to do so. –  dr jimbob May 30 '12 at 16:11
    
@drjimbob: Diversion is a motive in faking python as php I guess. That itself is a pretty good reason to do so. –  claws May 30 '12 at 17:44

5 Answers 5

up vote 5 down vote accepted

There are many books that talk about using this type of info gathering and vulnerability testing, but it is under the heading of 'HTTP Headers'. Because web servers are usually configured to 'prettify' URLs, much of the info you list is usually contained in the header of the http request.

For the specifics of your question:

  • cgi-bin means they use cgi scripts
  • bv60.dll means they are likely using Windows as the server
  • BV_EngineID is an internal variable and not helpful unless you can track that variable to a certain known application

But, all of this information can be 'faked' by the server, and all this info and more can be discovered using web server scanners and passive analyzers.

So, it is important to use URLs for info gathering, but anything found needs to be verified, and there are better ways to discover the relevant information.

share|improve this answer

There is an awful lot you can learn, and in fact most penetration teams have this as part of their methodology at the initial fingerprinting phase of an attack. Spotting a .asp or a .php obviously help you focus the activities you will use to identify vulnerabilities. Usually this is combined with looking for specific files which can pinpoint the exact version or build.

A good start is to work with a list of common languages/frameworks and look at what extensions and common/default files they use.

Remember, though, that these are all spoofable - admittedly most developers leave them as they are, but you could replace them with pretty much anything you wanted, as the browser doesn't absolutely need them.

share|improve this answer

Since most public websites use server-side rewrites to accomplish "pretty URLs" these days, getting that kind of info can be tricky from just the URLs.

Of course, there are common URL patterns that can be matched against known applications and/or platforms, but there are many more bits of info that can be obtained from HTTP headers, cookies, JavaScript files and even HTML comments and meta tags.

There are free tools that do a fairly decent job on outlining the technology stack behind websites using a combination of those factors, such as BuiltWith for example.

share|improve this answer

Checking out what directories the admins dont want bots crawling by reading the robots.txt file sometimes reveals some pretty juicy information also.

share|improve this answer

However more an more websites are using .htaccess to rewrite the long ugly URL to nice short pretty ones. This will stop you from guessing the technology.

For example

/showthread.php?tid=51115

Could be

thread/51115

share|improve this answer
1  
I have a perl script behind ......./avatar.jpg –  jippie May 30 '12 at 21:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.