Checking Java software for the absence of vulnerabilities typically includes a review of the source code, which in most cases is Java code. This is where the tools and toys of the software industry can help you with.
But for a complete understanding, you may need to understand the third-party dependencies, which may be written in Scala, JShell, Groovy or other, or even be available as compiled bytecode, or written in C/C++ and provided in a native library (JNI).
No worries, you don't need to learn these languages too, you need to know what is important to look for, and that can be different for each of the above code sources.
For the training you should be familiar with:
- Developing software in Java
- Be able to use the editor and compiler with elegance
- Have a basic understanding of typical threats that may hide in software
- Please bring a machine with a working docker installation
- An image with tools and examples will be provided at the beginning of the course
- You may want to have 20GB free
- You will start with a brief walkthrough of the Java Security architecture, following by a first round of presenting usual suspects that may cause security problems
- To practically manifest the above list of culprits we present a range of tools to allow basic scanning of software projects, we will see what this tools can do, we will see where these tools fail, and how to construct code that bypass checks in these tools
- You will learn about usage patterns with advanced APIs (Reflection, Method Handles, scripting extensions), and also about typical antipatterns that cause security fails. This is followed by a history of flaws in typical 3rd party libraries and frameworks (Apache, Spring). At this point, it is good to learn about the typical categorization schemes (such as CVE, CWE) and learn about strategies to find more information than the typical advisories and update reports tell you.
- This day will be completed with a practical session a scavenger hunt of live Java projects on Github. Everything you find there could be your first 0-day, and all we care for is defense, so at this point, you could also learn how to write a good security patch and how to submit it to the vendor.
- This day starts with a brief introduction to the relevant guidelines to writing secure Java software (Oracle Secure Coding Guidelines, CERT SEI), where to find those being supported by tools, or write your own tool extensions (you will cover SpotBugs and PMD, as well as a standalone scanner).
- You will now enter the areas, where Java code security is influenced by the security level of dependencies, such as code supplied in Jars without source code, or written in native code. You will learn about bytecode, decompilers and native debuggers. You will learn about to tools to generate bytecode, but also those tools for a better understanding of what goes on inside the JVM when the JIT compilers sets in or a garbage collection occur (and how that relates to the source code).
- Next on the agenda are typical server-side scenarios, such as bugs in web servers and web applications, the goal is to show how the integrity of remote systems could be compromised and how protection mechanisms can be constructed.
- A security training would not be complete without a fuzzing session, therefore you will dive into the wonderful world of mutated data and code coverage by the help of AFL, Kelinci, and JQF. Of course, to comply with the training goal we analyze the findings on a source code level and try to come up with good patches.
- To wrap up the training you will enter the topic of malware, and how to adapt and identify the coding skills used to construct it. This lesson will be important to understand that code scanning tools can only be of help if the author of the software we analyzed is coded by the book. You will learn about typical obfuscation tools and about a systematic behavior-based approach to work around obfuscation.
For more information about this training visit https://www.researchandmarkets.com/r/mfdt4f