Identifying Critical Software Security Flaws – Part 3
This series of articles is focused on application layer vulnerability because it can be exploited to compromise the confidentiality, integrity or availability of resources used by the application and its users. This layer may be difficult to protect so it is important to understand how it could be compromised. It is also very accessible to cyber criminals, so the best way to make the application layer secure is to ensure you develop secure applications.
In this third part of our four-part series of articles about IoT application layer vulnerability we will review:
- Sensitive data exposure
- Missing function level access control
- Cross-site request forgery
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. These errors can result in an attacker obtaining access to sensitive information which can lead to anything from privacy violations to monetary loss or identity 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.
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.
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.
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.
Are you planning an IoT project?
Whether you are planning a new project or want to upgrade your current IoT application, ciqada can help. We offer a complete, fully-integrated internet of things solution that includes device and cloud management, end-to-end security and as well as a dedicated help desk and server management team. Want to learn more? Contact us today.