Remediated mark_safe calls to prevent XSS attacks.

[Eric-Butcher]

ColdFront XSS Exploit

Steps to Reproduce

1. Start a ColdFront container with a new database
2. Execute the following commands to get the deployment configured:
   1. Execute initial_setup script
   2. Execute the load_test_data command
   3. Create a new superuser and name it 'changeme'
3. Navigate the the webpage and log in as 'changeme'
4. Go to Admin -> All Allocations -> select the allocation with ID==1
5. Go to Allocation Attributes -> Add Allocation Attribute
   1. Specify an AllocationAttribute type that is included in the setting ALLOCATION_ATTRIBUTE_VIEW_LIST. By default this includes ["slurm_account_name", "freeipa_group", "Cloud Account Name"].
   2. Set the value to <b>This is where the text is.<b> <script>alert("Malicious ! slurm ! Script")</script>.
6. Navigate to Admin -> All Projects -> ID==1
   1. The malicious script should execute.
   2. Refresh the page to demonstrate that it will execute again.
7. Log in as 'cgray' with password 'test1234'.
8. Click on the Project Link for "Angular Momentum in the QGP holography."
   1. The malicious script should execute.
   2. Refresh the page to demonstrate that it will execute again.
9. Click on Project -> User Allocations
   1. The malicious script should execute.
   2. Refresh the page to demonstrate that it will execute again.

How this Happened

The function get_information in coldfront.core.allocation.models uses normal string formatting to create a string from data in the database and then uses the mark_safe function before passing it on. This was done because each string returned from get_information needed to include a <br> element. However, the mark_safe function will make it so that the string is interpreted as a safe HTML string to render, bypassing Django's built-in XSS protections in templates. This leads to the XSS attack when any of the values pulled from th database contain HTML.

In this instance, whenever a value was specified by a user for an AllocationAttribute whose AllocationAttributeType was in the setting ALLOCATION_ATTRIBUTE_VIEW_LIST, that value would be sent to the user as raw HTML. There are calls made to get_information in the HTML files project_detail.html and user_list_allocations.html which are vulnerable to this attack. Since the file user_list_allocations.html uses the get_information with the following templating condition:

<a href="{% url 'allocation-detail' allocation.pk %}">{{ allocation.get_parent_resource.name }} ({{ allocation.get_parent_resource.resource_type.name }})</a>  {% if 'slurm' in allocation.get_information %} -- {{allocation.get_information}} {% else %} <br> {% endif %}

it will only be vulnerable when the string "slurm" is also included in the injection.

There is another call to get_information inside the allocation_request_list.html file but this does not appear to be vulnerable to this attack.