Skip to content
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

[AppSec] Skip converting Strongly Encapsulated Internals for WAF #3501

Merged
merged 2 commits into from
Apr 20, 2022

Conversation

ValentinZakharov
Copy link
Contributor

What Does This Do

Prevents decomposition of object that are belongs to Strongly Encapsulated Java Internals, in order to avoid throwing InaccessibleObjectException in Java 9+. Represents such objects as strings instead.

Motivation

Customer reported AppSec false positive issue, when request body contains:
<error: Unable to make field private final int java.time.LocalDate.year accessible: module java.base does not "opens java.time" to unnamed module @34f15e65>
and
<error: unable to make field private final int java.lang.string java.lang.enum.name accessible: module java.base does not "opes java.time" to unnamed module @34f15e65>
Additionally customer emphasized, they are using Dropwizard running on Java 17.

Additional Notes

If the request body contains a complex object, AppSec converts it in java standard datatypes with strings for WAF analysis. In order data converted (into map of strings, array of string, etc.) can be properly consumed by WAF.

Decomposition of complex object is done with Java Reflection. Starting from the Java 9, there were introduced Strongly Encapsulated Internals (see: JEP-260, JEP-396, JEP-403), which made some of standard java classes inaccessible for Reflection. As the result, decomposition throws InaccessibleObjectException for classes like LocalDate or Enum when running on Java 16+.

@ValentinZakharov ValentinZakharov added the comp: asm waf Application Security Management (WAF) label Apr 14, 2022
@ValentinZakharov ValentinZakharov requested a review from a team as a code owner April 14, 2022 11:15
@cataphract
Copy link
Contributor

This doesn't have to do with the java.time or java.lang specifically right? It's a general JPMS-related problem, no?

@ValentinZakharov
Copy link
Contributor Author

ValentinZakharov commented Apr 14, 2022

Yes, that's correct, I'm not sure if any classes from another java.* packages might be used as POJO. Please correct me If I'm missing something.

Basically we can check package accessibility but only starting from Java 9.

@ValentinZakharov ValentinZakharov force-pushed the vzakharov/skip_java_internals branch 4 times, most recently from 94c3470 to 8bcf658 Compare April 20, 2022 11:48
@ValentinZakharov ValentinZakharov requested a review from a team as a code owner April 20, 2022 11:48
if (setAccessible(f)) {
try {
newMap.put(f.getName(), guardedConversion(f.get(obj), depth + 1, elemsLeft));
} catch (IllegalAccessException e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be caught inside the setAccessible private method and return false from there.

@bantonsson bantonsson changed the title [AppSec] Skip decoupling Strongly Encapsulated Internal classes for WAF [AppSec] Skip converting Strongly Encapsulated Internals for WAF Apr 20, 2022
@ValentinZakharov ValentinZakharov merged commit 94c97e1 into master Apr 20, 2022
@ValentinZakharov ValentinZakharov deleted the vzakharov/skip_java_internals branch April 20, 2022 21:13
@github-actions github-actions bot added this to the 0.100.0 milestone Apr 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp: asm waf Application Security Management (WAF)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants