The complete life cycle of data management is rather broad, and in a sequential order I can list them as follows:
- Data collection, because data must be collected before you can think of doing anything else with it.
- Data storage: data must be stored somewhere - most logically in some electronic form (structured database, text form, binary form, etc).
- Data extraction / processing / analysis: to organize and bring out hidden insights from the data.
- Data quality control: to assure quality of the data.
- Information dissemination (reporting, business intelligence, visualization, etc).
Throughout the above processes, it might be important to ensure that your data is secure - in terms of controlling who can have access to the data, and who can do what with the data. You do not want just anyone to have read or write access to highly confidential patient data, bank account data, company financial data, school students data, etc. The list is endless.
If data must be collected and stored in an electronic medium, then we cannot avoid talking about an electronic software application to manage that process ... and more often than not, we could be talking about some web-based system. The moment we talk about a web-based system, then we open ourselves to the opportunities and challenges of the web. One critical challenge of the web is data security.
With multitudes of web-application frameworks abound, it is can be easy for any developer (or possibly anyone) to develop some kind of web-application that is able to collect, store and manage data. If such a system is locally available within an enterprise, and is not public-facing, then data security concerns may be minimal. However, if such a system is accessible via a public interface, then the level of security concern should not be underestimated.
In my experience, not many people are even aware of - or concerned about - the data exposure that web-applications bring about. Just to mention a few, attacks such as the following are too serious and too common to be ignored:
- Cross Site Scripting (XSS), also known as script injection. This is where an attacker injects Javascript of HTML into a vulnerable input field.
- Cross Site Request Forgery (CSRF). According to OWASP, this is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.
- SQL injection. This is where an attacker injects SQL script into a vulnerable input field.
All the above threats have grave potential local or global consequences on a website (or web-application). These are interesting security topics which have often featured in the OWASP Top 10 list. And they are easy to implement by an attacker as long as the system vulnerabilities exist, coupled with security-unaware users. Good understanding of these vulnerabilities would require knowledge of web-development, but end-users simply need to know how to use the internet in a disciplined manner. Until you understand these exploits, you may not be able to appreciate the everyday reality of the risks right at your fingertips.
Ask yourself how many spam emails you have ever received, or continue to receive on a daily basis. Have you ever imagined that such emails could be directly targeting your web-based application, either the application hosted by you, your enterprise, or even that banking application which you simply use as a customer? Depending on what application it is, you could count losses if a hacker decided to exploit that system. Some possible consequences of an attack could be illegal transfer of money from your account, illegal approval of an important transaction, stealing of password, introduction of viruses / malware, etc, etc.
There are two main players who can take control of the situation: the developer(s) of your application and you (the end user). Both of you should be well-versed with the techniques and counter-measures of the attacks listed above (and others). For starters, understanding cross site scripting, cross site request forgery, and SQL injection will put you miles ahead of the game.
A developer should take it upon themselves to design a system that seriously takes into account security vulnerabilities.If you are a developer and you haven't yet understood the security considerations above, then it is good to assume that your system is unsafe. For starters, a developer should take the following basic measures:
- Cross Site Scripting (XSS), also known as script injection:
- sanitize/validate html input (request) before processing, paying more attention if such an input is included in the response (output)
- Cross Site Request Forgery (CSRF)
- use csrf token;
- avoid using GET method for for state-changing requests (this can prevent use of exploit URL, but an attacker can still use Form tags)
- SQL injection
- use parameterized SQL statements or stored procedures;
- avoid using raw SQL queries
For the above measures, it helps if a developer uses a well-tested development Framework with strong security implementations. For instance, in the case of Flask (Python), use of standard libraries such as SQLAlchemy, Jinja, WTForms, etc is recommended. Avoid using older interfaces. If possible, allow a security expert to test your system before deployment.
An end user should exercise discipline while using web-applications and the internet generally because many attacks use social engineering to lure you to do something that triggers an attack. For instance:
- DO NOT open emails and links that you are unsure of. These can be just a bait to lure you to an attack.
- Always log out of sensitive websites e.g. banking website before visiting another website or immediately after performing your transaction (this can prevent CSRF attacks)
Sometime in the future, I hope to pick one of the three threats above and give a detailed account, with examples. Meanwhile, from now on, just know that you are exposed as long a you use some web-application (or the internet for that matter). Good luck and be safe.
