Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am looking to gather some professional advises and precautions to do Secure Coding using Java. Couple of them I am already considering:
Should not log unwanted/excessive/sensitive information.
SQL injection should be taken care in parameterised queries, should use PreparedStatement or CallableStatement instead of Statement.
All the resources (db connections, input/output streams) should be release carefully.
Internal Exceptions should be caught and sanitized before propagating to upstream callers as it may reveal sensitive information.
Should clear the sensitive information even from memory when done as it can appear in core dump.
In case of inter-process communication, sensitive arguments should be encrypted.
Should use private for variables unless having good reason not to.
Should provide copy methods for sensitive classes.
Should prefer static factory method for object construction over public constructor.
Should avoid serialization of class that might hold sensitive information.
Appreciate any add up from the community.
Just another that comes to mind, you should use defensive copies when returning from a getter method.
If you're looking to protect your released code, you could consider something like JET although that's not quite what your question is asking I thought I'd just mention it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We have a method which we use to log java exceptions in a log file. The method allows the caller to pass variables they wish to be shown in the log message for debugging purposes and uses inserts blank lines and tabs to make the message stand out and be more readable.
However, all of the recommendations I see to prevent Log Forging attacks recommend stripping all of the CRLF's out of the logging message.
Is it considered bad practice to have CRLF's in a logging message? This method is only used internally and any user supplied information can be sanitized before being passed to the method.
generally - yes.
while this seems a nice feature at first glance, you should consider the following potential complications:
depending on exactly how this is implemented, if you hand the underlying logging framework multiple lines as multiple logging invocations your statement could get interleaved with other concurrent logging statements, making the resulting log less readable
various log-parsing tools tend to assume one line == one statement. most know how to account for exception stack traces (that are multi line) but not much beyond, so you may find yourself having to delve into things like ELK stack / loggly configs to teach it about your fancy multiline statements.
complications around terminals with different widths (if youre printing to console)
I think the real problem is that you're tightly coupling the message you output with the medium you're expecting it to be stored in (a plain-text file). I'd recommend looking into structured logging frameworks, and more powerful "Sinks" for your structured logs to go to, so you can analyze your logs without relying on message-formatting tricks.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Most of the people says that abstraction is hiding something and showing only functionality to the user. Can anyone explain me what are all the things you are hiding and what are all the things you are showing?? please don't explain with the examples of animal, engine, vehicle.
I think this is a case where a concrete example would help a lot.
HashMap has an internal structure for handling hash collisions, which is an implementation of a singly-linked list. Now, do you know how that internal structure works, what it's called, what its fields are called, etc? More importantly, do you care, so long as the HashMap "just works"?
If the answer to both of those is "no" — which is what it should be for anything other than curiosity/learning purposes — then those details have been hidden from you and exposed via the abstraction of Map's interface.
The result is a class that's easier for you to reason about (because you have less to learn), and easier for the library maintainers to maintain (because they don't need to worry about a change they make breaking your code, so long as they still abide by the interface).
Abstraction is an overloaded term.
Abstraction, in object oriented languages, basically means leaving away unnecessary details when modeling real world objects. You could also think of it as a simplifying process.
Abstraction, in computer science as a whole, also means hiding complexity by providing some sort of simpler interface. Your question seems to aim at "data abstraction" which means hiding the exact way data is represented with an abstraction layer. This could be e.g. the Number data type in databases. You just know it is a number, but not how it is stored on disk.
Abstraction sometimes is used equivalently to encapsulation, too.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm working on a class where it is supposed to access an Singleton's class methods using reflection. Are there any best practices in here or pitfalls? Thanks in advance
Well, there's the general "reflection is slow and should only be used as a last resort" best practice, but the guidelines that I follow, from simple to advanced:
Cache any Method or Field or Constructor instances you get from reflection lookups. Looking them up repeatedly is slow.
If you can, cache them globally in a WeahHashMap or similar that unloads them when the classes are unloaded so you don't leak class references from your cache
Even better, convert the Method objects to MethodHandles and then use LambdaMetaFactory to turn them into a Function<Object[],Object>, which will be almost as fast as a compiled method reference. Still cache the helper functions because creating them is expensive.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it in good practice to use an exception for a different purpose than the intended one, for the name? For example, I wanted an exception something along the lines of "Already exists" and I found the exception "EntityExistsException." The name was great, but it seems it was intended for the EntityManager. Is it okay to use the class, or should I create my own?
Read the documentation. Anyone unfamiliar with your code will look at the exception, and either know its documentation or go and read it.
In this case, the documentation says the exception is
thrown by the persistence provider when EntityManager.persist(Object)
is called
so if it is thrown in other circumstances by your code then your code isn't compatible with the Java API and has a bug.
I would tend to either use or subclass IllegalStateException for your case, since that is a general purpose exception, is widely used, and the state of 'the thing already existing' falls within its specification. If I expected that client code would handle the 'already exists' state differently than other failing states, then I would subclass it, otherwise I wouldn't.
This issue is probably best answered on a case by case basis, since "different purpose than the intended one" is a little bit vague to offer a complete suggestion on.
In your case, it may come down to a matter of taste. Personally, unless your already exists exception needs are related to the persistence layer, I would advise against reusing the exception from that package since it is easy to make a new exception and will not confuse any future developers or code that may infer the exception is being passed on from the underlying implementation.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Is it possible to add software enforced copy-on-write for multithreaded applications in Java? By this I mean threads having a reference to the same object, but when one thread attempts to modify it, the object pointed to is copied and the reference is adjusted to point to that copy.
The only implementation I know is the
java.util.concurrent.CopyOnWriteArrayList
see
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
and the related Set class
java.util.concurrent.CopyOnWriteArraySet
and finally
org.apache.mina.util.CopyOnWriteMap
but it depends from your need.
If your question is,
is it possible to enforce copy-on-write behavior across the board for an entire Java runtime
then the answer is,
No, there is no such general capability in Java.
Actually, I think the closest you can possibly get to that goal is using Clojure. All its default data structures are copy-on-write internally, and on the outside they are simply immutable objects.
The references you talk about are called, surprisingly, refs and they support full in-memory transactions. A simpler kind of a reference is atom, which fits your description 100%.
The whole Core API is devoted to elegant and epressive manipulation of these structures in a thread-safe, lock-free manner.
Yes. Lazy copying is easy to implement, but you would generally have to do it yourself.