1

I was looking at the answer here and got curious if a function I use may be susceptible to XSS. Mostly because of this statement:

Some HTML attributes are inherently dangerous. This includes href, since you can do something like javascript:alert("XSS");. Since you make sure the value will always start with http you should be fine, though. Other examples of dangerous attributes are style and JS event handlers.

In my function you will see that the form action url and the input value are both set using jQuery.

$("#test").on("click", function(){
    let id = $(this).data("id");
    let url = 'test.php';
    
    let form = $('<form method="POST">').attr({"action":url, "target":"_blank"});
    let input = $('<input type="text" name="id">').val(id);
    
    $('#page').append(form.append(input));

    form.submit();
});

I am setting the input value to the value of a data attribute and setting my form action url. Is this susceptible to XSS?

Edit:

To explain some on where id is coming from, it is coming from a row that has data-id as one of its attributes. When a user clicks on this row, the function is triggered. This id could be altered by using the Inspect tool in browser.

1 Answers1

1

You definitely don't have to worry about setting the action on your form.

This is because it isn't being set from user input. The issue isn't setting it, but setting it based on user input and therefore potentially setting it to a dangerous value. If you control what it is set to then an attacker can't inject anything, and therefore there is no avenue for XSS.

Also, I'm not sure if the form action has the same potential issues as a link href does. I've never tried setting something like <form action="javascript:alert(1)"> but I'm 95% sure that it won't work.

The way you set the input value is fine too

It is unclear if the value you are setting the input to is controllable by a user (and therefore an XSS vector). It depends on where the id data in this comes from, and whether or not it comes from a user. However it shouldn't matter. You can still set values safely, even when they contain user input, by using the proper JavaScript methods. As a slightly different example this is perfectly safe:

element.text = [USER_INPUT];

While this is not:

element.innerHTML = [USER_INPUT];

In the case of the former, you are explicitly telling Javascript that you want to take some data and set it as the "text" for element. As a result the browser will treat your content as plain text - never JavaScript. The latter tells the browser that you want to take the input and treat it as HTML. Since HTML can contain JavaScript, this would be an XSS vector.

In your case you are using the val method in jQuery. Whether or not this is safe from XSS depends on the underlying method jQuery uses to set the input value. I haven't looked in a while, but I'm 95% sure that jQuery just sets the input.val property. Doing this is safe, and can't trigger any JavaScript, so you're fine even if id contains user input.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • To explain some on where `id` is coming from, it is coming from a row that has `data-id` as one of its attributes. When a user clicks on this row, the function is triggered. This `id` *could* be altered by using the Inspect tool in browser. – Newb 4 You BB Aug 13 '20 at 19:04
  • 1
    @Newb4YouBB an exploit that requires altering data via the inspect tool doesn't count as XSS, because a user can only do this to themselves. Naturally, a user can do whatever they want to their own connection *anyway*. They wouldn't have to inject data with the console - they could just grab their own credentials and make arbitrary HTTP requests to your server. – Conor Mancone Aug 13 '20 at 19:20
  • `
    ` is a functioning XSS.
    – hogarth45 Aug 17 '21 at 14:17