Programming & Security Vulnerabilities & Logging

It's not always easy to be a programmer! - Ask any coder what one of the most annoying things is to do and it is "debugging".  Trying to figure out why the nice, beautiful code you just wrote, does not do exactly what you expected it to do!

One of the main difficulties in writing software is the inability to imagine all of the possibilities a user might intend to use it for, which often is far greater then what the programmer had intended.

To do this we need to use our imagination to think questions like "what happens if a user types "X"?' or what should happen when the user enters letters in a number only field?. What if the user hits both the return key and the escape key at the same time? Often even the user doesn't even know why they 'did' it the way they did it..from their point of view that just seemed the 'obvious' thing to do !

In programming tech-talk we call this "Defensive Programming" and while the reality is we can never be 100% sure what the user will try with our software, in order to ensure the best possible user experience, we need to try and predict these unusual situations and provide an appropriate response.  Machines don't have behaviors on their own, it is only what the programmers put into it.

When a user  tells us something is 'wrong', it can also be difficult for them to communicate the specific steps they followed that caused their error. Often they cannot easily think of all the steps they did to cause the problem, and it is those specific steps (and our ability to re-produce them) that are vital to finding and correcting it in the future.

This is where log files become extremely invaluable.  By writing out to the log file what was happening just before the error, we can troubleshoot the exact steps that led up to the problem. Eg:

    9:25am - User Logged into the Application

    9:28am - User created a new Contact

    9:30am - User entered Contact Phone Number with text "see fathers phone number"

    9:31am - Exception in thread "main" class org.geekwisdom.PhoneNumber cannot be cast to class  java.lang.String

When we see the error we can recognize. Ah Ha! - the user didn't type in an actual phone number, they typed "see fathers phone number", and because there was nothing to 'catch' this problem, the software crashed.

Typically we can set the 'verbosity' of the log file, so that if we cannot determine why it crashed, we can increase how much is written to the file so that the next time we can get a bit closer to what went wrong.

Often times these logs are created using existing logging frameworks within the language. Log4j is an example of a logging framework used by countless java applications to make it easier for programmers to write details to a log file.  A simple way a programmer might write a log file such as above might be something like the simple statement:

 log.debug("User entered Contact Phone number with text" + PhoneNumber.getText());

But what happens when our logging framework fails?

Just like any other bit of programming, the people who maintain the framework make assumptions / educated guesses on how the users will use it.. and sometimes they simply don't (can't) think of everything.

One of the things that often gets drilled into us as young programmers is to always sanitize the user input before using it.  This is to ensure that the input is not trying to do anything 'nefarious' things and gain access to data they should not have access too.

A common example is known as "SQL Injection" suppose you have a login and password screen, and your code checks that password with something like this

"SELECT * FROM UserTable WHERE username=" + username + " and password = " + password;

where 'username' and 'password' were the username and password typed by the user.

But if the user types something like " ' OR 1=1' instead of the user password. This can be problematic ie:

SELECT * FROM UserName WHERE username="brad" and password='' OR 1=1" will always return true (because 1 = 1) even if the password isn't filled in.

So we should "know" better from making this kind of mistake right?

But surely writing our own log files is safe? right?.

Consider the example above:

 log.debug("User entered Contact Phone number with text" + PhoneNumber.getText());

Simple enough right? - It lets us know in our log file what the user typed so we can figure out what went wrong.

Except suppose for phone number the user instead types something like:

Now the logging system downloads the 'reverse_bash_server.class' executes it and allows user to remotely log into your system and gain access to all of your data!

And this is why today there are potentially hundreds? thousands? of machines out there capable of being exploited because who would have every imagined a need to sanitize the input that is output to a log file?

But at the end of the day, we never know what the user will try to do, and we need to constantly 'defend' against it.

You can read more about the log4j problem @ https://logging.apache.org/log4j/2.x/security.html

If you were imaginative enough to think to sanitize your input from users type in text in  the format ${} before writing it to a lot file then you are one of the lucky ones already safe and sound, (and you are not using any other 3rd parties that weren't as 'smart' as you)

Another good article to teach you about "lookups" and 'jndi" see: https://blog.sebastian-daschner.com/entries/log4shell-and-how-to-fix

GeekWisdom  Java Tools -> https://github.com/geekwisdom/gwJavaTools has been updated to use log4j 2.16 so as to be patched against this vulnerability.

Edit: Fixed error of 'AND 1=1' to 'OR 1 = 1'