Replace iframes on Web Application #914

Activity

1. github-project-automation

   added this to Security Shepherdon Aug 28, 2026
2. github-project-automation

   moved this to Backlog in Security Shepherdon Aug 28, 2026
3. SeanDuggan

   added

   Enhancement

   Platform

   Help Wanted

   on Aug 28, 2026
4. SeanDuggan

   added the

   Feature

   issue type on Aug 28, 2026
5. abhinav-phi commented on Aug 29, 2026

   

   abhinav-phi

   on Aug 29, 2026

   More actions

   Hi! I'd like to work on this.
   Plan: I'll replace the iframe usage on the web application page with a modern, safer embedding approach, and verify the UI still works across the affected pages.
   Could you please assign this to me? Thanks!

   /assign
   take
6. SeanDuggan

   assigned

   abhinav-phi

   on Sep 2, 2026
7. abhinav-phi commented on Sep 2, 2026

   

   abhinav-phi

   on Sep 2, 2026

   More actions

   Thanks.. I am on it 👍
8. abhinav-phi commented on Sep 17, 2026

   

   abhinav-phi

   on Sep 17, 2026

   Last edited by abhinav-phi

   More actions

   I reviewed the current iframe-based module-loading flow before making changes. The lesson and challenge pages are complete HTML documents with their own scripts, stylesheets, and document-relative URLs, while result submission and cheat-sheet controls remain in the dashboard. The existing getModule request also performs session and CSRF validation, module-access checks, and CTF countdown checks before returning the module address.

   A direct-navigation replacement would take users away from the dashboard controls. Injecting the existing documents into the dashboard would introduce duplicate element IDs and change how relative asset and request URLs resolve. Neither is a functionality-preserving replacement without additional work on the page structure.

   Could you confirm whether converting the module pages into dashboard-compatible fragments is within the intended scope? My recommendation is to preserve the dashboard and its submission workflow, rather than remove those controls as a side effect of replacing the frames. The intentionally sandboxed CSRF-forum frames would remain unchanged.

   No implementation or runtime validation is complete, and I have not opened a PR. The local Docker engine was unavailable and Maven was not on PATH during the environment check. This update is an AI-assisted source-level assessment, not a claim that a replacement has been tested.
9. abhinav-phi commented on Sep 17, 2026

   

   abhinav-phi

   on Sep 17, 2026

   Last edited by abhinav-phi

   More actions

   Hi, thank you for assigning this to me.

   I have kept same-origin frames for the lesson and challenge views, because those pages are full documents with their own scripts and relative paths while result submission stays in the dashboard. Replacing the frames with direct navigation would remove those controls, so a bounded modernization is the right scope here.

   What I changed: frame creation now uses DOM APIs instead of deprecated frameborder string injection, and every frame carries a title, lazy loading, a same-origin referrer policy, and a sandbox that blocks top-level navigation while preserving the scripts, forms, modals, popups, and downloads the training content relies on. I also added same-origin source validation for the getModule response and fixed the welcome-frame handling in getStarted.jsp, which was clearing its own frame.

   The PR is ready for review here: #920

   Two honest limitations: a full Docker runtime check and the Maven test suite are still pending in my environment, so I would appreciate confirmation that keeping sandboxed frames matches the intended scope for this issue. Thanks.