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
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
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.

Leave a Reply

Your email address will not be published. Required fields are marked *