In our first article in this series, we talked about two key areas of IoT software vulnerability, injection flaws, and broken authentication and session management.
In this article, we will review three additional areas for concern and investigation to ensure a safe IoT application including:
- Cross-site scripting
- Insecure Direct Object References
- Security Misconfiguration
Cross-site scripting -- or XSS -- vulnerabilities are the most widespread web application security flaw and occur when an application is used by an attacker to send a malicious script to an unsuspecting end user. Any application that uses input from a user in the output it generates, typically a page sent to the browser, without properly validating its content is vulnerable to an XSS attack. In this situation, the end user’s browser executes the script because it has no way to know that it came from an untrusted source. The malicious code can access session tokens, cookies, or other sensitive information used by the browser at that site and can even rewrite the entire content of the HTML page.
Cross-site scripting attacks are usually categorized as either stored or reflected. Stored XSS occurs when the malicious code is permanently stored on the target server and the victim retrieves it when it requests stored information from the flawed site, such as from a database, a visitor log, comment field, message forum, etc.
Reflected XSS occurs when the malicious code is reflected off the web server immediately to the user as part of the input request. Reflected attacks are presented to victims by other means, such as via a malicious link in an email message. When the user clicks the link, the malicious script travels to an at-risk web server and reflects the attack back to the victim’s browser, which executes the code because it came from a “trusted” web server.
Protecting a web server application from XSS attacks requires separation of active browser content from untrusted data. This can be done by ensuring that an application validates all parameters, such as headers, query strings, cookies, form and hidden fields, etc., against a precise security policy specification of what is allowed.
Insecure Direct Object References
Insecure direct object reference vulnerabilities occur when unintended direct access to internal implementation objects, such as database records, URLs, or files, are exposed by a web application based on user-supplied input. This is common when applications use the actual name or key of an object when generating web pages. This allows attackers the ability to bypass normal authorization checks to manipulate and compromise these resources by accessing unauthorized data.
Preventing these vulnerabilities requires enforcement of access control policies for protecting each user accessible object. Developers can use indirect reference maps where possible and can avoid revealing private objects to users such as internal URLs, database keys and file names. If direct references must be used, users can be validated to ensure they are authorized to access the information they are attempting to access.
Security misconfiguration vulnerabilities occur if a software component is subject to attack due to insecure configuration settings selected in its built-in security mechanisms. For instance, one may fail to set an important security header on a web server or neglect to disable default platform functionality that could provide an attacker administrative access. A misconfigured setting could occur at any level of the application stack, including the web server, database, application server, framework, or even the custom code.
Preventing these security misconfigurations requires cooperation between developers and system administrators to ensure the entire stack is configured properly. It is important to define an application architecture that provides secure separation between components and a process to deploy new software updates and patches including code libraries. Ensuring security settings in development frameworks and libraries are set to secure values and using the same configuration for development, staging, and production environments can minimize the introduction of misconfigurations.
How can Ciqada help with your next project?
Our ciqada IoT solution uses Veracode AST during the software design process. This allows us to detect and remove vulnerabilities as we add or enhance features within the application. If you would like to learn more about how ciqada and Mars can help you with your next IoT project, please give us a call.