Web Application Security – Is your IoT Product Safe?

2 908.233.0101 ciqada.net

Securing the Internet of Things is a critical step in achieving the growth and success analysts have predicted for the IoT market.

And while it is vital to include end-to-end security in an IoT product, 90 percent of all vulnerabilities exist at the application layer, according to Gartner Security.

An application vulnerability is a flaw or weakness in a software application that can be exploited to compromise the confidentiality, integrity or availability of resources used by the application and its users. The application layer is the most difficult to protect because vulnerabilities may involve complex input scenarios that may be challenging to detect with conventional intrusion detection software.

It is also the most vulnerable because it is the most accessible to cybercriminals. The best defense is to develop secure applications. Therefore, a substantial effort to evaluate and remove vulnerabilities in websites, web applications and web services is essential to reduce security threats and breaches, thereby limiting this barrier to IoT product deployments.

3 908.233.0101 ciqada.net

#1 – Injection

An injection flaw is introduced when malicious code or untrusted data is inserted into an application and passed to another system. This could include calls to backend databases, shell commands to external programs, or through system calls to the operating system. Scripts written in other languages, such as Python or

PERL, can be inserted and executed such that an attacker can read, modify, create or delete data available to an application. The most common injection flaw is SQL injection. However, they can also be found in NoSQL, LDAP, Xpath queries, OS commands, SMTP headers, XML parsers, etc.

Injection flaws can be prevented by carefully validating the data when calling an external function to verify that the data returned is what was expected. In certain situations, encoding the data may be needed to ensure immunity to an injection flaw. Proper handling of errors, timeouts or blockages is also important to confirm that the processing expected occurred.

Identifying Critical Software Security Flaws

In order to design a secure web application, you must know your threats. Knowledge about how attacks occur can guide a developer to build software defenses into their applications. Developers can turn to the Open Web Application Security Project (OWASP) Foundation, a not-for-profit open community organization focused on improving the security of application space software. Their projects cover many aspects of application security; participation is open, and the resulting tools, documents, and guidelines are made available to educate and inform anyone interested in producing secure code. Here are the top ten vulnerabilities identified by OWASP:

4 908.233.0101 ciqada.net

#2 - Broken Authentication and Session Management

Authentication and session management encompasses all aspects of handling user account credentials, including user authentication and active session management. Broken authentication flaws occur when there is an inherent vulnerability in the method chosen to authenticate users. Session management flaws occur when sensitive user information such as user names, passwords, and session tokens are not properly protected. If the session tokens created by web applications are not properly protected, an attacker can assume the identity of a user by hijacking a user’s active session. Developers may build custom authentication and session management schemes which could introduce flaws in areas such as password management, logout, timeouts, account updates, remember me, secret questions, etc.

Recommendations to prevent these types of vulnerabilities include:

• Using a single authentication and native session management mechanisms

• Assigning a new session cookie once a user authenticates and invalidate the previous one

• Verifying that users can easily locate the logout link, including adequate timeouts for inactive sessions

• Verifying users know their old password prior to changing it

• Verifying that all user credentials are stored in hashed form

• Ensuring that SSL is used for all authenticated parts of the application.

5 908.233.0101 ciqada.net

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

6 908.233.0101 ciqada.net

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

7 908.233.0101 ciqada.net

#5 - 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 introduction of misconfigurations.

8 908.233.0101 ciqada.net

#6 - Sensitive Data Exposure

As the name suggests, sensitive data exposure occurs when an application does not sufficiently protect confidential material such as personal information, financial information, information related to healthcare records and user account information. Exposure to sensitive data usually results from unsafe cryptography or lack of proper data protection policies. This can result in an attacker obtaining access to sensitive information which can lead to anything from privacy violations to monetary loss or identify theft.

It is a good first step to clearly define what data is considered sensitive when designing an application and then employing best practices to ensure it is protected. The best way to protect sensitive data is through encryption. Using cryptography methods with strong standard algorithms and strong key generation and management is critical.

