WebTerminal
- 3 Devlogs
- 5 Total hours
This project is just to showcase how unsafe javascript can be used to hack a website
This project is just to showcase how unsafe javascript can be used to hack a website
deciding on making architecture of FS for future use of commands
Devlog 2: Command History & Interactive VFSImplemented a fully functioning command history. No more retyping commands. ArrowUp and ArrowDown now traverse the bash history with proper state resets on Enter, coded completely from scratch But the roadmap is shifting. I’m turning this terminal into a simulated Linux-like Virtual File System (VFS). The plan is to build a mock directory structure where users can run ‘cd’, ‘ls’, and ‘cat’ This won’t just be an aesthetic feature. The goal is to demystify Linux system architecture for beginners. By navigating directories like /etc, /bin, or /var directly in the web terminal, people will learn where critical system files and configurations hide, and how misconfiguring them can compromise a whole system
Devlog 1: started building a lightweight, vanilla JS retro web terminal from scratch (no frameworks, no AI).
But as I was fixing bugs and styling the prompt, I realized something. Why not use my own projects to teach others cybersecurity?
So, I turned my terminal into the first interactive lab for my upcoming project: CyberSecurityLearningLabs In the latest update, I intentionally swapped textContent with innerHTML inside my terminal history function. This opens up a textbook DOM-based XSS vulnerability.
If you type a malicious payload like an img tag with an onerror event directly into the terminal, the browser parses the HTML, fails to load the broken source, and triggers the JavaScript payload (like a classic alert pop-up).
I left a hint in the code comments explaining how to patch it using textContent, making it a perfect, hands-on demonstration of why sanitization matters