Addressing Potential JavaScript Injection Vulnerabilities

Question

I am working on a project involving an input form where customers enter their name and email to start a conversation with support. The form works well, but I've noticed some issues with the 'Name' input field. Specifically, I can use developer tools to modify the number of characters allowed in this field and insert JavaScript code, such as element.value="<script>alert('test');</script>".

When I enter this code as the username and an email address, I can start a chat with the name element.value="<script>alert('test');</script>", and everything functions correctly—I can send and receive messages without any issues. However, when I check the database, I see that the user's name is stored exactly as entered, including the JavaScript code.

My concerns are as follows:

Database Vulnerability: Is it a potential vulnerability that JavaScript code can be injected into the MySQL database through the name field? Could this be exploited to inject a large amount of JavaScript code into the database?

Execution of JavaScript Code: When generating statistical reports (since this is a call center server), the JavaScript code in the customer name gets executed, causing an alert window to appear on my screen. Can querying the database trigger the execution of this code? Does this indicate a vulnerability?

Any help or guidance on addressing these issues would be greatly appreciated.

Answer 1

an alert window to appear on my screen ... Does this indicate a vulnerability?

Yes. The tool that creates the reports should display the name as-is without executing JavaScript. Executing the JavaScript makes it possible for an attacker to run malicious JavaScript in the context of the application, and basically perform any action the current user can do. This vulnerability is called cross-site scripting or XSS, which is a confusing name for being able to execute JavaScript where you shouldn't.

Is it a potential vulnerability that JavaScript code can be injected into the MySQL database through the name field?

No. Storing or retrieving JavaScript in a database does not execute it. It's just textual data for the database. Storing any kind of data, including JavaScript or HTML, in a database is not a vulnerability.

The correct way to solve XSS is to do output encoding, preferably automated using a template engine. Additionally, some people do input validation to restrict what data can be entered. For example, you can argue that an equals sign = should never occur in a person's name, and that you should block names that contain it. This does provide additional defense, but does not solve the underlying problem, and can cause problems for people with unusual names. Allowing all valid input while disallowing any invalid input is often hard to accomplish.

Answer 2

In addition to @sjoerd's great answer and inspired by it, I propose to always use the concept of privilege dropping:

Within this concept, the main application's task is to start subprocesses for every occuring task with only the privileges which the current task really needs.

In this way, a security bug within a subprocess is often not as bad as within a monolithic application, if the subprocess has lower privileges -- in this way the attacker which got control over a subprocess may e. g. not be allowed to change the database, if the subtask is only allowed to read the database.