And data must be encrypted not just while it is stored in the database and on the server, but throughout its path – while it is in transit over private or public networks and while it is displayed to users and used by an application. Using HTTPS for data communication and SSL or TLS encryption on pages displaying data is essential. Providing the same level of encryption protection for backup data is important.

In addition, data should be stored only as long as needed, and then discarded. These are the highlights to avoid sensitive data exposure; however, detailed security recommendations for programmers have been published and are continually updated on this topic.

9 908.233.0101 ciqada.net

#7 - Missing Function Level Access Control

A missing function level access control flaw occurs when unauthorized users are able to access functionality not intended for them. This happens when user authentication checks in sensitive request handlers are insufficient. This flaw is similar to the fourth entry on our list – insecure direct object references flaw.

The distinction here is that this refers specifically to access of unintended functionality in a web application while the insecure direct object references flaw refers to unintended access to data.

This vulnerability exists, for instance, if a user is able to spoof a URL to gain access to functionality not intended for them based on a URL he is permitted to access. Or, perhaps an unauthorized user could view the HTML and JavaScript code of a webpage to see how a function call is made. This flaw typically occurs if the web application isn’t configured for proper function level protection or doesn’t include the proper code checks to ensure functionality is provided only to those users who have been authorized for such capability.

The same prevention techniques discussed for the insecure direct object reference flaw regarding data access can be applied to a missing function level access control flaw regarding functionality access. In general, a deny-by-default approach is the best starting point to disallow access to all functions and then white-listing them as appropriate. Blocking file types that should not be available can prevent an attacker from getting access to forgotten databases, log files, or configuration files that were mistakenly exposed without authorization. Checking every URL, button, and all ways to access functions to make sure all user levels have access only to those functions needed is also important.

10 908.233.0101 ciqada.net

#8 - Cross-Site Request Forgery

A cross-site request forgery vulnerability allows an attacker to exploit a valid authenticated session in a user’s browser to make requests to perform an undesired function on his behalf. This occurs, for instance, if a user logs into a secure web application and then visits other sites while the connection to the secure application is still valid.

In this situation, the attacker embeds malicious commands in the third-party web pages visited which are then sent to the secure web application. A cross-site request forgery attack results in an end client-side action generated by the attacker, such as posting a forged comment to a social media site or changing a user’s email address or password. This is more likely to occur for web applications that have users who are always online, such as social networking sites, or email providers.

To prevent a cross-site request forgery vulnerability, a random token that is unique to each user session could be incorporated which would allow the web application to validate a command is from an authenticated user. Another common approach is to require that all user requests require re-authorization. For example, a customary practice is to require a user to enter their current password in order to change their password even though they are currently authenticated. Other approaches for re-authentication could be a randomly selected CAPTCHA, a one-time token sent to a trusted device, or a PIN code that only the user should know. Re-authentication may be impractical for all user functions which is why the random token approach is more ubiquitous. Some systems take a combined approach, implementing a token protection system and using re-authorization for a few chosen functions.

11 908.233.0101 ciqada.net

#9 - Using Components with Known Vulnerabilities

This category of vulnerability is quite common because most application developers make use of frameworks, modules and components combined with their own custom code to deliver the final web application. However, when incorporating external software

components and libraries, whether commercially available or free open source, the web application is vulnerable to any known vulnerabilities within these components. These components could be the operating system itself, the web server, a plugin, a library or any other popular third party software used within the application. These vulnerabilities are particularly dangerous because attackers are able to exploit a large number of web applications once one has been discovered in a software component, and it may also provide access to other secure code and data within the application.

Of course, the obvious option to prevent this vulnerability from occurring is to write all custom code and not to incorporate third party software components. This approach, however, isn’t practical when developing web applications. The next best and most important prevention method is to keep all software framework, module, and component versions up to date. Ensuring the software is up to date minimizes the likelihood of a known vulnerability within the software components uses as vulnerability fixes are releases as subsequent releases or sometimes as patches. A structured approach for software developers to identify all third party components, their versions, and all dependencies and to monitor the security of these components is advisable. It is also recommended to add security wrappers around external components allowing you to control what goes in and what comes out of these components and allows you to disable unused functionality. Removing any paths and references to third party components is also advisable as it shelters the web application from attackers by not revealing the external components used.

