Week 5 — Code Hardening: Java and Interpreted Languages¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

java -version; python --version
cd cen429-secure-programming\code\week-05\01-sql-enjeksiyonu
.\demo.ps1

sudo apt install -y openjdk-17-jdk python3
cd cen429-secure-programming/code/week-05/01-sql-enjeksiyonu
sh demo.sh

0. Before we start¶

This section prepares you for the week. It first briefly recalls the earlier topics this week builds on; it then defines each of this week's concepts in one sentence and links it to the section where it is explained in full. Background knowledge not covered in earlier weeks is explained from scratch under the "Background" headings.

What we bring from earlier weeks¶

• Memory bugs (overflow, use of freed memory, undefined behaviour) — across the first four weeks we saw how buffer overflow, use of freed memory, and undefined behaviour arise in C/C++ and how they are prevented (Week 4). This week Section 1 compares which of these bug classes disappear at the language level in managed languages, and which do not.
• The structure of the SEI CERT rule book — in Week 4 we saw the common structure of the SEI CERT C/C++ rules: identifier, title, non-compliant example, compliant solution, risk (Week 4, §2). This week Section 2 reuses the same structure for the Java standard, with the IDS/SER/FIO/MSC/ERR categories.
• TOCTOU (time-of-check to time-of-use) — in Week 2 we saw that the gap between checking a file's permissions and actually using it is a race-condition flaw (Week 2, §12). This week Section 6 justifies, on the same principle, re-checking that a path is still inside the root after the file has been opened.

This week's concept map¶

Background: managed languages and garbage collection¶

A managed language (Java, C#, Python, JavaScript, and the like) is a language whose memory is managed automatically by the runtime instead of the programmer; the programmer never calls malloc/free, and instead a garbage collector (GC) automatically cleans up objects that are no longer used, in the background. This single difference is why most of the overflow and use-of-freed-memory bugs we saw in C/C++ over the first four weeks disappear at the language level; §1 shows this in detail.

Background: databases and SQL¶

SQL is the query language used to talk to a database (SELECT ... WHERE ... and the like); an application reads or writes data by putting a value it received from the user (a username, a search term) into such a query. If that value is spliced into the query text without escaping, the SQL injection we will meet in §3–4 results.

Background: reflection and dependencies¶

Reflection is the ability to find and call a class or method at run time, from a string (Class.forName("..."), getMethod("...")), instead of writing it by name directly in the source; §12 shows how this interacts with obfuscation. A dependency is an external library your project uses that your own team did not write; even if your own code is secure, a flaw in a dependency you use affects you too — §14 covers this with the SBOM.

How do the concepts connect to each other?¶

The terms above are not a random list; each one sits on top of the previous one. The table below shows the relation "to understand this I must first know that" — if you forget a term, come back to the "prerequisite" column of the table.

The direction in which this table is read matters: to understand the term at the start of a row, you must first know the term in the "prerequisite" column. For example, before reading the "parameterised query" section, the concept of "injection" ("if data travels through the same channel as a command, it is taken for a command") has to already be settled; otherwise the question "why is the ? mark safe but string concatenation is not?" is left hanging in the air.

1. What do managed languages solve, and what do they not solve?¶

The first four weeks were spent with C and C++: buffer overflow, freed memory, integer overflow, undefined behaviour. In managed languages such as Java, Kotlin, C#, Python and JavaScript, most of these bugs disappear at the language level:

This is a large win; but it is not enough to say "we use Java, so we are safe." The classes below are language-independent, and they are the most commonly found vulnerabilities from web applications all the way to mobile applications:

Worked example: why an array overflow crashes in Java but not in C¶

In Week 4 we saw that for a 10-element array such as buf[10], writing to index 10 (the 11^th element) is undefined behaviour in C, and most of the time silently corrupts adjacent memory with no error at all. Let's trace the same bug in Java, step by step.

public class DiziTasmasi {
    public static void main(String[] args) {
        int[] dizi = new int[10];      // a 10-element array: indices 0..9 are valid
        dizi[9] = 42;                   // valid: the last element
        System.out.println("dizi[9] = " + dizi[9]);
        dizi[10] = 99;                  // INVALID: there is no 11th element
    }
}

dizi[9] = 42
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
    Index 10 out of bounds for length 10
        at DiziTasmasi.main(DiziTasmasi.java:6)

Step by step, what happened:

1. On every array access (dizi[10]) the JVM first checks whether the index is within the bound 0 ≤ i < length; this check is a part of the bytecode the compiler generates that runs before every aload/iastore.
2. Because 10 is equal to or greater than the array's length, 10, the check fails.
3. The JVM does not write to adjacent memory; instead it throws an ArrayIndexOutOfBoundsException and stops the program (or, if a try/catch exists, only that block) in a controlled way.
4. Which line, with which index, shows up in the error message — whereas in the C example from Week 4 this would have been a silent memory corruption or a random crash, and finding the source of the bug could take hours.

2. SEI CERT Oracle Java: the managed language's rule book¶

The SEI CERT Java standard, which we met in Week 4, has the same structure: identifier, title, non-compliant example, compliant solution, risk. Identifiers end with the -J suffix.

Why are CERT rules still needed if Java has solved memory bugs?¶

The SEI CERT C rules we saw in Week 4 (ARR, STR, MEM, …) targeted memory-management bugs for the most part; because the JVM closes off this class automatically, the MEM category in the Java standard is almost empty. But the IDS, SER, FIO, MSC and ERR categories in the table are bugs the language does not solve: topics such as input validation, deserialisation and leaking sensitive information are about design decisions, not memory. This is why CERT works from language to language on the principle "which category grows, which shrinks": in the C standard MEM and ARR are printed bold; in the Java standard IDS and SER are.

3. The common root of injection: data and command mixing together (Recipe 3.11)¶

SQL injection, command injection, path traversal, XML injection, template injection, the log injection from Week 2, and the format-string flaw from Week 4 are different faces of the same bug: inside the text handed to an interpreter (a SQL engine, a shell, a filesystem, an XML parser, printf), the command and the data travel through the same channel. If the user data contains the interpreter's special characters (', ;, ../, <, %), the data becomes part of the command.

