0

I recently developed a website that was operational for me ^^

However, someone came to try injections and found an XSS flaw.

I have a form like this:

<h2>
   <span>Search</span>
</h2>

<div class "col-xs-12">
   <input id="in" type="text" name="in" value="" required="" placeholder="value">
</div>

When he enters

"><script>alert(1)</script>

in the form, this changes my HTML like this:

<h2>
   <span>Search</span>
</h2>

<div class "col-xs-12">
   <input id="in" type="text" name="in" value="\">
   <script>alert(1)</script>
   " required placeholder="value">
</div>

And it shows me the famous pop-up with the value 1.

Being a beginner, I can't see how this can be dangerous, since the attacker can only execute his script on his client side, right?

Or he can execute code that allows access to my database?

3
  • Preventing XSS in general is a broad topic - while this site is about more focused questions. Also there is lots of good and easy to find documentation about this, so please study these extensively instead of expecting the complex topic to be addressed by a short answer on this site. Commented Feb 10, 2023 at 9:37
  • Let us continue this discussion in chat. Commented Feb 10, 2023 at 10:59
  • you don't show the back-end or front-end code here. (Javascript for front-end... and whatever you use on the back end...) That's where the vulnerability lies. Commented Jul 10, 2023 at 18:13

2 Answers 2

0

Do any users of your site have additional access to the system using a web browser? When such a user views this kind of content with incorrect or missing encoding, would it be bad if attacker can control his or her browser on that site?

XSS cannot directly attack the server but it can force the current user viewing the content with XSS to act behalf of the attacker. Note that the action the attacker wants to do doesn't need to be on the same page because attacker can execute JavaScript fetch() to fully interact with any page within the same domain. In practice, this means that a single XSS vulnerability within your domain will make the whole domain vulnerable!

Note that XSS is always about incorrectly encoding data resulting in data interpreted as commands. SQL injection attacks, SSRF and many other vulnerabilities are actually exactly the same problem, simply the actual encoding context is different. Some people seem to believe things are different and call encoding for SQL context "escaping" instead but that's exactly the same things as encoding untrusted data in SQL string data context.

0

What XSS does is inject an attacker-chosen script into your webpage. Typically this is done using a link or a page that the attacker controls, which submits the relevant request (in this case, the search request) to your server, and causes the user's browser to load the resulting page (with the injected script); this is called reflected cross site scripting. There are other types as well, but I'll leave them aside for now.

The important thing is, the attacker isn't attacking themselves, but they aren't attacking your server either. The attacker is attacking other users of your site. An injected script can do almost anything on a web page: log keystrokes and passwords, read or even modify data that the user enters or retrieves, submit requests for and exfiltrate any data that the user could access, take actions that appear to be done by the victim user (for example, harassing other users), or destroy data (e.g. delete the victim's account). In some cases it can even be used to create worms, where the injected script tries to spread itself to other users to infect their accounts too.

Now, all of this is only relevant if the site has authenticated users, with limited permissions (e.g. can modify their own account and search their own data, but not other users' accounts or data). XSS allows the attacker to effectively hijack the victim's account, gaining the ability to do everything the victim could do. However, what if there are no accounts, or at least not in any way that matters; no secret data or abilities that are specific to one account?

It turns out that XSS can be a problem even then, because it's malicious script running on your site, and browsers (and users) can't tell the difference between the injected malicious script and the scripts you wrote. As such, XSS can be used to launch attacks that exploit the user's trust in your site. The attacker might target the victim's computer (malicious downloads, dangerous instructions, or an "exploit kit" targeting unpatched browsers), network (HTTP port scans of the local address space to search for vulnerable servers), or the user themselves (financial scams, harvesting credentials to try on other sites, harvesting personal info to attempt identity theft, etc.). XSS can also be used to deface your website, which is sort of like an attack on you / your server; the attacker's script replaces the webpage's content such that the victim sees pornographic ads or Nazi propaganda or obvious scams or whatever, and associates them with the site owner (you).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .