Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The book Web Hacking Exposed has a number of instances where the attacker would essentially use patterns in naming conventions to design attacks.

Can any one point me to any study on security/privacy exploits based on "naming conventions" ... such as file name, identifier names (may be in javascript), url parameters etc.? Would you say, in general such vulnerabilities (read exploits) are limited to web applications?

share|improve this question
I still can't understand what do you mean. Could you rephrase question or add some information? – anonymous Apr 7 '11 at 21:02
Did my answer suffice? I think it took into account the information you mentioned from the book. – atdre Apr 8 '11 at 6:16
it's better off not to include shortener links (e.g., especially on a security site - users here are sensitive to that, and usually prefer seeing where they are clicking. Fixed the link for now. – AviD Apr 8 '11 at 8:46
@AviD ... of course, should have thought about that. Thanks for fixing it. – Tathagata Apr 8 '11 at 13:27
@atdre Your answer covers much more ground than my question, and is definitely gives a direction for further exploration. Thanks a lot ... :) – Tathagata Apr 8 '11 at 13:31
up vote 6 down vote accepted

Hostnames reveal interesting information, such as potential code sinks (e.g. would be LDAPi versus, which would be SQLi). These can be extracted with the host-extract.rb tool.

Parameters reveal the same type of information, and may even speak words about the type of query. For example, I often see ASC or DESC listed as parameter names (especially on sort buttons in web apps), which would indicate an ORDER BY or GROUP BY injection type. Sometimes the parameter names are sortby, groupby, or perhaps sortorder or simply "order" or "group". These are very telling.

Additionally, some are called "limit" or "offset" which indicates the LIMIT or OFFSET part of a SQL query. A web application assessor usually assumes he or she is injecting into the WHERE clause, but it really could be in these other places.

Some parameter names give other hints, such as whether they are an integer or string.

Often, SQLi exploitation tools, such as sqlmap, Marathon, and bsqlbf-v2 will allow you to configure the attack query more specifically, and yes, knowledge of the current parameter keys and values certainly helps when testing them, especially during blind SQLi testing!

File names (via a path disclosure) are even more obvious. They can be used to discern whether or not a popular open-source (or potentially closed-source if you read a lot of code!) package or component is installed on a web server. You can usually get down to the specific version. InspathX and WhatWeb utilize these techniques -- inspathx to identify path disclosure vulnerabilities and WhatWeb, well let's just say that WhatWeb can do a lot!

Since about half of the tools that I mentioned in this answer cite tools made by current members of the YGN Ethical Hacking Group, you should check out their Research area and Lab (accessible from their main webpage).

The authors of "Hacking Exposed Web Applications, 2nd Edition" (Note that the third edition is out, where additional up-to-date information is available) are referring mostly to custom directory/file brute-forcing lists, as well as Direct Object References (i.e. OWASP T10 Forced Browsing, OWASP T10 Failure to Restrict URL Access, OWASP Insecure Direct Object References, or WASC TC Predictable Resource Location).

In other words, if you see something like http://owaspbwa/external/ you could also check for the existence of http://owaspbwa/internal/ or similar.

share|improve this answer
This is a good resource for further identification of naming conventions -- – atdre Apr 10 '11 at 8:05

Another aspect that may be vulnerable (or enable other attacks) is naming conventions for usernames.
I.e. it makes User Harvesting possible, targeted attacks are easier, and if you're going for Account Lockout DoS it certainly is easier to either find your target user, or generate whole lists of users.
On the other hand, I've also seen the opposite - a naming convention that reveals a user's private information. For instance, using some form of personal identifier (think SSN, or payroll number) as part of the username. Now, whenever anyone sees the username (and in many orgs, the email address is based on the username), that detail is revealed.

share|improve this answer
Exactly these are of my concerns ... Do you know if some body has done any kinda study on such such things? My initial idea was to have some publicly available dataset and use some regular expressions for extracting SSN, IBAN, address telephone number etc. etc. ... but my search for some appropriate dataset didn't really end up anywhere – Tathagata Apr 8 '11 at 13:50
@Tathagata ah no, sorry. But I would suggest also looking at (corporate) email addresses, if you have a large enough database... Not 100%, but there will be some correlation. – AviD Apr 8 '11 at 14:06

If you're discussing path traversal by exploits there are many resources online. The most common case of path traversal is within SQL injection (i.e. if you're running Apache, I can guess where your personal documents are based on the standard convention of the linux/unix operating system).

More information can be found at these sites (this is the tip of the ice-berg of sources):

If you're looking at attacks being generated according to a naming scheme of, for instance, a host-name, that would be a very specific application (application as in apply the logic, not an executable) and would depend on the organization that is being targeted.

On the other hand, if you're talking about naming conventions pertaining to the actual file names of malicious application, that is an interesting concept. I'm not sure if that method of malware detection is really a possibility. This isn't because of a lack of technical know-how, it's more because malware inherently is meant to keep obscure. If the malware is actually named "hacked.exe" then I would be very surprised. Even if this was the case, the signature based detection methods that most anti-virus/anti-malware applications employ now should still apply. So it's equivalent to targeting squares when you really want to catch all rectangles.

I do not know what exactly you are looking for, so this is a difficult question to answer. Please expand on your question if you would like more information.

share|improve this answer
I edited my question so that it makes more sense ... my question is not towards malware detection, but more towards detection of vulnerability in applications due to naming idiosyncrasy ... – Tathagata Apr 8 '11 at 3:06

Tricky to understand your question, but I think Ormis has the key issue around knowing where items are.

The only other aspect I see reasonably often is around making life easy for attackers by naming finance servers as "finance001" etc...

Best not, eh:-)

Use a naming convention, sure, but one that adheres to a system which doesn't shout "Hey, over here - lovely target!" - an element of security by obscurity (but only as a layer which helps, not to be relied upon)

share|improve this answer
RATED: Super FUNNY ... – Tathagata Apr 8 '11 at 3:09
@tathagata - amusing, but sadly true. I see this so often and it does instantly focus the attackers mind:-) – Rory Alsop Apr 8 '11 at 7:01

I found this resource online. I hope this helps!

share|improve this answer
Thanks for the link. However, StackExchange answers should include actual relevant data instead of just references to other sites. – Iszi Apr 7 '11 at 19:45

Your Answer


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.