This is why the real fix for every kind of injection is the same: give the command and the data through separate channels. Sanitising with an escape character (' → '') is the second line of defence; every interpreter's escaping rules are different, and forgetting just one is enough.

Why does the interpreter mistake input for "code"? Step by step¶

This is the link students miss the most: the interpreter does not know which characters of the string it receives are "fixed code the programmer wrote" and which are "data the user entered." All it has is a sequence of characters, one after another. Let's make this concrete; let's follow, character by character, how a SQL engine reads the string that "SELECT ... WHERE ad = '" + ad + "'" builds at run time (assume the ad variable holds the input x' OR '1'='1):

1. Java first performs the string concatenation; the result is a single piece of plain text: SELECT ... WHERE ad = 'x' OR '1'='1'. From this point on, the information "this part was written by the developer," "this part was entered by the user" has already been lost — all that remains is characters.
2. This plain text is sent to the SQL engine as a single command. The engine's parser (lexer/parser) scans the string left to right, character by character, and enters a state based on each character.
3. After reading WHERE ad =, it meets a space and then a ' character → the parser moves into the "string literal started" state. From then on it treats every following character (letter, space, O, R, …) as the content of that string literal, up to the next ' character.
4. The first ' in the input (the one the user wrote) satisfies exactly this expectation: the parser says "the string literal has ended" and returns to ordinary SQL syntax.
5. At the point it returns to, the text OR '1'='1' now stands in front of the parser; this text is read as SQL keywords and operators (OR, =), because the parser has left the "string literal" state.
6. Result: the engine has parsed a single query, but this query's logical structure (... OR always_true instead of ... AND ...) has been determined by the characters the user typed in.

The critical point is this: the parser is not making a mistake; it is behaving exactly according to SQL syntax rules. The bug is that there is no separate channel carrying the information "are you part of the code, or are you data?" to the interpreter. The same sequence of steps (an interpreter → character-by-character scanning → a state change on a special character) repeats identically for the shell with ;, for the filesystem with ../, and for XML with </&; only the "special character" and the "state machine" change. Sections 4–8 will show the concrete counterpart of these steps in each interpreter.

4. SQL injection¶

Imagine that behind a login form there is code like this:

String sql = "SELECT id, rol FROM kullanicilar WHERE ad = '" + ad +
             "' AND parola_ozeti = '" + ozet + "'";
ResultSet rs = baglanti.createStatement().executeQuery(sql);

When the username field has ayse typed into it, the query behaves as expected. But if the user types ayse' --, the query turns into this:

SELECT id, rol FROM kullanicilar WHERE ad = 'ayse' --' AND parola_ozeti = '...'

-- means "comment to the end of the line" in SQL: the password check has been erased from the query. A single quote character in the input changed the query's structure. With the same technique an attacker can read other tables (UNION SELECT), modify or delete records, and, depending on the database configuration, even run operating-system commands. SQL injection has sat near the top of the OWASP Top 10 lists for more than twenty years (CWE-89).

The fix: a parameterised query¶

String sql = "SELECT id, rol FROM kullanicilar WHERE ad = ? AND parola_ozeti = ?";
try (PreparedStatement ps = baglanti.prepareStatement(sql)) {
    ps.setString(1, ad);
    ps.setString(2, ozet);
    try (ResultSet rs = ps.executeQuery()) {
        /* ... */
    }
}

The query's text is fixed, and it is sent to and compiled by the database first; the values arrive through a separate channel. Whatever the value contains (', --, ;), it is compared only as a value; it cannot touch the query's structure. This is the exact counterpart of the "two channels" principle from the previous section (IDS00-J).

Why does a parameterised query work, mechanically?¶

In Section 3 we saw that the parser works character by character. PreparedStatement splits this mechanism into two stages; that is where the magic hides:

1. Prepare stage: when baglanti.prepareStatement(sql) is called, only the text SELECT id, rol FROM kullanicilar WHERE ad = ? AND parola_ozeti = ? is sent to the database server — the user's input does not exist yet. The server parses this text (with the state machine from Section 3), produces a query plan and keeps this plan in memory. The ? marks are placeholders inside the plan, marked "a value will go here."
2. Bind stage: when ps.setString(1, ad) is called, the content of the ad variable is never concatenated with the SQL text. The driver sends the value through a separate binary protocol message (the wire protocol between JDBC and the database), saying "the value of placeholder 1 is this byte sequence."
3. When ps.executeQuery() runs, the database places the incoming values directly into the plan that has already been parsed. Even if the value contains ' or --, these characters never pass through the parser — parsing is already finished. The characters are only copied over as "the byte sequence to compare against this column."

It is instructive to compare this with the printf("%s", girdi) example from Section 3: the string put in place of %s is not reinterpreted, the way a %n inside a format string would be; it is printed as-is. In a parameterised query too, the value put in place of ? is not re-parsed, the way the query text is; it is compared as-is. Both mechanisms rest on the same principle: the parsing that determines structure happens once; binding the data is separate, and happens afterwards.

Where a parameterised query is not enough¶

Defence in depth¶

• Least privilege: the application's database user should reach only the tables it needs, and only with the operations it needs. The user behind the login screen should not have DROP TABLE rights.
• Error message: showing the database error to the user as-is leaks the query's structure and table names (ERR01-J). Give the user a generic message; put the detail in a secure log.
• Input validation: for fields with a known expected shape (an ID number, a date, an e-mail address), white-list validation narrows the attack surface; but it does not replace a parameterised query.

Worked example: reading Demo 1's output line by line¶

The Python part of Demo 1 (sqli.py) sets up an SQLite database with three synthetic users (ayse, mehmet, and an admin, admin), and runs the same login query in two ways. Let's follow, step by step, the output you will see when you read and run the code; at every step we tie why that result came out back to the mechanism from Sections 3–4.

[KOTU YOL]
   Uretilen SQL:
   SELECT id, ad, rol FROM kullanici WHERE ad = 'ayse' AND parola = 'parola123'
   -> 1 satir dondu. GIRIS BASARILI:
      id=1 ad=ayse rol=kullanici
[IYI YOL]
   Uretilen SQL (sablon):
   SELECT id, ad, rol FROM kullanici WHERE ad = ? AND parola = ?   [degerler ayrica gonderilir]
   -> 1 satir dondu. GIRIS BASARILI:
      id=1 ad=ayse rol=kullanici

As expected: when the input is harmless, both the wrong code and the correct code produce the same result. This is exactly why the wrong code goes unnoticed during development — testing is done with honest input.

[KOTU YOL]
   Uretilen SQL:
   SELECT id, ad, rol FROM kullanici WHERE ad = 'ayse' AND parola = '' OR '1'='1'
   -> 3 satir dondu. GIRIS BASARILI:
      id=1 ad=ayse rol=kullanici
      id=2 ad=mehmet rol=kullanici
      id=3 ad=admin rol=yonetici
   ^ Parola bilinmeden giris yapildi: sorgu yapisi degisti.
[IYI YOL]
   -> Sonuc yok. GIRIS REDDEDILDI.
   ^ Girdi bir DEGER olarak arandi; oyle bir parola yok: RED.

Follow the steps from Section 3 here: after parola = ' is written, the attacker's first ' character closes the string literal; the text OR '1'='1' that follows is then read as a SQL operator. Because '1'='1' is always true, the right-hand side of the AND is true for every row; the query effectively becomes WHERE ad='ayse' OR true, and the entire table is returned. In the correct path, the whole string the attacker typed (quote, OR, equalities and all) goes to the database as a single text value; since no one has such a password, the result is empty.

[KOTU YOL]
   Uretilen SQL:
   SELECT id, ad, rol FROM kullanici WHERE ad = '' OR rol='yonetici' --' AND parola = 'farketmez'
   -> 1 satir dondu. GIRIS BASARILI:
      id=3 ad=admin rol=yonetici
   ^ Baska kullanicinin (yonetici) satiri sizdirildi.
[IYI YOL]
   -> Sonuc yok. GIRIS REDDEDILDI.
   ^ Boyle bir ad yok: sizinti yok.

Here the attacker both changed the query structure with OR and used -- to turn the rest of the query (the password check) into a SQL comment, disabling it; it now no longer matters at all what is written in the password field. In the parameterised query this string (quote, OR, -- and all) is compared against the ad column as a single text value; since no such username exists, the result is empty.

Demo 1 — SQL injection: string concatenation and parameterised query¶

cd code\week-05\01-sql-enjeksiyonu
.\demo.ps1

cd code/week-05/01-sql-enjeksiyonu
sh demo.sh

5. Command injection¶

Applications sometimes hand a task off to an external program: converting an image, opening an archive, testing a network address. If the command is given to a shell as a single string, the shell characters inside the string (;, &&, |, `, $( )) start new commands:

String kullanici = istek.getParameter("ad");
Runtime.getRuntime().exec(new String[]{"sh", "-c", "echo Merhaba " + kullanici});
/* ad = "ayse; <another command>"  →  the shell runs two commands */

The same situation arises on Windows with cmd /c and the & character. Java's Runtime.exec(String) form, which takes a single string, also splits the string on whitespace by its own rules; it is possible to shift arguments around by playing with quotes (IDS07-J).

How does the shell parse input, step by step?¶

Let's apply the general principle from Section 3 to the shell (sh, bash, cmd). Suppose the kullanici variable holds "ayse; echo SIZDI"; Java concatenates this string and hands the shell the following single piece of text: echo Merhaba ayse; echo SIZDI. The shell processes it like this:

1. The shell first splits the text it receives into commands, based on command separator characters (;, &&, ||, end of line). This is the shell's own syntax rule, exactly like the SQL parser changing state on a ' character.
2. The part up to the ; character (echo Merhaba ayse) is separated out as the first command.
3. The part after the ; (echo SIZDI) is separated out as a second, independent command.
4. The shell runs both commands in sequence — as if the user had typed two separate lines at the terminal.
5. The application itself believes it made a single exec call; but from the shell's point of view there are two commands, because the shell re-parsed the text by its own rules.

The critical point is, again, the same: the shell is not making a mistake, it is reading the ; character exactly according to its syntax rule. Java's information "this was a username" was already lost the moment the string reached the shell.

The fix: no shell, with an argument list¶

private static final Pattern AD = Pattern.compile("^[A-Za-z0-9_]{1,32}$");

if (!AD.matcher(kullanici).matches()) {
    throw new IllegalArgumentException("gecersiz ad");       // default: reject
}
Process p = new ProcessBuilder("/usr/bin/printf", "Merhaba %s\n", kullanici)
        .redirectErrorStream(true)
        .start();

1. No shell: ProcessBuilder launches the program directly; ; or & are just characters inside an argument.
2. Full path: the program's full path is given, against the PATH attack from Week 1.
3. Allow list: the argument is validated against the expected shape before it is run.
4. Best of all: removing the need for an external program entirely. Using a library to convert an image, or InetAddress.isReachable to test an address, eliminates the whole problem.

Worked example: reading Demo 2's output line by line¶

The Python part of Demo 2 (komut.py) runs a "greeting tool" first through the shell (shell=True), then with an argument list (shell=False). On WSL/Linux, the actual output is as follows:

[KOTU YOL]
   Kabuga giden komut:
   echo "ARAC CIKTISI: Merhaba" Ayse
   | ARAC CIKTISI: Merhaba Ayse
[IYI YOL]
   Arguman listesi:
   [python, -c, ...] ... 'Ayse'
   | ARAC CIKTISI: Merhaba Ayse

[KOTU YOL]
   Kabuga giden komut:
   echo "ARAC CIKTISI: Merhaba" Ayse; echo SIZDI-KOMUT-ENJEKSIYONU
   | ARAC CIKTISI: Merhaba Ayse
   | SIZDI-KOMUT-ENJEKSIYONU
   ^ 'SIZDI...' satiri = enjekte edilen komut kostu.
[IYI YOL]
   Izin listesi REDDETTI (^[A-Za-z0-9_]+$):
   girdi = Ayse; echo SIZDI-KOMUT-ENJEKSIYONU
   -> Program hic calistirilmadi.
   ^ Izin listesi bosluk/;/& gordu ve reddetti.

In the wrong path, the shell followed the five steps above, split the string in two at the ;, and ran two separate commands; the second line (SIZDI-...) is proof that the injected command actually ran (the demo uses a harmless echo). In the correct path, ProcessBuilder/subprocess never calls any shell; the input is a single argument, and the allow list (^[A-Za-z0-9_]+$) rejects this input, which contains a space and a ;, before it is ever run.

Demo 2 — Command injection¶

cd code\week-05\02-komut-enjeksiyonu
.\demo.ps1

cd code/week-05/02-komut-enjeksiyonu
sh demo.sh

6. Path traversal (Recipe 3.7)¶

A file server should only serve files under a specific folder. If the requested file name is appended directly to this folder's path, sequences of ../ escape outside the root:

Path kok = Paths.get("/srv/veri");
Path dosya = kok.resolve(istek);                  // istek = "../../etc/passwd"
return Files.readAllBytes(dosya);                 // a file outside the root is read

Path normalisation step by step: why does ../ walk back up to the root?¶

resolve()/normalize() process a path with a single stack algorithm. Let kok = "/srv/veri" and istek = "../../etc/passwd". The filesystem processes this request segment by segment, like this:

Result: /etc/passwd — a path completely outside the root (/srv/veri). The .. characters are, for the parser, the command "go up one folder"; just as ' in SQL is the command "close the string literal," .. plays the same role in the filesystem. This is why a check that only searches the raw string for ".." (istek.contains("..")) is not enough: forms such as ..%2f (URL-encoded) or ....// (nested spelling) bypass this search, while still ending up outside the root when processed with the same stack algorithm. The correct order is therefore to normalise first (run the stack algorithm to completion), then check the result — we check the final stack content, not the intermediate steps.

The fix: canonicalise first, then check whether it is inside the root¶

Path kok = Paths.get("/srv/veri").toRealPath();
Path aday = kok.resolve(istek).normalize();      // if istek is an absolute path, resolve returns it unchanged
if (!aday.startsWith(kok)) throw new SecurityException("kok disi");
Path gercek = aday.toRealPath();                  // also resolves symbolic links
if (!gercek.startsWith(kok)) throw new SecurityException("kok disi");
return Files.readAllBytes(gercek);

Order matters: first the canonical (single, definitive) path is obtained, and only then is it checked. Checking the raw string (istek.contains("..")) is not enough; ..%2f, ....//, ..\ on Windows and absolute paths with a drive letter, Unicode forms, and symbolic links can all bypass the check. toRealPath() also resolves symbolic links to their real targets; because the TOCTOU problem from Week 2 (the time between check and use) still applies, it is most robust to verify again that the file is inside the root after it has been opened.

Worked example: reading Demo 3's output line by line¶

The Python part of Demo 3 (yol.py) treats the cikti/veri/ folder as the root; outside the root (cikti/gizli.txt) there is a synthetic "admin note." The actual output:

[KOTU YOL]
   Cozulen yol: .../cikti/veri/rapor.txt
   OKUNDU -> Herkese acik rapor (sentetik).
[IYI YOL]
   Cozulen yol: .../cikti/veri/rapor.txt
   OKUNDU -> Herkese acik rapor (sentetik).

[KOTU YOL]
   Cozulen yol: .../cikti/gizli.txt
   OKUNDU -> GIZLI: sentetik yonetici notu (kok disinda).
   ^ Kok disindaki gizli dosya sizdirildi.
[IYI YOL]
   REDDEDILDI: kok disina cikiyor -> .../cikti/gizli.txt
   ^ resolve() + kok denetimi engelledi.

In the wrong path, the expression KOK / "../gizli.txt" pops the veri segment with the stack algorithm above and lands directly on cikti/gizli.txt — it has climbed to one folder above the root. In the correct path, the same normalisation happens, but because the result does not start with the root (cikti/veri), the request is rejected before it is ever executed.

Demo 3 — Path traversal¶

cd code\week-05\03-yol-gecisi
.\demo.ps1

cd code/week-05/03-yol-gecisi
sh demo.sh

7. Unsafe deserialisation¶

Serialisation is converting an object into a byte sequence to store it or send it over the network; deserialisation is the reverse. Java's built-in ObjectInputStream mechanism creates an object of any serialisable class whose name is written in the byte stream, and while doing so runs some of that class's methods (such as readObject, readResolve).

The problem is this: if the byte stream comes from an untrusted source, the attacker chooses which classes get created. Innocent-looking classes found in libraries on the application's class path can be chained together so that, as they are created, they trigger one another. In real incidents these chains have gone all the way to remote code execution; in 2015 this is exactly how a series of vulnerabilities, working through classes in a widely used common library, affected many enterprise server products. This is why CWE-502 ("deserialisation of untrusted data") is part of the "software and data integrity failures" category in the OWASP Top 10.

How does a byte stream carry a class name? The mechanism, step by step¶

We are not writing the attack chain itself, but understanding where the authority in the attacker's hands comes from also makes the defence meaningful. The beginning of the byte stream ObjectOutputStream produces has a fixed format:

1. The first two bytes are always AC ED — the "stream magic," a signature stating that this stream is a Java object stream.
2. The next two bytes are 00 05 — the version of the stream format.
3. After that comes an object block; this block begins with a class descriptor: the class's fully qualified name (something like com.ornek.Ayar) sits in the stream as plain text, with a length prefix.
4. When ObjectInputStream.readObject() runs, it first reads this name, then looks up and loads the class on the class path with a call resembling Class.forName(isim) — no type check has happened yet, because the stream itself is stating what the expected type is.
5. Once the class is loaded, the JVM allocates an object of this class (without an ordinary constructor call, through a mechanism specific to deserialisation) and writes the field values from the stream into this object; if the class defines special methods such as readObject/readResolve, these are also run at this point.

The result of steps 3–4 is: the party that sends the stream decides which class gets loaded, not the application. If the stream comes from an untrusted source, any class name on the class path can be written; then whatever that class's readObject/readResolve methods do while they run (opening a file, creating another object, calling a method) is under the attacker's control. A series of such classes triggering one another in a chain (the "gadget chain" of real incidents) can end up at arbitrary code execution — we are not writing how the chain is built, but steps 3–4 fully explain "why it is possible."

Layers of defence¶

ObjectInputFilter filtre = ObjectInputFilter.Config.createFilter(
        "com.ornek.Ayar;java.base/*;maxdepth=5;maxarray=1000;maxbytes=65536;!*");
try (ObjectInputStream in = new ObjectInputStream(akis)) {
    in.setObjectInputFilter(filtre);
    Ayar a = (Ayar) in.readObject();          // unexpected class → InvalidClassException
}

The pattern is read left to right: allow classes in com.ornek.Ayar and the java.base module, apply the limits, reject everything else (!*). The last item is the deny-by-default principle; if it is left out, the filter turns into a blacklist.

Worked example: reading Demo 7's output line by line¶

Demo 7's Java code (SeriDemo.java) defines two harmless classes: the expected Ayar (carries a name + value), and the unexpected BaskaSinif (in a real attack this would be a "gadget"; here it only carries a string). Both are serialised and then deserialised, first without a filter, then with one. The actual output:

   [beklenen Ayar] KABUL -> Ayar(ad=zaman-asimi, deger=30)  (Ayar)
   [beklenmeyen BaskaSinif] KABUL -> BaskaSinif(yuk=beklenmeyen-sinif)  (BaskaSinif)
   ^ Filtre olmadan gelen HER sinif olusturulur;
     gercekte bu bir gadget zinciri olabilirdi.

   [beklenen Ayar] KABUL -> Ayar(ad=zaman-asimi, deger=30)
   [beklenmeyen BaskaSinif] REDDEDILDI (filtre): beklenmeyen sinif engellendi.

The filter "SeriDemo$Ayar;java.base/*;!*" allows only the Ayar class and Java's own core classes. Recall the mechanism from Step 1: the filter checks the name read from the stream before the class is loaded; because BaskaSinif is not on the list, the readObject call stops with an InvalidClassException — the class is never instantiated, none of its methods run.

Demo 7 — Safe deserialisation¶

cd code\week-05\07-deserializasyon
.\demo.ps1

cd code/week-05/07-deserializasyon
sh demo.sh

8. XML, template and other kinds of injection¶

The same "mixing of data and command" bug shows up in every interpreter. The four most common ones:

The XXE mechanism, step by step (without writing a payload)¶

The XML standard allows a document to declare a DTD (Document Type Definition) at its start, and to define special abbreviations (entities) inside that DTD — much like a "find-and-replace" shortcut in a text editor: wherever &abbreviation; is written in the document, the real content defined in the DTD is substituted in. The problem is that this "real content" can come from an external source (a file path or network address marked with the SYSTEM keyword):

1. While reading the document, the parser first processes the DTD block; it records every <!ENTITY ad SYSTEM "kaynak"> definition inside the DTD into an abbreviation table (ad → kaynak).
2. While processing the body of the document, if the parser meets a reference of the form &ad;, it opens the kaynak from the abbreviation table (reads the file or makes a network request) and substitutes its content in place of &ad;.
3. This substitution happens during parsing, without the application's own logic ever getting involved; by the time the application "finishes reading" the XML, the entity has already been expanded, and the file's content has been mixed into the document text.
4. If the application shows this expanded text back to the user in any form (in an error message, in a response field), the file's content has been leaked; if the source is a network address, this also means the server has sent a request into the internal network (SSRF, Week 3).

The critical point is, again, the same: the parser is not making a mistake, it is implementing the DTD standard exactly. The hardening below closes off the first step of these four (processing the DTD at all) and the second step (opening externally sourced entities) from the start; that way steps 3–4 never get a turn.

DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
f.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);   // no DTD
f.setFeature("http://xml.org/sax/features/external-general-entities", false);
f.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
f.setXIncludeAware(false);
f.setExpandEntityReferences(false);

The rule is the same every time: know which of the interpreter's features are turned on, disable what you do not need, do not pass data through the command channel. The book's XSS recommendations in Recipe 3.10 (encoding output based on context, validating input with a white list) have become the default behaviour of today's web frameworks; but turning on a "raw HTML" option in a template, or building a page by string concatenation, brings the same bug right back.

The same mechanism in XSS: how does the browser parse HTML?¶

The exact counterpart of the "the parser expands externally sourced content" idea from XXE, in XSS, is the browser's HTML parser. In a string concatenation like "<p>" + yorum + "</p>", if the yorum variable contains an HTML tag-opening character (<), the browser moves from the "text state" into the "tag state" the moment it sees this character — exactly the same mechanism as the SQL parser changing state on a ' character. Result: part of the text the user wrote becomes part of the page's structure (a new tag, and therefore potentially an executable script tag), and it runs in the browser of every user who views this HTML — the difference from SQL injection is that the victim is not a database, but another user who opens the page. Template engines' "automatic escaping" does exactly the same job as the parameterised query from Section 4: it encodes user data as plain text content, not as HTML syntax (writing < instead of <), so that the parser never enters the "tag state" at all.

9. Interpreted languages: the same bugs in Python and JavaScript¶

The syllabus names this week "Java and interpreted languages." In languages such as Python, JavaScript (Node.js), Ruby and PHP, memory safety is also free; but these languages make generating and running code at run time much easier than Java does. The same bug classes appear here under different names:

eval and friends: running data as code¶

The most dangerous feature of interpreted languages is being able to run a string as code. A string coming from the user reaching eval is the most direct form of injection: the interpreter itself is the command channel.

deger = eval(girdi)                 # WRONG: girdi could be any Python expression

import ast
deger = ast.literal_eval(girdi)     # Better: accepts only LITERALS such as numbers, strings, lists
deger = int(girdi)                  # Best: parse the expected type directly, catch the error

The rule is simple: user data must never reach eval, exec, new Function, or a script engine. If a calculator or a rule engine is genuinely needed, a small parser that recognises only the allowed operations is written instead.

Deserialisation: pickle and YAML¶

Python's pickle module carries the same problem as Java serialisation: the data being decoded determines which objects get created and how; its own documentation explicitly says "never unpickle untrusted data." YAML libraries' full loaders can create objects in a similar way.

import json, yaml

veri = json.loads(metin)            # data only: dict, list, number, string
ayar = yaml.safe_load(metin)        # only basic YAML types
# pickle.loads(metin)               # ONLY on data you produced yourself and verified with an HMAC

Denial of service through regular expressions (ReDoS)¶

The most common tool for input validation is regular expressions; but a badly written regular expression can itself become an attack surface. In engines that use backtracking (the built-in engines of Java, Python and JavaScript), a pattern containing nested repetition runs in exponential time on a specially crafted input:

Pattern: ^(a+)+$
Input:   "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!"   → the engine tries millions of paths to prove there's no match

A single request can keep a server's processor busy for seconds or minutes (CWE-1333). Defence:

1. Avoid nested repetition ((a+)+, (a|a)*, (\w+\s?)*); write the pattern as precisely as possible.
2. Bound the input's length before the regular expression runs (the "length first" principle from Week 4).
3. Use a linear-time engine where possible (RE2 and its derivatives).
4. Turn on static analysis tools' ReDoS rules.

Worked example: why does backtracking grow exponentially? Let's count by hand¶

Let's not leave the "tries millions of paths" sentence from above abstract; let's count, on a small input, exactly how many paths really get tried. The pattern ^(a+)+$ consists of two nested repetitions: the inner (a+) means "one or more a," and the outer (...)"+" repeats this group "one or more times." The engine tries every possibility for how many pieces to split the inner group's a sequence into — this is called the compositions of a number.

Let's take just 4 a characters as input ("aaaa"), and work out by hand how many different ways the engine's inner group can split these 4 a's (each part must contain at least 1 a, because a+ cannot be empty):

There are exactly 8 different splits. The general rule: the number of compositions of n a's is 2^(n-1) (for n=4, 2³=8, which the table confirms). The input "aaaa" matches on its own (the pattern ends with $, and the full match succeeds), so the engine can stop on the first attempt. But if we add a single character to the end of the input that breaks the match ("aaaa!"), the $ can never be satisfied; the engine tries all 8 splits, all of them fail, and it finally says "no match" — but before reaching this conclusion it has exhausted every path.

As n grows, the number of attempts grows exponentially with 2^(n-1):

All the attacker has to do is make n large enough (say, 40–50 characters, not long at all) and add one character at the end that breaks the match; the input is not even kilobyte-sized, but it can lock up a single processing core on the server for minutes. This is the regular-expression counterpart of the "small input, disproportionate effect" idea from Week 4.

Prototype pollution (JavaScript)¶

In JavaScript, objects inherit properties from a prototype chain. If a function that deep-merges a JSON object coming from the user allows writing to a special key such as __proto__, a new property gets added to the shared prototype of all objects; a check elsewhere in the application such as if (kullanici.yonetici) can then come out unexpectedly true. Defence: reject the keys __proto__, constructor and prototype, use prototype-less objects (Object.create(null)) or a Map, and validate incoming JSON against a schema.

10. Bytecode and decompilation¶

The C/C++ compiler translates source code directly into machine code; in the process, variable names, types and most of the structure are lost. The Java compiler, on the other hand, translates source code into the bytecode understood by the JVM (Java Virtual Machine), the virtual machine that runs Java, as .class files; on Android this bytecode is further converted into the DEX format. Bytecode is much more high-level than machine code:

This is why reversing a Java or Android application does not require expertise. The JDK's own tool, javap, shows bytecode as text; decompilers such as jadx, CFR and Fernflower produce readable Java source. In Week 9 we will cover, in depth on the C/C++ side, the very tools used against obfuscation (symbolic execution, pattern recognition) and the principle of resilience against them (Week 9, §10).

private static final java.lang.String GECERLI_PIN;
public boolean pinDogru(java.lang.String);
  Code:
     0: aload_1
     1: ldc           #7        // String 4729
     3: invokevirtual #9        // Method java/lang/String.equals:(Ljava/lang/Object;)Z
     6: ireturn

Bytecode line by line: the JVM is a stack machine¶

Let's make the four lines above readable even for someone who has never seen bytecode before. The JVM is a stack machine: every instruction pushes a value onto a small stack, or pops a value off it:

These four lines are the exact counterpart of the source expression return girilenPin.equals("4729"); — no information has been lost. The // String 4729 comment is javap reading and showing entry 7 from the constant pool; decompilers (jadx, CFR) see these four lines and produce the source code return girilenPin.equals("4729"); directly. In C, in the equivalent machine code after strip, neither the constant's value nor which type the equals call operates on would remain this obvious (compare with the machine code examples from Week 4).

Even without the source code, three things are plainly visible: the constant (4729), meaningful names (GECERLI_PIN, pinDogru), and the logic ("compare the input to this constant"). A password, API key or server address embedded in the code has effectively been handed to everyone who downloads the application (MSC03-J, CWE-798).

Demo 4 — What shows up in the bytecode?¶

cd code\week-05\04-bytecode-decompile
.\demo.ps1

cd code/week-05/04-bytecode-decompile
sh demo.sh

11. ProGuard and R8: shrinking, optimisation, obfuscation¶

ProGuard is an open-source tool that processes Java bytecode; R8 is its successor, developed by Google for Android, compatible with ProGuard rules, and shipped as the default in the Android build system. Both do four jobs:

Obfuscation's output is a mapping file (mapping.txt) that matches old names to new ones:

com.ornek.odeme.KartYoneticisi -> com.ornek.a:
    android.content.Context baglam -> a
    boolean varsayilanKartiAyarla(java.lang.String) -> b

-keep rules: whose name has to be kept?¶

The obfuscator cannot know whether a class or method is called by name from the outside. In the following cases the name has to be kept; otherwise the application throws a ClassNotFoundException or a NoSuchMethodException at run time:

• The application's entry points (in Android, the activities and services named in the manifest; main on the desktop).
• Classes and methods called by name through reflection.
• Methods called by name from native code via JNI, and native methods.
• Fields of serialised classes (JSON libraries use field names).
• A library's public-facing API.

The golden principle of writing rules is to write the narrowest rule. A broad rule like -keep class com.ornek.** { *; } effectively turns obfuscation off; this is the most common "obfuscation exists but doesn't do anything" situation seen in the field.

Worked example: why a missing -keep crashes the application¶

If a class's name is called through reflection (Class.forName("com.ornek.Odeme")) but there is no -keep for this class in proguard-rules.pro, here is what happens, step by step:

1. During compilation, ProGuard/R8 sees no static call to the com.ornek.Odeme class — because the call is written as a string inside Class.forName; the obfuscator does not count strings as part of the class graph.
2. The obfuscator assumes this class is "unused" and either removes it during the shrinking stage or renames it to a.b.c.
3. When the application runs, Class.forName("com.ornek.Odeme") is called; but the class's name in this release is now different (or the class does not exist at all).
4. At run time a ClassNotFoundException is thrown (if the class was removed) or a NoSuchMethodException (if the method's name changed) — this is seen only in the release build, because obfuscation is turned off in the debug build (Section 13); the developer usually only notices the problem during store testing.

java.lang.ClassNotFoundException: com.ornek.Odeme
    at java.lang.Class.forName(Class.java:...)
    at com.ornek.a.b.baslat(Unknown Source:1)

Advanced rules: a configuration from the field¶

The obfuscation configuration of a certified mobile payment library includes the following rules and their rationale (a generalised version of the library's own rules):

What ProGuard does not do¶

ProGuard and R8 obfuscate names, they do not obfuscate strings. The // String 4729 line in javap's output stays exactly the same after obfuscation. They only change control flow as much as a side effect of optimisation. String encryption, control-flow obfuscation and tamper checks require commercial tools (such as DexGuard, iXGuard) or the application's own methods (the next section).

12. String obfuscation and dynamic method invocation¶

The leak in Demo 4 had two sources: plain-text constants and direct calls. Two simple methods reduce them.

Static string obfuscation¶

In Week 4 we saw symbol and string hiding on the C side; here we apply the same idea to Java bytecode. The sensitive string sits in the source not as plain text but as an encrypted or scrambled byte sequence, and is decoded at the moment it is used. Meaningless bytes appear in the constant pool instead of the string itself.

• A simple XOR scramble stops javap and strings scans; but the decoding function and the key are also inside the application. This is an obstacle, not a lock.
• In the field, strings are AES-encrypted by a tool before the build and embedded into the build configuration as encrypted constants; the decoding work is left to a single function on the native side, protected by additional checks, and the decoded string is wiped from memory once the job is done. This way, neither the string itself nor the decoding key is found on the Java side.
• The decoded string sits in memory in the clear at the moment it is used; this is why string obfuscation gains its real meaning together with run-time protection (RASP, Week 6).

Worked example: decoding XOR obfuscation by hand¶

Demo 5's GizliSabit.java file scrambles the synthetic string "sunucu-anahtari-9F3A" with the XOR key 0x5A (decimal 90) and stores it as a byte array. Let's decode the first three bytes of the source array (41, 47, 52) by hand; by the definition of XOR, XOR-ing with the same key twice returns the original value (x ⊕ k ⊕ k = x) — this is why encryption and decoding are the same operation:

  41 = 0010 1001
  90 = 0101 1010
  ----------------  (bit by bit XOR: 0 if the same, 1 if different)
 115 = 0111 0011  =  0x73  =  's'

  47 = 0010 1111
  90 = 0101 1010
  ----------------
 117 = 0111 0101  =  0x75  =  'u'

  52 = 0011 0100
  90 = 0101 1010
  ----------------
 110 = 0110 1110  =  0x6E  =  'n'

The remaining 17 bytes decode with the same operation and give, in order, the characters u, c, u, -, a, n, a, h, t, a, r, i, -, 9, F, 3, A; joined together, they produce exactly the source string "sunucu-anahtari-9F3A". javap -c -p shows not this string, but only 20 meaningless byte values and the ANAHTAR constant; a strings scan does not find the plain text either. But the key (0x5A) and the decoding loop are inside the same class — which is why the warning below applies.

Dynamic method invocation (reflection)¶

Calling a method directly (nesne.gizliIslem()) leaves an explicit link (invokevirtual) to that method in the bytecode; the decompiler easily reconstructs the graph of "this function is called from here." With reflection, the method name in the call is generated at run time (and this name can also be obfuscated):

sonuc = Hesap.gizliIslem(girdi);                                   // an explicit link in the bytecode

Method m = Hesap.class.getDeclaredMethod(adiCoz(ADI_BAYTLARI), String.class);
m.setAccessible(true);
sonuc = (String) m.invoke(null, girdi);                            // the static call graph is broken

Let's be honest about the limits: the method is still defined in the class, and javap -p lists it; reflection only hides the call link. Its real power appears when combined with ProGuard renaming the method (in that case, a -keep rule is needed for the reflectively called method; the rule is written so that it matches the new name generated at run time). Reflection is also slow and loses compile-time type checking; it is used only for a handful of genuinely sensitive calls.

Demo 5 — String obfuscation, reflection and ProGuard¶

cd code\week-05\05-gizleme
.\demo.ps1

cd code/week-05/05-gizleme
sh demo.sh

13. R8 on Android, measuring the effect of obfuscation, and static analysis for Java¶

R8 in the Android build pipeline¶

In Android applications, R8 is turned on with a few lines in the Gradle configuration. Having it on in the release build is a baseline expectation of mobile security standards (OWASP MASVS-RESILIENCE):

android {
    buildTypes {
        release {
            minifyEnabled true          // R8: shrinking + optimisation + obfuscation
            shrinkResources true        // also remove unused resources (images, layouts)
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                          'proguard-rules.pro'
        }
    }
}

proguard-android-optimize.txt contains reasonable defaults for Android; application-specific -keep rules are written into the proguard-rules.pro file. A typical rule for methods called from native code via JNI, and for native methods:

-keepclasseswithmembernames class * {
    native <methods>;
}

Reading crash reports: retrace¶

An obfuscated application's crash report contains lines such as a.b.c(Unknown Source). The mapping file is used to reverse this report (the retrace tool, or uploading the mapping file to a crash-reporting service securely). This is why the mapping file is not deleted; but as we said above, it is also not shipped together with the application. Adding -keepattributes SourceFile,LineNumberTable makes reports readable but puts source file names and line numbers into the package; this is a trade-off, and it is recorded.

Measuring the effect of obfuscation¶

Saying "obfuscation is on" is not enough; you need to show what actually changed. Simple, repeatable metrics:

Filling in this table for before and after obfuscation and putting it into the security guide turns the claim "obfuscation was done" into evidence.

Worked example: doing the measurement step by step on Demo 5¶

Let's actually run the first two rows of this table on the jar files Demo 5 produces (if you downloaded ProGuard with the demo's hazirla script):

cd code/week-05/05-gizleme/cikti
javap -p -classpath oncesi.jar 'GizliSabit' | grep -c "GizliSabit\|coz\|GIZLI\|ANAHTAR"
# Output: every name from the source (class, field, method) appears verbatim

javap -p -classpath sonrasi.jar 'a' | grep -c "GizliSabit\|coz\|GIZLI\|ANAHTAR"
# Expected: 0 (or only the name of the entry point kept with -keep)

ls -la oncesi.jar sonrasi.jar
# Shrinking reduces the size depending on the class count; obfuscation alone barely changes the size

These three commands turn the claim "obfuscation worked" into a measurable number: if the first command's output is greater than zero (a meaningful name is still found), then either the -keep rule was written too broadly, or the obfuscation stage never ran at all — both show the same symptom as the "most common mistake seen in the field" from Section 11.

Static analysis for Java¶

The Java counterparts of the static-analysis layers we saw for C/C++ in Week 4:

mvn com.github.spotbugs:spotbugs-maven-plugin:check
# the findsecbugs-plugin is added to the plugin configuration in pom.xml

These tools are added to the secure build pipeline (CI) from Week 4 in exactly the same way: a new high-severity finding blocks the merge.

14. Dependency security and the software bill of materials (SBOM)¶

Most of a modern application's code does not belong to the team that wrote it. In a typical Java or JavaScript application, a few dozen directly added libraries reach hundreds of components once their own dependencies are counted in. A vulnerability in one of these components is a vulnerability in the application.

What is an SBOM?¶

A software bill of materials (SBOM) is a machine-readable list of every component inside a piece of software: like the ingredients list on a food package. At least the following is recorded for every component:

There are two common standards: OWASP's CycloneDX (security-focused) and the Linux Foundation's SPDX (started licence-focused, now the ISO/IEC 5962 standard). The United States' 2021 cybersecurity executive order and the European Union's Cyber Resilience Act have begun requiring an SBOM from software suppliers.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "ornek-json",
    "version": "1.2.0",
    "purl": "pkg:maven/com.ornek/ornek-json@1.2.0",
    "hashes": [{ "alg": "SHA-256", "content": "9f86d081884c7d65..." }]
  }]
}

From SBOM to a vulnerability list¶

An SBOM is just an inventory on its own; it gains its value once combined with software composition analysis (SCA) tools. These tools match every component in the SBOM against vulnerability databases (NVD, GitHub Advisory Database, OSV):

A match does not always mean "we are affected": the vulnerable function might never be called at all. VEX (Vulnerability Exploitability eXchange) documents are used to publish this information in a machine-readable form: "this component has CVE-X, but our product is not affected, because …"

Dependency hygiene: a checklist¶

• Pin the versions: keep a lock file (package-lock.json, gradle.lockfile, poetry.lock) in the repository; do not use floating versions such as "latest."
• Verify hashes: Maven/Gradle dependency verification, pip --require-hashes; is the downloaded file the expected file?
• Remove what's unused: every library on the class path is an attack surface (deserialisation chains can also be built from unused libraries).
• Monitor continuously: generate the SBOM on every release, send it to a monitoring platform; know within minutes which products are affected when a new CVE is published.
• Vet the source: pin the package source against name-squatting (typosquatting: e.g. reqeusts) and dependency confusion (an internal package name being hijacked by a fake package in a public registry) attacks.
• Build integrity: the supply-chain incidents and the SLSA framework from Week 2: the build itself must also be provable.

Worked example: reading Demo 6's output line by line¶

Demo 6 (sbom.py) produces small jar files from four synthetic libraries, writes a CycloneDX component for each one, and matches them against a small dictionary of "known vulnerable versions." The actual output (the component names and versions come from a fixed list in the source code):

ad                     surum    SHA-256 (ilk 16)
gunluk-cekirdek        2.14.0   <jar baytlarindan hesaplanir>...
json-arac              2.5.1    <jar baytlarindan hesaplanir>...
kayit-kutuphanesi      1.2.0    <jar baytlarindan hesaplanir>...
sifreleme-yardimci     3.0.4    <jar baytlarindan hesaplanir>...

pkg:maven/ornek.grup/gunluk-cekirdek@2.14.0
pkg:maven/ornek.grup/json-arac@2.5.1
pkg:maven/ornek.grup/kayit-kutuphanesi@1.2.0
pkg:maven/ornek.grup/sifreleme-yardimci@3.0.4

[UYARI] gunluk-cekirdek 2.14.0  (CEN429-2026-0001)
        Bicimli mesajda uzaktan kod calistirma (sentetik ornek).
        Cozum: >= 2.17.1 surumune yukselt.
[UYARI] json-arac 2.5.1  (CEN429-2026-0002)
        Guvensiz seri durumdan cikarma (sentetik ornek).
        Cozum: >= 2.6.0 surumune yukselt.

The SHA-256 values come out different on every run (the generated jar's ZIP metadata contains a timestamp); this is deliberate, and it is a good supply-chain lesson — the hash verifies exactly which byte sequence the file is; "the name and version match" alone is not enough. kayit-kutuphanesi and sifreleme-yardimci are not on the synthetic vulnerability list, so they get no warning — the part of an SBOM that stays empty is also information: it means "these components are not on the known list," not "they are safe."

Demo 6 — Generating an SBOM and matching it against vulnerabilities¶

cd code\week-05\06-sbom
.\demo.ps1

cd code/week-05/06-sbom
sh demo.sh

15. Term project: this week¶

Even if your project is C/C++, two of this week's topics apply directly to your project:

• SBOM: List all of your project's dependencies (libraries, build tools, components downloaded through CMake) in CycloneDX format. If you use vcpkg or Conan, try their SBOM-generation support; if not, write it by hand. Look up every component in the OSV database and add the result to the guide.
• Input-validation table: List every point where your project takes in outside data (a file, the command line, the network, configuration); for each one write the expected format, the length limit, and the function where validation happens.
• If your project contains a file path, a SQL query, or a call to an external program, review it again with this week's patterns (canonicalisation + root, parameterised query, argument list).
• If your project has a scripted or Java component, add the obfuscation requirement and the -keep rules to section S9.

16. Work on your own¶

17. Self-check¶

18. Resources and further reading¶

Course textbook — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Recipe 3.1 (basic input validation), 3.7 (validating file names and paths), 3.10 (preventing cross-site scripting), 3.11 (preventing SQL injection)
• Recipe 1.7–1.8 (safely running external programs)
• Recipe 12.9 (function pointers and indirect calls — concept), 12.11 (obfuscating strings)

Open standards and resources

• SEI CERT Oracle Coding Standard for Java (the IDS, FIO, SER, MSC, ERR rules).
• OWASP: Top 10, SQL Injection Prevention Cheat Sheet, OS Command Injection Defence Cheat Sheet, XML External Entity Prevention Cheat Sheet, Deserialisation Cheat Sheet; MASVS-CODE and MASVS-RESILIENCE.
• Oracle: JEP 290 (deserialisation filters), JEP 415 (context-specific filters); Java Secure Coding Guidelines.
• The ProGuard manual (Guardsquare) and the Android developer documentation: "Shrink, obfuscate, and optimise your app" (R8).
• The CycloneDX 1.5 and SPDX 2.3 (ISO/IEC 5962) specifications; the package-url (purl) specification; the CISA SBOM and VEX documents; the SLSA framework.
• MITRE CWE: CWE-89, CWE-78, CWE-88 (argument injection), CWE-22, CWE-502, CWE-611, CWE-79, CWE-798, CWE-1104 (use of unmaintained third-party components).