# How I Discovered and Reported a Vulnerability in TU FOHSS System ## **Introduction** In today’s digital-first world, even universities rely heavily on web systems to manage student data. But with that convenience comes risk. As a student and aspiring security researcher, I experienced this firsthand when I uncovered a vulnerability in the **Tribhuvan University Faculty of Humanities and Social Sciences (FOHSS)** entrance portal. What started as curiosity turned into a lesson in ethical hacking, responsible disclosure, and the importance of securing sensitive data. ## **Background of TU FOHSS Portal** Tribhuvan University (TU) is Nepal’s largest and most influential educational institution. The FOHSS entrance system portal is designed to streamline application and student management processes. While this system is meant to improve efficiency, it also holds thousands of students’ sensitive information making security a top priority. I was exploring this portal not as an attacker, but as a curious student eager to understand how real-world systems work. That curiosity led me to an eye-opening discovery. ## **Discovery of the Issue** While navigating the portal, I noticed something unusual. The **profile page URLs** contained numerical user IDs. For instance: ```plaintext https://studentportal.tufohss.edu.np/profile/documents/123 ``` Changing the number at the end (`123` → `124`, `125`) displayed another student’s details. This meant that **anyone logged in could view information of other students by simply modifying the ID in the URL**. This was a textbook example of an **Insecure Direct Object Reference (IDOR)** vulnerability. ## **Technical Breakdown: What is IDOR?** An **Insecure Direct Object Reference (IDOR)** occurs when a web application exposes internal identifiers (like database IDs) directly in URLs without proper authorization checks. For example: * `/profile/documents/123` → My profile * `/profile/documents/124` → Someone else’s profile Since there were no restrictions, the portal didn’t verify whether the logged-in user actually owned the requested profile. According to the **OWASP Top 10**, IDOR is one of the most common and dangerous vulnerabilities because it directly exposes sensitive data. ## **Real-World Impact of the Vulnerability** The impact of such a flaw could have been severe: * **Exposure of personal details** such as names, contact info, or academic data. * **Privacy violations** affecting thousands of students. * **Risk of identity theft or fraud.** * Loss of **trust** in the institution’s digital infrastructure. ## **Responsible Disclosure** I chose to act ethically. Instead of exploiting the vulnerability, I reported it responsibly. * I found the issue on 31st August * First, I informed **Mr. Raju Poudel**, Director of BCA at **Mechi Multiple Campus**, Jhapa on 31st August 2025 and then he crosschecked the issue found it to be valid bug. * He escalated the matter directly to the **Dean’s Office of FOHSS** on the day same 31st August 2025 This step was crucial. By collaborating with the right people, I ensured the issue was addressed without misuse. ## **Quick Resolution** To my surprise, the FOHSS technical team acted swiftly. Within just **24 hours**, they patched the issue, secured the portal, and prevented unauthorized data access. **Before the fix:** ```plaintext https://entrance.tufohss.edu.np/profile/documents/123 ``` The numeric ID (`123`) represented a specific student’s profile. By changing this number, anyone could access another student’s data — the core of the vulnerability. **After the fix:** ```plaintext https://entrance.tufohss.edu.np/profile/documents ``` Now, the system only loads the **currently logged-in user’s profile**, without exposing any numeric ID in the URL. Even if someone tries to modify the address, it will no longer show another student’s details. This shift from **ID-based access** to **session-based access** ensured that data remained private and secure for every student. ## **Lessons Learned** This experience gave me several takeaways: * Always validate **access controls** in applications. * Regular **security audits and penetration testing** are a must. * Reporting vulnerabilities ethically strengthens trust between developers and researchers. ## **Preventing IDOR in Web Applications** For developers, here are some best practices to prevent IDOR vulnerabilities: * **Enforce authorization checks** before serving user-specific data. * Use **session-based identifiers** rather than exposing raw database IDs. * Conduct **regular penetration testing** and code reviews. * Implement **logging and monitoring** to detect suspicious activity. ## **Broader Cybersecurity Perspective** Educational institutions are prime targets for cyber risks because they manage sensitive personal and academic data. As students, we must learn that cybersecurity isn’t just for “hackers” — it’s a shared responsibility. By learning ethical hacking, students can contribute positively by identifying flaws before malicious actors exploit them. ## **Personal Reflection** For me, this wasn’t just about finding a bug. It was about realizing the **power of ethical skills**. As a **BCA student, developer, and security researcher, SEO professional**, this incident tied together my interest in technology, problem-solving, and digital responsibility. ## **Final Thoughts** Cybersecurity is a **shared responsibility**. If we, as students and professionals, use our skills responsibly, we can make digital spaces safer. My experience with TU FOHSS was proof that even small actions — like reporting a vulnerability can have a big impact. ## **Conclusion** The vulnerability I found was a wake-up call: even trusted institutions can have flaws. But with ethical reporting and proactive fixes, we can protect sensitive data and build stronger, safer systems. This journey reaffirmed my belief in using my skills to make the internet a better, more secure place. ## **FAQs** **1\. What is IDOR in simple terms?** IDOR means accessing data you shouldn’t, just by changing a number or ID in the URL. **2\. How can students learn ethical hacking?** Students can start with free resources like OWASP, TryHackMe, and HackTheBox, while practicing responsibly. **3\. Why should vulnerabilities be reported responsibly?** Responsible disclosure ensures the issue is fixed without being misused, protecting both users and institutions. **4\. Are educational portals usually secure?** Not always. Many educational sites lack regular security audits, making them prone to vulnerabilities. **5\. What’s the role of students in improving cybersecurity?** Students can report issues ethically, raise awareness, and encourage secure development practices in institutions. ✍️ *Written by* [*Abiral Acharya*](http://aviralacharya.com.np) *— Security Researcher, SEO Consultant from Nepal, BCA Student at Mechi Multiple Campus*