Clarification: 1.5.2 "insecure"
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 3.6k
- Forks
- 831
- Avg merge
- 7h 55m
- Merged PRs (30d)
- 4
Description
Verify that deserialization of untrusted data enforces safe input handling,
such as using an allowlist of object types or restricting client‑defined object
types, to prevent deserialization attacks. Deserialization mechanisms that
are explicitly defined as insecure must not be used with untrusted input.
Attackers can abuse "gadget chains" of already-allowed classes. A simple allowlist might not be enough.
what is "insecure" in ASVS context? As per me to identifying insecure requires continuous security research and knowledge, which is not possible easily.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the raw Markdown requirement for 1.5.2 in the ASVS 5.0 tree and reviewing the existing issue comments. Research what “insecure” means in this deserialization context, including the gadget-chain concern, then clarify the requirement so its intended scope and completion criteria are unambiguous.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation, security
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100