Snap4City: Security and Privacy Assessment

This content has been extracted from the IEEE Access article: 

To assess the security and privacy of the solution, a number of penetration test’s activities have been performed in the period April-July 2019 by professional companies of the sector. During the period, the Snap4City platform had approximately 1200 operative users on the Web Portal, 1.8 million of new data per day, 6 organizations that were operative (Florence, Helsinki, Antwerp, DISIT, Sardegna, and Garda), more than 4500 data ingestion processes executed per day, more than 320 IoT Applications running on the cloud and on IoT Edge Devices, more than 50 processes of Data Analytics, approximately 840 Dashboards of which 200 public, more than 300 MicroApplications of HTML5, 15 IoT Brokers, 5 Mobile Applications connected on Smarty City APIs, with approximately 3500 distinct active users on Mobile Apps daily, etc.

Any detected issues have been analyzed and for each of them a set of counter measurements have been taken to make the platform more robust to external intrusion and attacks. An approach of incremental tests has been chosen to spot the largest number of weaknesses and to enable a progressive evaluation-and-patching process. Each phase has been carried out by different actors such as:

  • first phase: two groups of internal developers and security experts that know very well the Snap4City infrastructure;
  • second phase: two groups of external testers that know nothing about the Snap4City infrastructure and that had very low interaction with the Snap4City developers;
  • third phase: two third-party companies that executed the test without any interaction with the Snap4City developers; one of them has a high-ranking status and reputation on security issues and professionally works in the penetration test field of study.

During the period in which the penetration tests have been performed, an activity of a stress test was also carried out. Even if the focus of the pentest was not about analyzing how the platform responded to a high workload of requests, some feedback on the platform’s performance has been collected to also improve this aspect of the platform and thus resilience on the workload and DoS (denial of service) attacks on APIs.

The penetration tests were performed following the following steps:

  1. Intelligence gathering activities against a target: in this step, information about the target has been acquired using the OSINT (Open Source Intelligence) public accessible sources, and the information was collected using different tools such as: SpiderFoot (, Maltego (, Shodan (
  1. Vulnerabilities detection, verification and analysis: in this step, the target has been analyzed and deeply scanned for the different vulnerabilities using tools such as OWASP ZAP ( ), Pentest-Tools and Burpsuite ( and verified using sqlmap ( and xenotix6 (

For example, the complete crawling of the identified contexts performed via the OWASP ZAP and w3af tools was performed from the point of view of (i) a user not registered and (ii) a logged user. Considering that any external links pointing to services out of the context have been excluded, a list of 73 ANAME records has been identified for a total number of approximately 8500 unique URLs that identified the attack surface where the following deeper analysis was performed.

A detailed set of attacks has been performed on domain and subdomains using the OSWAP ZAP and Arachni ( tools. Even proceeding separately by subdomains, any complete analysis required several hours of computation. An analysis of the false positive alerts has been carried out to highlight just the true risks. For the main domain, 3095 URLs have been identified and a complete attack required more than 750 thousand requests for a total of approximately 39 hours of computation.

     The pentests found some vulnerabilities that have been immediately solved, as described in the following and in particular:

  • few “SQL Injection” vulnerabilities were found by using the OSWAP ZAP, Sqlmap ( and Gobuster ( tools. These problems were found mainly in the Dashboard Builder and management modules. The problems identified were solved adding checks on the API parameters provided in the HTTP GET or POST requests; a specific list of 18 URLs (over a total of 244 URLs with high risk) has been identified and simulated attacks have been carried out manually and solved. The most relevant vulnerabilities were related to SQL injection of malicious code during the editing of information related to Dashboards and to Remote OS commands script injection permitted in a specific form of a User Interface exposed by the platform.
  • a “Broken authentication” vulnerability was found as it was possible to do a password-guessing attack; to prevent this, it is set to not accept a login for 2 minutes after providing 5 wrong passwords.
  • A few “Sensitive Data Exposure” regarding test users and passwords and a test private key present on GitHub were removed and changed; moreover, in some cases, the listing of directories was enabled;
  • one “Broken Access Control” for a possible local file inclusion was found that was present in the CKAN tool used for managing open data. Moreover, in the process of fixing the SQL injection problems, also the potential broken access controls were identified that allowed a user to access data of another user by manipulating the API parameters; in this case, stronger controls were added to prevent this situation;
  • a few “Security Misconfiguration” vulnerabilities were found, and, in particular, were identified as a web server supporting the TLS1.0 and TLS1.1 protocols;
  • some “Cross-Site Scripting” vulnerabilities were found, mainly in the Dashboard Builder and management module. The identified problems were solved escaping the input parameters using html entities when the input is not a html content; otherwise, only the script tag is sanitized;
  • regarding “Using components with known vulnerabilities”, the vulnerable versions of nginx and Apache2 web servers were detected and upgraded; moreover, a vulnerable version of Drupal 7 was found, which was at the basis of the “Snap4City Platform Support Living Lab” module, and it was upgraded to the latest version available.


For the other types of vulnerabilities, as mentioned in Section II.A, such as “XML External Entities (XXE)”, “Insecure Deserialization”, and “Insufficient Logging & Monitoring”, nothing was found.