-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minor improvements #1418
Minor improvements #1418
Conversation
…ectly after jadx-gui start
@jpstotz looks good to me, but CodeQL found possible log injections and suggesting filtering input to allow only alphanumeric characters to pass:
Or maybe we can just concat raw strings without using logger args pattern ( |
@skylot Sorry but I am still not sure how to react on this CodeQL error. Especially as the CodeQL error is not on testing that the input is non-ASCII but on replacing new lines for avoiding forged log lines. First I thought of an early Aprils fool because using log injection as an "attack" seems to me not like something an attacker would ever consider. Especially as in my opinion it is the dedicated purpose of a log system to record received data in a way the developer can see the actual unmodified data. Even considering that log files could be processed by an automatic system later and based on certain log entries trigger actions (a scenario not really relevant for jadx but let's just consider it). In such a case in my opinion it is the job of the logging system to save the data in a way that makes injections impossible (e.g. save the data not in plain text files but in JSON, XML or directly in a database). So the only risk I see is a potential DOS attack by injecting large data into the log file consuming storage space. Checking the linked OWASP page mentions possible attacks:
In my opinion 2. and 3. are outside of an web application not really relevant and anyway it would be a vulnerability of the log viewer application (log files are user defined arbitrary and potential insecure data by definition). So it comes back to 1. injection of log messages an possible "attack" in deed but so useless that it is not relevant in my opinion besides for script kiddies who what to say "helle I was here". |
@jpstotz well, I agree that this vulnerability is not really related to jadx-gui, but due to the latest issues with log4j, I want to correctly handle such warnings. Mostly to get used to correct code practices and prevent possible issues in other parts of jadx. For example, in jadx-core such issues should be handled very carefully because it can be used as library in any kind of software. So I will add simple log escape utility method in |
@skylot OK, the LogUtils seem to be a good approach but please don't use |
Looks like CodeQL not too smart. After applying suggested fix, it is still throwing warnings 😢 |
A bunch of minor improvements to: