A transit application accepts serialized objects from untrusted clients and reconstructs them server-side. What class of risk should the tester emphasize without providing exploit recipes?
Select an answer to reveal the explanation.
Short Explanation
Opening mystery packages from strangers is a bad ops habit. Reconstructing untrusted serialized objects can lead to severe code-execution-class outcomes — call the class, recommend safe patterns, and skip the gadget cookbook. A JSON Content-Type sticker does not magically make unsafe loaders safe.
Full Explanation
Transit applications that accept serialized objects from untrusted clients and reconstruct them server-side raise insecure-deserialization risk: untrusted object graphs can lead to remote code execution-class outcomes depending on language and gadget availability. Prefer safe data formats (strict JSON schemas) and integrity controls; do not treat serialization as a transparent transport.
Serialized traffic does not prove mutual TLS is correctly deployed. Deserialization bugs are not limited to offline batch jobs—web tiers are common victims. Declaring untrusted object graphs harmless solely because Content-Type is application/json misunderstands both JSON and binary serialization dangers.
Exam caveat: discuss classes and safe design; CPTS-style answers avoid exploit recipes or gadget chain walkthroughs.
Operational check: identify endpoints that accept native serialized payloads, confirm whether types are constrained and integrity-checked, and recommend eliminating native untrusted deserialization for rider-facing services. Record residual risk if legacy serializers must remain temporarily. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.