How to generate malicious input at processing stage?

Question

I am developing an application and It needs to be highly secured. Because of that reason, I am researching more security vulnerabilities and I found the below paragraph. This is related to input validation and I have already implemented client-side and server-side validation. But this paragraph says while processing data, it is possible to generate malicious input.

A skilled attacker may be able to manipulate the application to cause malicious input to be generated at a key stage of the processing, attacking the component that receives this data. It would be extremely difficult to implement a validation mechanism at the external boundary to foresee all the possible results of processing each piece of user input.

Please explain how it is possible? Once we validated correctly, how to generate malicious input?

The book you got this from seems to explain it nicely. It is the sentence just before what you quoted... And it even says the same thing as the answer you accepted in the previous bulletpoint. — schroeder, Jul 24 '21 at 18:21

score 1 · Answer 1 · answered Jul 24 '21 at 16:30

1

Any Client is under full control of the user. Just because you designed the client to only send certain forms of data doesn't prevent a knowledgeable user from modifying or injecting other unexpected data.

answered Jul 24 '21 at 16:30

user10216038

7,552
2
16
19

But I have already added client side validation and server side validation. Although Client bypass client side validation, he will not able to bypass server side validation. If we assume that server side validation is correctly working, how he generate malicious input during processing? – Infra Jul 24 '21 at 16:50
@Infra - *"If we assume that client side validation is correctly working ..."* That is the issue, it's an invalid assumption! – user10216038 Jul 24 '21 at 16:53
@Infra - I see you edited your comment changing **client** to **server** in your *assumption* statement. It's now a logical non-sequitur with the ending of "*how he generate malicious input ...*". – user10216038 Jul 24 '21 at 17:01
Very sorry, I have edited it. "If we assume that **SERVER** side validation is correctly working" – Infra Jul 24 '21 at 17:01
@infra while this answer is true, I'm not sure how it applies to what you asked about the processing stage. Is this answer what you truly needed to know? This is a case of "if this is the right answer, then the question doesn't make sense." – schroeder Jul 24 '21 at 18:25

score 0 · Answer 2 · answered Jul 24 '21 at 14:06

This is a generally unanswerable question, as it would require understanding your entire application and detecting every bug in your application to answer it.

What this is saying is that simple syntactic validation of user input may miss data that is semantically invalid. It may be possible for an attacker to generate inputs that are valid on the surface, but triggers bugs in the processing of that input that cause subsequent stages of the program to fail.

One mitigation for this would be for each stage of the program to separately validate its inputs, even though previous stages validated their own inputs.

Really this is just a different way of saying that you have an uncountable number of unknown bugs in every program.

if you can add, some example, it would be more helpful – Infra Jul 24 '21 at 14:33 — Infra, Jul 24 '21 at 14:33

score 0 · Answer 3 · answered Jul 24 '21 at 23:24

I think the book may be referring to something like this:

Suppose you have a web application handling the url /login?user=alice&password=hunter1 with code such as:

database->query("SELECT user FROM usertable WHERE username='" + user + "' AND password='"+ password + "'")

which has a trivial SQLi vulnerability (in addition of passing credentials in the url and storing passwords in plaintext!).

An approach to secure the application just at the external boundary would so something like forbidding the ' character in the requested url, sometimes in a firewall or htaccess, in order to avoid the injection. Which can be bypassed by simply using %27 in the url, and let the receiving program decode that into the '.

The moral of the story is that the module building that SQL query should be handling the parameters properly (by calling a database-specific escape function or using prepared statements), as it is the one with the specific knowledge that user and password are variables and not part of the query. HTTP level is the wrong place to solve that problem which is actually in the login module.

As a corollary, you should take security into account on every step, it's not "something you add at the end of creating the product" or that can be solved by "installing a WAF in front of the system". A WAF might dwarf some attacks, and it can be valuable as an additional measure to raise the stakes, but it doesn't have the application-specific knowledge of how every parameter should behave (you can see the opposite as well, when a WAF blocks a perfectly safe POST because it contained SQL code -such as a developer documenting some queries in a wiki- which would have been processed safely, but wasn't known by the filter).

The book is talking about multiple inputs, validated successfully individually, but when combined and processed together, creates malicious input. It's a 2nd order malicious input scenario. — schroeder, Jul 25 '21 at 10:05

How to generate malicious input at processing stage?

3 Answers3