12 908.233.0101 ciqada.net

#10 - Unvalidated Redirects and Forwards

An unvalidated redirect or forward vulnerability exists if a user clicks a link on a trusted website and is redirected to an untrusted site. Redirects and forwards are frequently used in web applications either in the user authentication process itself or as new pages replace older pages. If untrusted data can be used to determine the destination page, an attacker can use this unverified redirect or forward to access unauthorized pages or to redirect victims to phishing or malware sites.

The obvious approach to prevent an unvalidated redirect or forward is to not use them in your web application. However, if you must use them, it is recommended that user parameters aren’t used in determining the destination. If user input is required, then it is advisable to ensure the supplied value is valid and authorized by the user or by incorporate a dictionary to map values to valid pages rather than using the actual URL information in the user parameter. Creating a whitelist of valid URLs is also helpful. Adding an extra layer of authorization by sending all external redirects initially to a page which requires the user to choose whether or not to visit the site can reduce exploits as well.

Finding and mitigating security flaws with Application Security Testing

Ensuring that web applications are free from these known flaws is an important first step in providing secure web applications. These issues and many more errors can be identified prior to deploying an application using Application Security Testing (AST) products and services. These tools analyze and test applications for vulnerabilities and identify their findings according to the industry standard categories defined by the OWASP.

Static analysis examines software without actually executing it. The control and data flow of the code is modeled and then analyzed by scanning the model with patterns associated with security flaws. Static analysis tools detect a large percentage of known security and, because it is not dependent on the application running, it can be used early and often during the software development cycle to ensure secure design practices are being employed.

Some types of security flaws, however, are difficult to find using automated static analysis. For these flaws, dynamic analysis is employed. Dynamic analysis is performed on the application while running in its production environment. Dynamic analysis detects flaws by sending a series of requests to a web application and examining the responses received. It is essentially mimicking the types of attacks that could occur to the web application.

13 908.233.0101 ciqada.net

#10 - Unvalidated Redirects and Forwards-continued

Seven of the of these ten vulnerabilities can be discovered using either static or dynamic analysis: 1 – Injection, 2 – Broken Authentication and Session Management, 3 – Cross-Site Scripting, 4 – Insecure Direct Object References, 5 – Security Misconfiguration, 6 – Sensitive Data Exposure, and 10 – Unvalidated Redirects and Forwards.

Two can be uncovered only by static analysis: 7 – Missing Function Level Access Control, and 9 – Using Components with Known Vulnerabilities. And one can be uncovered only by dynamic analysis: 8 – Cross-site request forgery.

Using a multi-faceted approach to include both static and dynamic analysis methods provides a more comprehensive risk assessment of the application.

Ciqada® Application Security Testing

When designing our ciqada® Internet of Things web application, we incorporated security analysis and testing into our development process with the Application Security Testing services provided by Veracode. Using a third-party validation service such as Veracode, selected as a “leader” by Gartner in their Magic Quadrant Security Report, we have ensured our product meets the application layer security standards set by the security industry.

With Veracode AST as an integral part of our software design process, we detect, evaluate, and remove vulnerabilities as new features and enhancements are rolled out giving us continued confidence in the security of our ciqada® cloud application. While ciqada integrates an end-to-end approach to security, it is reassuring to know that we have tackled the most vulnerable layer, the application layer, thereby providing a cloud platform that withstands the scrutiny of software security experts.

Attacks targeting IoT applications are, unfortunately, inevitable. Nevertheless, you can safeguard your product from known threats by using secure design guidelines and incorporating application security analysis within your development process. Together, we can meet the demands of the IoT community and reach the full potential of the market by taking this crucial step to securing the IoT.

Let Your Products Take Flight

908-233-0101 ciqada.net