Thrudigital

The risk of your site being hacked by unauthorised visitors has become the webmaster’s ultimate nightmare. Since new technologies allow us to carefully secure login areas, we have a choice to make between solutions that integrate common or atypical, spectral or narrowly-specified protection. However, web application developers often forget about potential security holes. During the past few days I have been facing malicious attacks against one e-shop website. As the attack was repetitive, the e-shop’s owner had to close the site until the vulnerabilities were repaired.

As mentioned above, it is considered that the most common attack against web site is breaking through the login area. Naturally login areas are the first weak point on any web site. Because of this, it is recommended to keep them hidden from public. However, sometimes we aren’t allowed to hide such forms. Furthermore, there are e-commerce sites, web communities, and portals using applications which were developed by 3rd parties, so it’s impossible to change admin panels’ folders. Once a hacker realises you’re running some kind of public application, that person can easily obtain the same application. Anyhow, this is the most common mistake by internet businessmen. Any application which is available to the public is at risk of attack. Picture yourself as someone who wants to hack a competitor’s business. All you need to do is buy/download the same software and find the security holes.

No matter if you keep admin panels hidden from the public eye or if you login to your system from your homepage, you must keep all information secure. SSL is useful way to keep your login information safe. If you’re not able to use SSL protocol, you can still make your login area secure. For this purpose you should use the md5() function, a cryptographic hash function with 128-bit hash value. Calling this function from the client side can easily be done using JavaScript after a visitor clicks on the submit button. While you’re sending the secured login and password, it’s easy to keep anyone who is listening to your stream away from reading such information.

Nevertheless there are still weak points after securing logins and passwords. Since a dynamic web site interacts with visitor through variables and values which are transferred through forms and URLs, it’s quite easy to manipulate such values from the client side. Because variables’ values are used for database operations primarily, they are a potential danger for the web site owner. Internet sites can be divided into two basic groups: sites with pre-defined text outputs, and sites using content management-based systems. For us, there’s a huge impact of manipulating unsecured data on CMS-based sites. Thanks to their adaptable modularity, every piece of code must go through verification procedures which remove harmful elements. Sites with pre-defined outputs may use interactivity which could be another risk. As we know, there are two basic functions which convert any input into application-friendly data. These functions are htmlspecialchars() and stripslashes(). Additionally, the inverse function for stripslashes() is addslashes(). All three functions also exist in PHP. Of course, storing application-friendly data within a database still means potential problems when we show this data to our visitor. That’s why the strip_tags() function is useful for building hack-free web applications. This function helps us to avoid showing unwanted scripts on our homepage or even internal pages. Bear in mind you must weigh up two types of users: administrators (or privileged users) and ordinary visitors who can’t send us potentially harmful data. Allowing people to show harmful code on a site is the most common way for hackers to do their job. Be careful when applying filters and securing functions and take great care of who can potentially ruin your business.

Another potential security hole is shared web hosting. There’s little debate that free web hosting is potentially very dangerous. Moreover, there are no guarantees that paid web hosting services are any more secure. So, before you buy any hosting package, you should ask other customers about its reliability and security. Believe it or not, some sites are secured as discussed previously, but lacking in server security. Hackers buy web hosting from the same firm, and they hack into it using server-side vulnerabilities. People usually don’t know anything about files’ permissions and users’ privileges. For example, if  file’s attributes are 777, anyone can modify such file. This is why you should hire an experienced Linux system administrator or user, or learn how to secure your site on the server-side. Newly-released systems thwart attempts to modify files from outside the server. All in all, you should use 744 or possibly 644 permissions for files which require the client side to read their content, 711 or 611 for those which require executing and 700 or 600 for those files which aren’t called from anywhere in your application by your visitor. In very special cases you should use

766, 767, 765, 764, 755, 756, 757, 754, 777, 775, 776 774,

or 666, 667, 665, 664, 655, 656, 657, 654, 677, 675, 676 674

permissions, but it is not recommended to allow others to change your files’ content. The same principle applies to folders! Instead of files you should use databases, since database data can be easily protected against unwanted manipulation. Don’t forget that server-side security includes database security and protection, as well as filesystem security.

In summary, we can divide securing a web based application into the following rules:

Rule 1: hire a team of programmers who can develop a secured web site.

Rule 2: make your web application a safe and independent system with minimum maintenance.

Rule 3: use proper permissions and privileges within the file system. Call every function, data and module from one server.