We use the Reflection API to find out about the internals of a Java class — its fields, constructors, methods and annotations. We can also use it to programmatically instantiate objects, invoke methods and access fields at runtime.
This is a very powerful API. It is used extensively by JEE containers, the Spring framework, GUI builders and other APIs.
In my previous post about the compiler
-g debug flag, I mentioned the concept of decompiling Java code. Java decompilers are very useful if you need to retrieve lost source code, or you want to see what code the compiler has automatically generated for you (e.g. for auto-boxing, generics, enums, enhanced for-loops and the like).
There’s a reason you pay for plastic shopping bags. It is to protect the environment. Durable shopping bags can be re-used, and don’t pollute our oceans and landfills.
Re-use is a good thing – and not just for the environment. We know that code re-use is important. And that also applies to data. If we have data that is used in many places, we only want to store it in one place and have one source.
That’s the same principle behind XML external entities (XEE). Unfortunately, there’s a potential security loop hole.
Cross-site request forgery (CSRF or XSRF) is also known as “Sea Surf” or “Session Riding”. But unlike real surfing, it’s got nothing to do with waves, water or the beach.
Occasionally you might have to debug your Java code. Now maybe your code is always correct, and never needs debugging, but then you might want to help someone else in the team who has a problem.
When we debug code, we want to have as much information about our code as possible. One of the problems we face when debugging is that the compiler strips the method parameter names and local variable names from the class file. If we’re stepping through our code, we would like to see the correct names in our debugger.
Last week I wrote about Cross-Site Scripting, and the serious consequences it can have.
According to OWASP, XSS affects about two thirds of all applications. That statistic should scare you!
Now that I have your attention, let’s look at how we can stop XSS.
There’s probably nothing programmers hate more than documenting their code. Even doing timesheets takes second place on the list of things programmers hate to do.
Fortunately help is at hand.
I’ve mentioned Cross-Site Scripting, aka XSS, in some of my previous posts. And I’m sure you’ve heard of it as well.
XSS is often categorised as either reflected XSS or stored XSS. And then DOM-based XSS was added. OWASP now categorises XSS as:
Both of these can be either reflected or stored, which can make it all a little confusing.
Here’s a fact that you may not know. When you auto-box integral primitives (
long) to their respective wrapper classes (
Long), the wrapper classes cache all values from
+127. These values are later used by the
valueOf() methods to give better performance than using a constructor.
No, we are not talking about delicious double-chocolate cookies. Although I’ve really missed the fabulous Incus Data cookies during lockdown.
As you know, cookies are small text files. They are usually created by the web server, but are saved and managed by your browser.
Cookies can be harmless or incredibly dangerous. It all depends on how you use them.