Security of Web Applications

Motivation

As we have seen in the previous chapter: Creating dynamic web pages from your server is easy. You can use CGI, PHP, Python, Perl, etc.. Also there are a lot of free and open source packages that you can deploy on your own server for a lot of different applications. Wordpress and other popular content management systems, etc..

The problem is to keep them secure. Here you learn the basic rules to follow and how to avoid the most common security issues.

Common Security Problems

Buffer Overflow

When you use compiled software (e.g. written in C) and the programmer is not careful, then it can happen that a buffer that is used to hold a string and is filled with data that comes from the outside user overflows and overwrites neighboring data. Often this is can be exploited to run arbitrary code on the machine.

Usually people do not write their web applications directly in C but e.g. you use some tool to convert images and that uses some library code and there might be bugs. The best way to avoid problems here: Regular updates of your operating system software.

Bugs in off-the-shelf applications

When you use many of the available packages of free software: Also keep them up to date. Once in a while bugs are found there but usually quickly fixed. The best solution here is to have an automatic update. In most Linux distribution a lot of popular web applications are bundle with it and you get your updates together with the normal OS updates.

SQL Injections, Shell Injections

If you have a dynamic web site you usually get some input data from forms that the user fills out or from cookies that are kept on the browser of the user, etc. All of this data is dangerous and needs to be properly checked and sanitized. Instead it often happens that some of this data is used to directly create SQL queries or passed to a shell where parameters for some external command are created.

If you do not take care it is extremely easy to overlook a possibility where some special crafted data can be used to execute any SQL statement or any shell command, etc.

// do NOT do this:
$res=mysql_query(
’SELECT * FROM bla WHERE id="’ . $_GET[’id’] . ’"’
);

The above could be from some PHP script that uses string concatenation (with . ) to create some query string for mysql instead of using dedicated functions for that. the _GET is used to read the input from a form or a hidden variable from a web page. NOw a hacker can put anything there and use ' to close the argument and add additional code there... See: https://xkcd.com/327/

Something similar might happen if you include a shell command go convert some image or send and email where you pass some untrusted strings to the shell...

To avoid this: sanitize your input. E.g. if some id is only numerical: Filter out anything that is not numerical. If you pass data to external tools, shell commands, always be careful. There are usually secure ways to do that.

XSS - Cross Site Scripting

In the early days of the web we only had static pages and dynamic content was created on the web sever itself. Then came JavaScript which allowed some programming that in the browser itself. Server admins where not concerned as this ran on the client. For a few years nobody noticed that this still was a problem:

JavaScript in the browser can access the cookies for the site. If someone manages to place some JavaScript in the HTML page of a user they are then able to read the cookie of the user. Since the cookie is often used for maintaining a session between requests: They can take over your session.

As we have seen in the chapter above: Injection of code is easy to overlook - in this case many web programmers where not even aware that this injection of JavaScript had grave consequences.

Here is an example:

echo "Your id is ",$_GET[’id’];

This could be part of a PHP code. Now the id field could be filled in the URL with url?id=somestring and that somestring could contain a JavaScript program that would then be executed in the browser of the victim. All an attacker would need to do is bring people to click on that link. E.g. by spamming it over email. In a different form of this attack: If we e.h. have a discussion forum where people can post messages: If the input is not sanitized the JavaScript could be served as part of the page for all users. So there they do not even need to click on an URL.

To avoid this attack: Before you display anything on a web page: Replace all special characters that are used in crafting HTML pages with something else. E.g.

< &lt;
> &gt;
& &amp;
...

This way there will be a < displayed on your page instead of enabling an attacker to craft HTML or JavaScript elements.

What else you can do about securing your site?

• keep your OS, libraries and web scripts up to date.
• Run Everything with minimal privileges.
• Run services with different users
• Do not pack to many services on one host and or:
• Separate things into virtual machines or containers
• Break up your service into different tiers and run critical things in the background with limited connection to the front end.
• When you store passwords: Do not store them in clear but run them through a hash. Always use a long random salt with your hash.

Exercises

• Try to understand who the above security problems work. Try to google and find some examples of where that happens.