Common Website Security Misconceptions

Below we will try to explain 8 most common misconceptions about website security that we are very often confronted while working with our Customers.

1. Static websites are secure

Many think static websites are secure, because no server-side script language (PHP, ASP, ColdFusion, PERL) is utilized. For the website itself this may be true. However, the web server the website is hosted may contain vulnerabilities, which can result in website compromise and unauthorized remote access. Keep in mind that some hosting companies use shared hosting, which means that your website is sharing disk and server amongst other users. Imagine that other Customers have website that contains vulnerabilities? This can put the whole server at risk, which includes your website.

2. HTTP authentication is secure

Each authentication is as secure, as its weakest password.If weak passwords are being used, the Attacker can easily crack them by using dictionary attacks or bruteforcing. Ensure your passwords are hard to guess and bruteforce.

3. My website is not a viable target for Hackers

Even if your website does not contain any sensitive information (such as passwords, Customers’ data etc) it does not mean your website is not a viable target for Hackers. Hackers also look for website to easily spread malware and phishing code in order to infect your visitors and staff or create malicious network of BotNets.

4. My website is protected by anti DDoS script

There is really no effective script solution to protect against DDoS. Countermeasures are complex and should usually happen on several layers possibly starting at the edge router from your provider up to server and application layer. Unfortunately, there is no such thing as a 100% effective solution.

5. Cross-Site Scripting (XSS) vulnerabilities are harmless

That is one of the most misconceptions. Cross-Site Scripting can be very dangerous. Folks are not aware that by injecting malicious Javascript payload you can not only steal the cookie, but modify page or its elements, perform phishing, install a keylogger or even perform operations on Victim’s computer. Cross-Site Scripting looking innocently could be used to stage and mount more serious and sometimes very sever attacks. We advice our Customers to take these flaws very seriously.

6. PHP magic_quotes_gpc() function automatically prevents SQL Injection

Magic_quotes_gpc() function can be bypassed with the function char or with hexadecimal values. Additionally, Magic_quotes_gpc() function will be no longer supported in PHP 6.0.

7. PHP htmlspecialchars() function prevents Cross-Site Scripting (XSS)

Let’s look at the following example:

At first it may look good, but the problem with the code above is that certain characters will not be properly encoded, such as single quotation mark. By taking advantage of this, we are able to perform attribute XSS. For example it is possible to insert the following string into the text field:

To encode simple quotation marks the modus ENT_QUOTES has to be used. This modus has to be committed as a parameter to the functions. $textfield = htmlspecialchars($_POST['textfield'], ENT_QUOTES);

8. PHP mysql_real_escape_string() function automatically prevents SQL Injection

The mysql_real_escape_string() function prevents SQL Injection if the user input used by a SQL query is placed inside of string – simply spoken it is surrounded by quotation marks. If this is not the case SQL Injection is possible because the mysql_real_escape_string() function masks only certain char inside of a string. Let’s look at the following example:

The variable id is not situated inside a string. Well it is not required, because it will include an ID which is numeric. However, because of this SQL injection would be possible. If the variable was placed inside a string, SQL injection would not be possible. In some cases even mysql_real_escape_string() function can be bypassed. SQL injection could be very tricky. We advice our Customers to really handle this for audit to security experts. To prevent SQL injection in this example the value of the variable should be converted into a numeric data type. For this the PHP intval() function can be used or you use the type casting.