Parameter Enumeration: Security Basics

What is parameter enumeration? How can you mitigate against it?

This is part two of my “security basics” series. Part one covered SQL injection.

This post is a text-based companion to this hands-on exercise hosted on Killercoda. Both have similar content. If you prefer to read, stay here and read on. If you prefer hands-on. Read this for background, and then head over there.

What is parameter enumeration?

Parameter enumeration is a type of web parameter tampering attack.

This blog post will serve as a “getting started” or “101” guide for a basic type of attack on a vulnerable system.

You'll learn what a parameter enumeration attack is, how to perform one, and some tips on defending against this type of vulnerability and related attacks.

Scenario

Imagine you're subscribed to an email mailing list. At the bottom of every email is an unsubscribe link that takes you to a page that provides a way to unsubscribe.

You notice that the URL has a id parameter. It looks like you're id=3

When visiting that URL (eg. https://example.com/unsubscribe?id=3), you see your name, full email address, and a handy “unsubscribe” link. No dramas. That’s you, and you can happily unsubscribe.

You wonder what happens if you use id=2 instead?

Well, now — apparently, you can now see that id=2 is someone called Sue Taylor. You can also see Sue’s email address and can even unsubscribe Sue from the mailing list 🤯.

This is parameter enumeration

With a small adjustment, you can see data you're not supposed to see.

It’s not a stretch to imagine writing a script to run through every ID and retrieve (or delete) an entire mailing list.

Should you be able to do this? I doubt it.

Parameter tampering is the first part: the ability to change something (like id in a web address). You can then "cycle" (or enumerate) through the parameters (ids) to see everyone on the mailing list.

How Dangerous is This?

Web parameter tampering and parameter enumeration are basically types of broken access control, allowing you to access the information you shouldn’t be able to see. This is the OWASP’s number 1 most common vulnerability. So, very common and obviously very critical to business protection.

Imagine if my example was real. I would already have by now your entire mailing list, or I could have already deleted it.

How can I protect against this?

Generally, never give the user an option to “cycle” through things. If you do, at least make the IDs random (or none sequential), so they're harder to guess. For example, use IDs like aFG4X!@da, mMb5432!!--3 and xP-+4886bVf~instead of 1, 2 and 3. Those IDs are much harder to guess and almost impossible to automatically "cycle through."

Use combinations of things. For example, a unique “additional parameter” for each ID. For example, id=1 can only access their account when they also use this in the URL: secret=!A-fgd_nkf--+sjh^sAAB . Even if you use ?id=2&secret=!A-fgd_nkf--+sjh^sAAB it wouldn't work - because user ID 2 has a different secret value assigned to them.

More reading

The OpenSSF Guides and OWASP Top 10 are fantastic places to expand your knowledge.

Parameter Enumeration: Security Basics was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.