
JavaSecLab is a Spring Boot-based intentionally vulnerable Java platform pairing vulnerable and fixed code with source/sink audit notes for authorized training and SAST/IAST tool evaluation.
| Tool | whgojp/JavaSecLab — comprehensive intentionally vulnerable Java lab for security learning, code audit practice, and tool evaluation |
| Category | Vulnerability lab / secure development training platform |
| Primary Use | Learning Java vulnerability classes from paired vulnerable/fixed code, practicing source-to-sink audit flows, and benchmarking SAST/DAST/IAST/SCA tools in a lab |
| Safe Use | For authorized security training, internal secure-development programs, and defensive tool evaluation only; must be deployed in isolated lab environments, never on public networks |
| Telemetry Note | The lab documents traffic-analysis examples (e.g., latency patterns in time-based SQL injection) so defenders can study how vulnerable request/response behavior appears; deployments are intentionally insecure and must stay contained |
JavaSecLab is a deliberately vulnerable Java application built on Spring Boot, designed as a teaching and evaluation platform rather than an attack tool. Version 1.5 at the time of writing, the project ships vulnerable code alongside fixed implementations, realistic attack scenarios, audit-oriented source and sink annotations, remediation guidance, and traffic-analysis examples. The stated goal is refreshingly pragmatic: users should understand not only how a vulnerability manifests at runtime, but why it exists in the code and how to fix it properly. With 881 stars and an Apache-2.0 license, it is an active, community-oriented project with a bilingual README, a default branch named i18n-bilingual, and a WeChat community around it.
The README frames four distinct audiences. Security service teams can use the lab to explain vulnerability causes, exploitation paths, fixes, audit flows, and traffic patterns to clients. Enterprise security teams get a vehicle for SDL, DevSecOps, and secure development training. Security researchers can use it as a testbed for SAST, DAST, IAST, RASP, SCA, and reachability-analysis tooling. Java developers, finally, can study real vulnerable code rather than abstract OWASP-style checklists. That breadth is unusual: most vulnerability labs target either pentester training or tool benchmarking, while JavaSecLab explicitly serves both.
The vulnerability module coverage is extensive and clearly organized. Classical web flaws include XSS, CSRF, CORS misconfiguration, JSONP, URL redirection, XFF spoofing, denial of service, and XPath injection, alongside injection and execution classes such as SQL injection, arbitrary file read/upload/download/delete, SSRF, XXE, and RCE. Business-logic scenarios cover IDOR, captcha security, payment security, and concurrency flaws, plus sensitive information disclosure, login confrontation, request signing, and JWT credential security. Language-level and framework-level injection is represented by SpEL injection, SSTI, and Java deserialization.
What distinguishes the project for professional audiences is its component-ecosystem depth. Dedicated scenarios exist for Fastjson, Jackson, XStream, Log4j2, Shiro, SnakeYAML, and XMLDecoder — the exact dependency chain where real-world Java incidents concentrate. There are also Spring Boot ecosystem exposure cases covering Swagger, Actuator, Druid, and MySQL JDBC deserialization. This matters because auditors rarely face clean textbook flaws; they face gadget chains and misconfigured framework endpoints buried in dependency trees.
The author's rationale section is one of the more insightful parts of the README. Drawing on enterprise security experience, the author describes the post-assessment workflow where findings are assigned to developers through ticketing systems like TAPD or Jira, and two questions recur: why is this behavior a vulnerability, and how should it be fixed? JavaSecLab was built to close that communication gap by connecting observable vulnerability behavior, the vulnerable code, remediation patterns, and audit reasoning in a single artifact. It is essentially a translation layer between penetration-test reports and engineering fixes.
For code auditors specifically, the design follows the classic sink-first methodology. The README explains that an auditor typically locates a dangerous sink — command execution, SQL execution, file access, template rendering, deserialization, or response output — and then traces backward to the corresponding source such as request parameters, headers, cookies, uploaded files, serialized data, or database content. Many JavaSecLab scenarios are explicitly structured around this source-to-sink path, which makes them equally useful for training humans and verifying whether automated taint-analysis tools actually find the flow. The project also provides multiple trigger paths for core vulnerability classes, so users can compare how different coding patterns, framework features, and business flows change the risk picture.
The traffic-analysis component deserves its own mention. JavaSecLab ships request/response captures that correlate observable wire behavior with code execution, and the README gives a concrete pedagogical example: in a time-based SQL injection scenario, the vulnerable server responds after roughly five seconds, making the injection observable through response latency alone. This is exactly the kind of evidence a SOC analyst or WAF engineer needs to recognize, and pairing it with the code makes the lesson stick. The project actively solicits better packets and reproduction notes as contributions.
The tech stack is standard enterprise Java: Spring Boot, Spring Security, MyBatis/MyBatis-Plus, JPA/Hibernate, Thymeleaf, Layui, and MySQL. Deployment is documented for both IDEA-based local runs (JDK 8, MySQL 8.0+, Maven, importing sql/JavaSecLab.sql, and configuring application-dev.yml) and Docker Compose, either from the published image via docker compose -f docker-compose.image.yml up -d or built locally with mvn clean package -DskipTests followed by docker compose -p javaseclab up -d. The default account is admin/admin, and the author also maintains a public demo, though any serious use should be a self-hosted, isolated instance.
The security notice is blunt and should be taken literally: the application intentionally keeps dangerous endpoints, vulnerable dependencies, and insecure configurations for reproduction and teaching. The README warns against deploying it on public networks, recommends disposable accounts, test databases, and isolated containers, advises against mounting sensitive host directories into the container, and suggests treating uploaded files, generated files, and logs as untrusted data. Anyone running this in a shared cloud environment without network isolation is asking for the lab to become an actual incident. The author also cautions that the bundled secure-code examples are teaching aids, not production templates — real systems need authentication, rate limiting, dependency governance, monitoring, and defense in depth.
From a defender's perspective, JavaSecLab has a quiet secondary value as a calibration target. Standing it up in a lab and pointing your SAST engine, SCA scanner, or IAST agent at it yields an immediate picture of detection coverage across the Java ecosystem's most-abused components, with ground truth available in the paired fixed code. Blue teams building detection content can use the documented traffic patterns to validate rules, and training teams get ready-made curriculum material spanning both technical and business-logic flaws.
Contribution guidelines reinforce the project's quality bar: new scenarios must include clear vulnerable and fixed code, source/sink notes should be accurate, traffic captures should be analyzable, and UI improvements that make the lab easier to teach with are welcomed. The wiki hosts a deployment guide and a changelog, and the author maintains an active blog and community channels. The repo is a genuine bilingual effort with an English README mirroring the Chinese original, which broadens its usefulness for Western security teams considerably.
In short, whgojp/JavaSecLab occupies a specific and useful niche: it is not a scanner, not an exploitation framework, but a structured corpus of Java vulnerability knowledge rendered as runnable code. For teams that need to answer the two questions every assessment generates — why is this a vulnerability and how do I fix it — it provides concrete, code-level answers across the Java ecosystem's most relevant flaw classes. Run it isolated, treat it as the educational instrument it is, and it earns its place in any secure-development or tool-evaluation program.
whgojp/JavaSecLab.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.