PENTest: How Vulnerable are query string parameters and their values?

How Vulnerable are query string parameters and their values?

I am curious how vulnerable a website is to hacking that has little validation on the query string params.

Some argue that:
1) an unrecognized query string parameter can do no harm
2) it's too much work, since the program is always in flux, so the "poor stepchild" would not keep up
3) the code to block this (locally at least) is fragile and will always delay a solid release
4) there will be many more failed log-ins than blocked hackers

What are your thoughts on this topic?

And how does using a Web Application Firewall change the discussion?

It seems that if the benefits to security were small or non-existent, the Security Industry would not waste its time closing this vulnerability.
newbiewebSr. Software EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Kyle AbrahamsSenior .Net DeveloperCommented:
It depends on what kind of query string you're talking about.

If you're just talking about looking at products, then you're fine.  EG:  ?ProductId=53

If you're talking about users and permissions, well then that's just scary:
(1=admin, 2=me)
?UserId=2

hrmmm, change it to 1 and viola, now I have full access to your application.


In general I treat anything that expose via query string as untrusted, unless it's encrypted or a GUID (EG: microsoft style unique key).  Even then with the guid I usually put some kind of expiration date on it (this guid is valid for the next 1 hour, after that treat it like a non-existant guid).

IMHO the query string was web's 1.0 way of dealing with state before session was introduced.  Now adays anything you put in the session could be written to the database or in session and have the same effect.  EG: there are much better ways of doing the same thing, but that's just my 2 cents.
1
masnrockCommented:
It's all in how the application is written and how parameters are treated. Kyle brings up a lot of great points. But for things that one could potentially input in a string, I would encourage you to test out scenarios that aren't expected... building on the item number example, what if someone used a number that was outside of the integer range? Or a non existent item number? Maybe a negative number? Bunch of letters? For exposed items, you definitely need to be sure to do bounds and input checking. But i will once again point back to the fact that Kyle's post addresses a lot of stuff.

If security were taken into account in the first place, then a lot of issues get avoided. Hence comments like you cannot bolt on security. But to answer your question more directly, the more you leave open like that, the more potentially vulnerable the application.
1
Shalom CarmelCTOCommented:
Please take a look at the OWASP top 10 web app security risks.
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

The top risk is called an injection. The context of this risk is an value external value that is used in SQL queries, or LDAP queries, or NoSQL commands, or bash scripts, or Powershell scripts etc.
Guess what is the main vector of getting external values into your web application? You guessed right. Query strings.

What about unrecognized query string parameter?
For a long time in PHP you could send global variables via the query string, even when they were unexpected.
There was an explosion of frameworks in all kinds of languages in recent years, and I can guarantee you that some will happily accept your query string and let you override internal variable.

The good thing is that while the application query parameter names vary from one programmer to another, framework specific variables are common across the framework.
SQL injection values are similar across SQL.
LDAP queries have a syntax that is common and recognizable.
That is a major part of how Web Application Firewalls work. They know patterns of attacks, and are configured to block them or alert on them. So if a dumbass programmer does not sanitize the input and uses it as-is to construct an SQL statement, at least the WAF will block the obvious attacks.
1
Defend Against the Q2 Top Security Threats

Were you aware that overall malware worldwide was down a surprising 42% from Q1'18? Every quarter, the WatchGuard Threat Lab releases an Internet Security Report that analyzes the top threat trends impacting companies worldwide. Learn more by viewing our on-demand webinar today!

ste5anSenior DeveloperCommented:
1) an unrecognized query string parameter can do no harm
As URL's are processed on many levels, this can lead to problems on any of those levels. Therefore query parameters must be at least well-formed.

2) it's too much work, since the program is always in flux, so the "poor stepchild" would not keep up
Then the developers are too lazy.

3) the code to block this (locally at least) is fragile and will always delay a solid release
Then the administrators are too lazy.

4) there will be many more failed log-ins than blocked hackers
???
1
nociSoftware EngineerCommented:
Allway expect the data to be invalid & wrong. And first prove that input data is valid accordinging to Form, Type etc.
This can be done according to rules like:
character string is valid, only if it doesn't contain ' & ",
number are valid if they only contain digits  ( possibly intersperced with group characters).
floats are valid if:    sign digits [ digital-sign digits].
   possibly allow exponential notation: sign digits [decimal-sign digits ] ['E' sign digits ]
digits one or more of the character '0' .. '9' inclusive.
Sign  = +, - or absent
A grouping character is dot or comma depending on locale
A decimal-sign is comma or dot depending on locale

After that contents of valid form & type needs to be matched for meaning.  
Is a productID existing?  is the user-id a valid userid, was that authenticated if rights are derived from it....

If that is OK then your other software can take care of this data.
Rules like the above can be handled by WAF.
1
masnrockCommented:
I forgot to address these individually, with some my snark:

1) an unrecognized query string parameter can do no harm
Someone will always figure this out, and figure out how to abuse it. After all, the developers know how the string parameters work, right? (At least I *hope* they do)

2) it's too much work, since the program is always in flux, so the "poor stepchild" would not keep up
Remember my earlier comment about building in security, rather than trying to bolt it on? But since they don't want to do their work upfront, that means more work for them later as well as more work for security professionals. $$$$

3) the code to block this (locally at least) is fragile and will always delay a solid release
If said release were solid, then there wouldn't be any security issues, now would there? For as long as attacks like buffer overflows have existed, you'd figure that they would be almost gone at this point. But no, the same issues continue. In addition, see my response to #2. Another factor in this is businesses pushing products out of the door too quickly, so quality usually suffers (security is a corner that usually gets cut, but functionality suffers quite a bit too). And funny enough, I remembered a discussion I had with a major vendor of hotel software regarding their lack of input validation, and pointed out some of the issues that leaves their software open to.

4) there will be many more failed log-ins than blocked hackers
Do they have empirical proof? And how are they able to separate those who just logged in incorrectly from those who are trying to force their way in. A good number of external incorrect logins are probably from hackers. If any of the people making this argument got their applications hacked, what did they have to say at that point?

What are your thoughts on this topic?
That those who came up with those 4 arguments will be a noticable reason that security people will continue to have job security.

It seems that if the benefits to security were small or non-existent, the Security Industry would not waste its time closing this vulnerability.
Things get exploited all the time. Some developers care enough to actually try to address these, while a number of others don't. The impacts can potentially be huge, and the costs could be large to someone.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Kyle AbrahamsSenior .Net DeveloperCommented:
Some developers care enough to actually try to address these, while a number of others don't. The impacts can potentially be huge, and the costs could be large to someone.

I would also argue that a ignorance plays a huge factor with security.   I would say a majority of programmers are focused on just making the program work instead of making it work while protecting against malicious users.  Also sometimes you don't know what you're not aware of until it's too late.
0
masnrockCommented:
@Kyle - I'll give you that. But I would also argue that security tends not to be a part of the development process to begin with, which plays a role in keeping developers ignorant (sort of a catch 22). And especially in these times where software flaws with serious ramifications keep getting found, I'd say that it reduces the reasons for security not to be built into the process. (And to be fair, many companies will tend to be cheap on this one and expect their existing people to just "figure it out")
0
newbiewebSr. Software EngineerAuthor Commented:
thanks
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Vulnerabilities

From novice to tech pro — start learning today.