About the topic Web Security many allegations, prejudges and false evaluations exist. As a result much false information is spreading and insufficient protective measures are being used. In this article we will unveil 10 of the most popular myth about the topic Web security.

To some of this myth there exist some practical examples which will demonstrate how an attacker will bypass insufficient security measures.

Are static web sites really secure? Are client-side vulnerabilities like Cross-Site Scripting (XSS) really harmless? – That and quite a few more will be unveiled in this article.

1. Static Web Sites Are Secure

Many think static web site (html-documents) are secure, because no server-side script languages like PHP are being used and therefore no security issues will emerge.

For the web site itself this may be true. However web sites always reside on a server and the server may contain vulnerabilities. Therefore a attacker may still be able to access every file (html-documents) and alter them.

It does not have to be vulnerabilities in the server software. Many web site operators are simply using web hosting packages and no separate server. Every single customer gets some disk space on a server. On the same server many other customers have placed their web site on – and definitely not only static ones. If those web applications include any vulnerability the attacker may be able to get access to the server. Different directories on a shared server do have access protection but an experienced attacker is even able to bypass this and then he will be able to access any directory on the server. On this issue I will write an article later on.

2. My web site is of no interest for an attacker

Just because there are no sensible data like passwords, data from customers, etc. existing does not mean that an attacker may have no interest in your site.

Web sites can be manipulated in different ways. If files are offered as download they can be changed. Links can be altered so they will lead to an infected site. Proxy servers can be installed. Phishing-sites can be uploaded, etc.

3. http-authentication is secure

If weak passwords (or usernames) are being used, attackers can easily crack it by using brute-force or through dictionary attacks. Even if secure login-data is used it still does not mean that it will protect you from unauthorized access.

For example there exists a method with which it is possible to bypass the HTTP-authentication through manipulation of a certain HTTP-method.

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

That is one of the most popular prejudges existing against XSS from “self-appointed experts”.

Thereby they do not even exactly know the possibilities of XSS. XSS vulnerabilities are often used to steal someone’s cookie-information. Often the cookie-information contain sensible data which will be transferred to the server. That may be encrypted (sometimes even decrypted) login data or session ids (SIDs) with which an attacker may be able to hijack the current session (Session Hijacking - about this I will also write an article later on.)

But stealing of cookies is not the only thing what an attacker can do with XSS. For example an attacker may be able to inject a XSS-shell and intercept all the data sent by the user- amongst others XSS-shells are being used as temporary keylogger.

With the aid of DOM-based XSS client-side code can be executed with the privileges of the current user. If the old IE was used it even could lead to Remote Execution (and therefore access to the PC).

5. The function »htmlspecialchars« automatically prevent XSS

With the aid of the functions htmlspecialchars and htmlentities XSS can be prevented. However these functions can be used in the wrong way.

In addition the following example:

If normal JavaScript code is inserted in the text field and the form is sent special chars will be converted (that is what we want) in HTML code.

value='<script>alert(1);</script>'

At first glance this may look good, but at second glance it will be a potential security risk. The functions htmlspecialchars and htmlentities encode chars which would normally XSS; however a certain char normally is not encoded: the simple quotation mark.

Cause the variable »textfield« (which contains the user input) stands between simple quotation marks it is possible to escape the value-attribute and JavaScript-handler can be injected whereby code can be executed by certain actions.

For example it is possible to insert the following string into the text field:

'onmouseover='alert(123);

Now if you move the mouse over the text field the JavaScript code will be executed. In this example it is a harmless alert-box. If you look closer you may notice that no char exists which the functions htmlspecialchars and htmlentities normally would encode.

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);

6. The function »mysql_real_escape_string« automatically prevents SQL-Injection

The function mysql_real_escape_string prevents SQL-Injection if user-side input used by a SQL-query is situated inside of string – simply spoken it is surrounded by quotation marks.

If this is not the case SQL-Injection is possible because the function mysql_real_escape_string (as its name implies) masks only certain char inside of a string.

In addition to that a (simplified) 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 SQL-injection would be possible without a problem. If the variable were situated inside a string SQL injection would not be possible. In some cases even mysql_real_escape_string can be bypassed.

To prevent SQL-injection in this example the value of the variable should be converted into a numeric data type. For this the PHP function intval can be used or you use the type casting.

$id = intval($_GET['id']);

7. »magic_quotes_gpc« automatically prevents SQL-injection

In many cases magic_quotes_gpc can be bypassed by an attacker – for example with the function CHAR or with hexadecimal values. magic_quotes_gpc will be removed in PHP 6.0.0.

8. DDoS Protection Scripts prevent DDoS-attacks

No script in the world provides an efficient protection against DDoS. Countermeasures should happen on a deeper level – e.g. at the Edge-Router from your provider or if necessary on the server-level. A 100% protection against DDoS attacks does not exist anyway.

9. The X-Forwared-For HTTP-Header does always contain the correct IP

Needless to say it does not. If anonym proxies are being used the real IP-address cannot be readout so easily. Even less if a proxy-chain is being used.

10. Validate $_GET, $_POST, $_COOKIE and your PHP script is secure

This is a common mistake PHP programmers make. User-side input or to be precise data from the outside may for instance be transmitted through the superglobal array $_SERVER to the web application. $_SERVER['HTTP_USER_AGENT'] for instance contains a User-Agent string which can be manipulated freely.

The opinion of our specialists

From an effective point of view you as the end-user, administrator, webmaster or IT-professional only need the aid of a few products which will help you to protect your web application. All those products you will find on the German Web Security page. Using the following link you be redirected to our " products".

Do not be satisfied with less - bypass complex obstacles – make your choice for the GWS - your professional web security auditor.