Securing Web Applications Powered by Mivec Framework

It is important that web application components, especially the files which are required to power the application, be well-protected from being directly accessible from the client side (i.e the client’s web browser). It is also important that the web application is able to prevent malicious users from embedding codes which could potentially compromise the web application, or the client’s web browser.

Below we will discuss some features available from Mivec Framework for securing web applications.

Note:

1. These recommendations only secure your web application at the web server level; they don’t guarantee the web application will not be exploited in other ways, such as through the server’s shell, physical damage, etc.
2. These advices are provided with the best hope to secure your web application; but we cannot guarantee that, and we hold no responsibility if your web application is still being compromised.

If you have complete control of the server, it is best to place the whole application’s libraries (i.e. the Actions and its dependencies) outside the web server’s root; and also, add the following define statement inside MivecServlet.php:

define("CONFIG_FILE", "/your/path/to/mivec/config/MivecFrameworkSettings.php");

So that you can leave only MivecServlet.php on the web server, with all other server-side resources (except images, CSS, client-side scripts, etc.) inaccessible by the client.

In addition, if you are working with a UNIX server, you may also use chmod command to allow only the web server’s user to access the web application’s files locally. For example:

chown -R wwwrun.nogroup /srv/www/htdocs/demo
chmod -R 600 /srv/www/htdocs/demo

However, note that it may also block yourself from changing the files directly!

If you don’t have complete control of the server, but you’re able to use .htaccess to override Apache httpd’s default settings, for each of the directory where Mivec Framework libraries and your web application files, except static resources, such as images, CSS, clients-side scripting files, etc., place a .htaccess with the following contents:

Options -Indexes
<Files ".*">
  order deny,allow
  deny from all
</Files>

You may take a look at the example application for an idea of how to do it.

For the worst case, if you cannot use .htaccess at all, you will need to take the following suggestions into serious consideration:

1. Use PHPArrayActionMapInitializer in place of any other ActionMapInitializer implementations
2. Make sure all web application files are ended with the extension .php
3. If possible, try use dotted directory names, such as “.lib”, “.demo”
4. If possible, change the directories and files permission to allow only you and web server can access it (Most FTP servers supports chmod command)

Otherwise, you should consider changing your hosting service…

Cross-site scripting refers to embedding HTML codes, possibly with client-side scripting codes, that could possibly compromise the client’s web browser.

Such exploits usually comes from web applications which directly prints out client’s entry onto the screen. Malicious users may input some HTML codes, possibly with client-side scripts, that could crash the other user’s web browser, or even hijacked other user’s cookies.

For example, a malicious user may enter the following string to the web application, such as a chat room:

Hihi<script language="JavaScript">if(confirm("Your computer may have been compromised! Click \"OK\" for a quick fix")) window.location='http://www.you-are-mine-now.com'</script>

and this unescaped HTML will be rendered directly as HTML to the other users, which brings them to the abyss of danger when they click “OK” on the popup dialog box…

As a precaution, Mivec Framework automatically converts client’s input, changing the < and > characters into &lt; and &gt;s by default. The above string will be printed as-is, i.e. not in HTML code, to the client’s screen.

If you want to get the original input back, you will need to use StringUtils::encodeHTML($str):

$clientHTML = StringUtils::encodeHTML($this->ta);

The same also applies to cases when you need to strip all HTML tags away with PHP’s strip_tags(), or you will get a string with HTML tags not stripped at all (as they are already escaped)!

$msg = strip_tags(StringUtils::encodeHTML($this->message));

SQL injection refers to embedding SQL strings into their input to the web application, thereby allowing malicious users to gain access to all data on the database.

For example, inside an Action we have:

$result = mysql_query("SELECT * FROM users WHERE userID = '" . $this->userID . "'";

A malicious user may enter

myusername' AND '1=1

So that he can see all user names stored on the database, as the above statement will execute the SQL

"SELECT * FROM users WHERE userID = 'myusername' AND '1=1'"

Again, as Mivec Framework converts client input by converting the HTML tag braces (< and >) to &lt; and &gt;, it also converts the quotes to their HTML entities - so that ’ becomes &#039; and “ becomes &quot; - which allow them to touch the database server safely: the above SQL will become

"SELECT * FROM users WHERE userID = 'myusername' AND '1=1'"

These characters are still visible as normal characters ’ and ” on the browser screen. They will not be converted back to their original form with StringUtils::encodeHTML(), so that you can be sure that your HTML output is validatable (or HTML validation errors is not caused by us ).

However, if you don’t like this, though not recommended, you can still customize it to your needs, by setting the configuration parameter mivec.settings.quote.handling.options at settings.properties, to the values ENT_COMPAT, ENT_QUOTES or ENT_NOQUOTES, as described in PHP htmlentites manual.

« Prev: Session Handling