I m in a project which my co-workers want to use log4cpp, log4php or log4j for flow control, ie: they want to log things, parse it and then flow control based on that information.
I told them that log4X should only be used to log, report errors and run time information.
How can I convince them not to use log4cpp or log4php or any log4x for flow control?
or do you think there is nothing wrong with this?
Sounds like a classic case of using the wrong tool for the job. There are many ways to do flow control and even whole servers for that purpose. Mule, IBM Message Broker to name a couple. As you say, LogX is for logging. The concept of trying to base the flow of messages, execution or whatever on the parsed output of a logger is so far wrong I cannot even begin to figure out why anyone would suggest such as bad idea, never mind adopt it. And there are so many ways to screw it up too. Never mind the fact of how do they intend to do real logging if their logging framework is not being used for it.
It never ceases to amaze me how often people in IT manage to make such decisions.
Related
I'd like to find redundant blocks of code in my service. Is there a way to check when that last time this code was used runtime? The service is running on GCP.
I don't think there's a great solution to your problem but you could instrument, perhaps via Aspect-Oriented Programming (AOP), selected places in your code with simple logging statements and then monitor those.
You should avoid including any "hot code" which is executed very frequently because you can slow down your service and produce an overwhelming amount of logs (harder to manage and costly).
There's a lot of way to do this, but personally, I would use logging into this function and then let this app running normally. Then, you'll just have to check you log files and check for your logging message occurrences.
However, I'm not sure if it is possible to get this information without any action of your part to see previous usages of your code block.
I'm so worried about people logging confidential information to server logs.
I have seen server logs in production. Some developers are accidentally logging security related
information like password, clientId, clientSecret etc.
Is there any way, like Eclipse plugin or any tool, to warn developers while writing their code?
`ex : log.info("usernam = " + username + "password = " + password) ;` //
Warn that confidential info is getting logged.
I have done some research... I have seen tools like sonarLint and FindBug
but those plugins are unable to solve my problem.
SonarLint offers the rule S2068: Credentials should not be hard-coded, which targets the use of hard-coded credentials, and it seems close to what you are trying to achieve, though it may be not enough for your needs.
As stated in other answers, however, identifying such security holes can be ultimately hard and strong code reviews is certainly a good move to reduce the risks.
Now, if you really fear about usages of loggers, already knows potential issues, and what data could leak, I would suggest to write your own Java Custom Rule for SonarQube.
Custom rules are supported by SonarLint and can be applied at enterprise level once the Custom Plugin containing it is deployed on a SonarQube server. This solution would allow you to explicitly define what you want to target, and fine-tune a rule depending on your needs and enterprise specifics. Writing such rules is not hard and documented in the following tutorial: Custom rules for Java.
There are many different ways how security holes can appear. Logging data to the browser console is only one of them.
And to my knowledge, there is no tool that can detect those security issues automatically. It is the responsibility of the programmer to not expose private user information on a page.
In this case the advice is: Never log passwords (especially unencrypted ones) to the browser console! Instead, encrypt your passwords in the database with an algorithm that can't be decrypted.
Another approach is to create a custom log appender that looks for certain tell-tale patterns (e.g. works like "password" and "passwd") and obliterates the messages, or throws an error.
However, this could be dangerous. If the bad guys knew you were doing this, they might try to exploit it to cover their tracks or even crash your server.
I wouldn't hold my breath for some out-of-the-box solution on this one. Beyond your own logging, you also have to be concerned about the logging done by your dependencies. That said, you have two areas to work on: what goes into the logs and who has access to the logs.
As far as what goes into the logs, your best tools to combat this problem are education and collaboration (including the aforementioned code reviews). Start with writing a list of non-functional requirements for logging that includes security that addresses what to log and how to log (markers, levels, sensitive parameters, etc). I recommend working with colleagues on defining this list so it doesn't become known as "Ravi's logging crusade" instead of "something we really need to do".
Once that list is defined and you get your colleague's and/or management's buy-in, you can write wrappers for logging implementations that support the list of non-functional logging requirements that you assembled. If it is really necessary to log sensitive parameters, provide a way for the parameters to be asymmetrically encrypted for later retrieval by a root account: such as the encryption key stored in a file only accessible by root/container. For management, you might have to spend some time writing up value propositions describing why your initiative is valuable to your company.
Next work with whoever defines your SLDC - make sure the change to your SDLC is outwardly communicated. Have them create a Secure Coding checklist for your company to implement with 1 item on it that says: All logging is implemented using OurCompanySecureLogger. Now you can start working on enforcing the initiative. I recommend writing a check on the build server that looks at dependencies and fails the build if it finds a direct reference to log4j, slf4j, logback, etc.
Regarding the other half of the problem, work with your SysOps team to define rules of Segregation of Duties. That is, software engineers shouldn't have access to the servers where logging is being performed. If you're not staffed well enough at this point to support this notion, you might have to get creative.
May be you should try Contrast tool. Its good one and we are using it since long.
It takes care of all updated owasp top 10 issues.
Quite good for finding security holes in enterprise applications.
Their support is also good.
I am having a fairly large legacy (swing) application and currently brainstorming and evaluating the strategies to add logging in it.
Key point is that it's fairly large (like I said above) and thinking what could be the strategy to do it quickly and completely (100% coverage for argument sake) (let's say logging is no customer facing core business functionality, so let's say not getting paid for it)
So the two strategies as such are -
Do use log4j2 add the debug statements, add appenders, file rolling rules, add dynamic on/off and change of log levels etc and thus do it the way it ideally should be done.
Use AOP to define endpoints and advices declaratively/programmaticly. Device such elaborate rules, add in the rest of the part (appenders, rolling rules etc.) and thus wont be touching each and every file and adding a revision just for that.
The second strategy is what I want to explore if someone has experience with, if somebody has gone that route.
The cons I can think of -
No standard / convention in apps, would be 99% impossible to define endpoints completely
Sphagetti and unmaintainable code in AOP module above, largely a result of the above problem
Adding same and matching set to logging to future classes.
Can you guys suggest me wither ways
While I am a big proponent of refactoring and clean code, I suggest you use AspectJ to add logging and see how far you get. Probably you will be surprised by how much logging you get with a little aspect.
IMHO logging is a cross-cutting concern and not core functionality. I would try to avoid logging in my core code. My expecience with AspectJ is only positive, I warmly recommend it. You should take some time to get acquainted with its power, though.
If you need something like a call trace (maybe neatly indented) or just plain method call logging with parameters and maybe return values, you will get quick results with AspectJ without cluttering your application code. The aspect can always be improved and maintained in a single spot, which is very clean. No need to be afraid of spaghetti aspect code. It will not happen if you don't totally abuse AspectJ.
You will only run into problems if your core code is already spaghetti code and you have very long methods which need log statements inside those methods and not around them. Then you might need to refactor and break down monster methods into smaller ones. But that is a problem no matter which logging approach you choose. My own experience with ugly legacy code and AspectJ-based logging tells me that it helps a lot because even spaghetti code calls other methods and that can be nicely traced in AspectJ.
I have a problem which is hard to explain so lets get started:
Context: I have a application running on a tomcat server Lets call it "admin". The admin have an import/export function. Our own application is an extension to that and we need to gather some information when the "admin apps" use the import/export function.
Problem: The third party jar that contain the class ImportController is located there: ~/someFolder/admin/WEB-INF/lib/admin.jar. The goal is to gather the Old project ID and the new Project ID so that our extension can link our class to the right project. Since i know the method signature i though i could use AOP to do so.
Idea: The idea i came with is to put something like idHiJacker.jar that would contain a single pointcut and advice into the ~/someFolder/admin/WEB-INF/lib/ and enable load-time weaving. That advice would simply put the information into an xml file so our extension would be able to read it when we want to put the link back after a project import.
Also i must say I'm a pure newbie with AOP and web stuff. But i do not wish to import a monster for just doing this small operation with AOP. At the moment im reading on aspectJ and AspectWerkz
Question:
1) Am I in the right direction? Do you see anything that would make this idea not work at all?
2) If this is possible what would be the good practice to do it in a very clean manner?
3) Should i do it with AspectJ? AspectWerkz? Or Something else?
4) Am i doing this for nothing? Is there an easier way to do that operation?
Edit: Also if you have good tutorial to link with answer, it would be awesome
Thanks for your time and answer
Question:
1) Am I in the right direction? Do you see anything that would make this idea not work at all?
I can't see any reason why this will not work. Aspect Oriented Programming and cross-cutting concerns apart, the notion of advice is to execute some before or after some other pointcut and often to influence the behavior of that advised function. You are doing exactly that here.
2) If this is possible what would be the good practice to do it in a very clean manner?
There is some inherent chaos with aspects/advices -- since the control flow is hijacked more then a simple sequential reading of code is needed to understand whats going on.
3) Should i do it with AspectJ? AspectWerkz? Or Something else?
I have never used AspectWerkz but I have very good experience with AspectJ; especially in terms of the support here on stackoverflow and perhaps even more on its mailing list.
4) Am i doing this for nothing? Is there an easier way to do that operation?
Unless you can change the code of import controller or change the clients to make extra calls to do the linking thing this interception based approach seems best IMHO.
I have suggestion for a simpler solution - use a decorator pattern to wrap around the third party ImportController, put your functionality before the third party library is called. You should be able to do this since you seem to have access to the admin application.
This is essentially doing what AOP is doing, but using code. Your approach using load time weaver should also work, but is in my opinion complicated - if you absolutely plan to go this way, do use AspectJ.
i am currently working on a java application for some network monitoring tool. In my code i am supposed to use logging a lot. Since its a network management software, the information in logs is quite useful to the user hence its compulsory to use them. But now I am bit confused with what kind of logger method i should prefer. Right now i am using Logger.lop(...//...) since with its help we are also logging the class name and method so its becoming very easy for me (developers) to debug the code and find the error. But finally I am confused should i deliver it to the end user with the same logging mechanism??? Is it any harm to let your user know what kind of class is executing currently , in which method error has occured. I have seen many times in many product in exception handling stacktrace is used so normally we get class name as well. So is there is no problem to let enduser know what your class name and method is??
Before considering the security implications of it, consider the performance. In most logging systems, getting the actual classname and method name dynamically by the logging facility requires reflection and dramatically slows down the logging - usually a synchronous operation. My guess is that in a network monitoring application, you really don't want that.
If you're hard-coding the method name into the log message (either by making it part of the message or by the category), that's a different story. As a security person, I don't consider it to be that big of a deal - if your code is in Java, it can be reversed anyhow, so your code should operate in such a way that it would be secure even if the code was given away.
All that being said, you could either use a different logging configuration for development and production, or those fine-grained messages could go in debug, trace, etc. If you're using log4j, it's generally advisable to use isDebugEnabled to wrap any logging statements which include anything dynamically-calculated as those get calculated before the logging statement determines whether it's enabled.
log4j/logback/slf4j allow you to have different formats for different appenders. For development you can enable a console appender where you include the class name in the format, while for the end-users you can omit it (for a file appender)
It's worth mentioning that such logging is performance costly in Java, contrary to C++ where it is usually implemented with preprocessor. Fortunately, with log4j/logback you can switch it on and off — follow Bozho's advice.