There are a lot of ways that put websites and web app security at critical; however, the scale of threat varies as does the difficulty in hacking.
Imagine if it can be as serious as leaking of valuable information or personal images for a common user, how severe can it be for companies who protect the valuable data of millions of users; even large corporates or software service providers. It is way beyond one can imagine!
For hacked users, they take the extra precaution of changing passwords or using more secured firewalls; yet there’s no guarantee that they won’t face a similar calamity again. Hence arises the question, what security measures to take which can avert such breaches in the future?
Ever thought where lies the credibility of the websites who promise uncompromised security to their clients, when they cannot protect their own? The focus should be on finding loopholes in the application’s security during building it; rather than pondering over how to strengthen the firewall when the fortress has already been breached.
The amusing part of the story is that these bugs are usually critical mistakes by the developers. There lay so many cases of website hacking in front of us that make you question the immunity of sharing and/or storing data on the Internet and clouds. Some pretty recent incidents which have made headlines and become topics of big discussions have raised these security concerns.
Recently after attending a seminar with the OWASP team, I realized that although we think we are following the best Quality Assurance methods yet there are ambiguities overlooked on our part as developers and lead to disasters for the client at a later stage. It is time we hand down the necessity of best practices that are going unnoticed in most cases.
The below-mentioned list of vulnerabilities is the most common impact of coding carelessness, by the hands of developers. The list is long hence we will be covering a few critical ones here.
When the control plane data is injected into the user-controlled data plane thus modifying the control flow of the process; it results in the disclosure of useful and data-sensitive information. Injection issues occur mostly due to logic errors, caused either due to lack of knowledge or the habit of doing smart work when cautiousness is required. Amongst other threats caused due to injection problem, there is a lot of data, jeopardized authentication and loss of data integrity. It is broadly classified under these three categories:
Improper validation of data is the main cause of code injection; a code is inserted into the application which is later executed by it leading to loss of availability and/or accountability. Inaccuracy when validating data formats or the extent of predictable data leaves the gap for the hackers to tamper and use code injections.
Amongst the varied types of code injection, I have pointed out the major two here:
The commonest injection in ASP and PHP, an SQL query is injected through the input data from the client to the application. An SQL injection can affect the performance of predefined SQL commands. It can lead to destroying data or making it unavailable; the hacker can even become the administrator of the database server.
The hacker inserts their own content into the page using valid HTML values, often parameterized. The attacker creates a malignant content along with HTML codes and sends it to the user. The receiver takes it to be coming from a trusted source and clicks on it. As soon as the user fills in his username and password it reaches the hacker, thus causing a huge loss to the former.
Inserting the command injection in the host application is possible when the latter is passing unsafe cookies to a system shell. The motive of the hacker usually is implementing random commands on the operating system of the host. Although the hacker is unable to add his own code as is the case with code injection however, it points out that your application is vulnerable.
For developers who often prefer to create their own session tokens; although most application development environment has the session capability; it turns out to be riskier. If your session identifiers and authentication credentials have not been protected with Secure Sockets Layer (SSL), from defects like cross-site scripting (elaborated below), the hacker can easily break-in into a running session posing as a user.
CSRF or Cross-Site Request Forgery makes the user execute undesired actions on a web application with the aid of social engineerings, such as sending malicious links via mail or chat. This must-have happened with many of you, here I will explain the reason why it happens even when you take the precaution of using a secret cookie.
In general cross-site scripting happens when a hacker sends malicious codes or links to the end-user, usually in the form of a browser side script. XSS can lead to some major issues like disclosing the data in secured files; sending out malicious links from the account of the end-user ultimately compromising the whole account; inserting viruses into the database etc.
Even your secure cookies will not be helpful in this regard since XSS code will have access to all your details, the only way is to perform a security review of the code.
As goes the saying a stitch in time saves time, I would like to put forward these easy to adopt security tools and ethics for my fellow developers:
Using secured HTTP headers is one of the best practices for making safe your connections to the server. Applying headers in the web server configuration such as Apache, Nginx, etc; is helpful if you want to strengthen the defense mechanisms of your new applications.
For example, X-Frame-Options denies rendering within one frame; it does not render if the origins do not match but allow rendering when carried out frame by frame from the domain. The other secured headers that can be used are X-Content-Type-Options, Strict-Transport-Security.
There should be no restriction on the password strength i.e. the size and complexity of characters. Moreover, the storage of passwords should be in the encrypted form; preferably in the hashed format because it is irreversible. The definite number of login attempts and informing the user of the timings of their logins as well as failed login attempts are commonly applied helpful secured practices.
Guarding your session transit with the help of SSL is amongst the best ways to save your day. The session id should ideally be never included in the URL; they should be long enough that makes them impossible to be guessed. Never accept a session-id suggested by a user!
Authentication of every component with the other is highly important; applying strong procedural and architecture mechanisms prevents the misuse of site architecture as it progresses over time. Using no-cache tag deters from going back to the login page using the back button and obtaining the resubmitted user credentials.
These are simple measures if taken will keep you on the safer side.
