Thinking about a new web application that could be the next big thing that users flock to? You’re probably paying more attention to the features of this new application rather than one of the most important aspects of it that could send people running for the hills: security, or the lack thereof.
According to OWASP, a list of the top 10 vulnerabilities plaguing websites, the top 10 security vulnerabilities that should be addressed while developing any web application are:
1. Injection –One of the easiest exploits of any website which has become even easier as more automated tools are developed to make the process faster. It occurs when untrusted data is sent to an interpreter. Prevention of such an attack can be made my setting boundaries on the input data to only accept data within those boundaries, a so-called “whitelist” of data. In addition to the whitelist, try to use a parameterized interface and also escape the input data;
2. Cross-Site Scripting (XSS) – The most prevalent web application security flaw, according to OWASP. It occurs when user-supplied data is not escaped and/or validated. While most prevalent, it is also one of the easiest to prevent. Simply escape data and only accept data that is of the correct type, length, name and/or value, a so-called whitelist;
3. Broken Authentication and Session Management – Custom authentication schemes commonly suffer from such vulnerabilities as these because the development of custom authentication schemes is hard and the developer inadvertently doesn’t account for one or more of the common flaws. Prevention of such flaws can be by forcing developers to use a single set of authentication and session management controls;
4. Insecure Direct Object References –A developer might use the key names of database fields in forms on their web application. The attacker changes the name of the form field with a different value that they may not be authenticated for and submits the data. Prevention of such attack can be made by simply adding an abstraction to the fields of the database so that the field names are not known to the attacker;
5. Security Misconfiguration – The entire “stack”—the technologies that, when stacked up, facilitate an application to function—needs to be secure or else other attack vectors can be exploited. For example, a couple of years ago it was found that MySQL databases would allow an attacker to login to a database after 255 tries of the password. Any affected database that was exposed to the internet i.e. not filtered with a firewall, could be directly accessed without the need to go through the web application in order to be exploited. Prevention of such attacks can be made by ensuring that both developers and IT staff collaborate and continuously audit their systems for such flaws;
6. Missing Function Level Access Control –A malicious and authenticated user changes a parameter of the URL and is able to gain access to a function of the website because the developer didn’t check to make sure the user should have access to that function. Prevention of such attack is as simple as make sure that if a function is accessed, the user has the rights to access it;
7. Cross-Site Request Forgery (CSRF) –Allowing data to be sent to a server without also including an unpredictable token value that the server already knows would allow such an attack. A user could go from one website to another, malicious, one where the malicious one would send seemingly authenticated data without the knowledge of the user. Prevention of such an attack is easy. Just set an unpredictable token in the session and have the form submit it as another field. Clear the token on form submission so each new submission has a unique value;
8. Sensitive Data Exposure – One of the more difficult exploits, it typically occurs when the developer uses no data encryption, or weak data encryption, or weak keys and/or weak encryption and hashing algorithms. As technology advances, hashing and encryption algorithms should be used and kept updated to the latest versions;
9. Unvalidated Redirects and Forwards – An attacker can trick a user into clicking on a link that contains an unvalidated parameter, which allows a redirect to a page with higher administrative privileges. Prevention can be not using redirects/forwards; if redirects/forwards are used, then validate the redirect parameters and ensure the user has the appropriate privileges to access the redirected/forwarded page;
10. Using Components with Known Vulnerabilities – Developers may not check to see if components, such as plugins, have known vulnerabilities before using them in a web application. As vulnerabilities are commonly widely published as a means to inform developers, attackers can use the same published data to create attack vectors for web applications. Prevention includes checking public information to see if any components of the web application are vulnerable; Create security tests for the components that scan for common vulnerabilities; Add an abstraction layer to the component to restrict what data can be input and output by it.