Introduction

Clickjacking is a malicious technique of tricking web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function (credit: Wikipedia).

Clickjacking is hard to combat. From a technical standpoint, the attack is executed using a combination of CSS and iFrames, which are both harmless web technologies, and relies mostly on tricking users by means of social engineering. Additionally, the only server side technique against …

I was working on a client’s server that was recently compromised.  Interestingly the attacker had replaced the OpenSSH server with “trojan” binaries that accomplished two things:

• All logins to the system had the username/password logged in a plain-text file (this was how I discovered the problem with OpenSSH)
• It gives the attacker a remote backdoor that is undetected to the system. Another words, when the attacker logs in using the compromised sshd they do not show up in top or ps.

This is bad enough, but it gets worse. The system had been compromised for a week before I began working on it. There is no telling how many other binaries were changed. I did find that the ssl certs had been modded. At this point there is no way that the current setup can be cleaned with any assurance that it is completely secure. No baseline of the system with a tool such as tripwire …

Actually, what I really wanted to blog about before getting carried away with irony yesterday was an old idea on how to force my developers to use placeholders exclusively for SQL queries in applications. As should be apparent from yesterdays blog entry, I am strongly in favour of using placeholders for interpolating values into SQL queries, due to the great reduction in potential bugs (including, but not limited to, SQL injections).

Basically, wrap the database API so that all database access passes through the wrapper. This can usually be achieved, for example by subclassing DBI (for Perl) and returning such subclasses from the application connection pool, or other similar methods. Probably many large web applications already have such wrappers or use APIs that can be patched or extended appropriately.

Now add code that basically bombs out with a big …

It is sad to see how 9X% (or should that be 99.X%?) of SQL applications are riddled with SQL injection bugs.

There really is no excuse for this. Nobody writes code like this:

sub stupid_sum {
    my ($list) = @_;
    my $string = shift @$list;
    for (@$list) {
      $string .= " + " . $_;
    }
    my $sum = eval($string);
    return $sum;
}

Right? Just because our computers use the Von Neumann architecture, where CPU instructions and data is stored in the same memory, does not mean that we cannot distinguish between code and data (ok, so in TeX we do not, but there is a reason TeX is not pleasant to write applications in).

So when we use …

Preventing MySQL Injection Attacks With GreenSQL On Debian Etch

GreenSQL (or greensql-fw) is a firewall for MySQL databases that filters SQL injection attacks. It works as a reverse proxy, i.e., it takes the SQL queries, checks them, passes them on to the MySQL database and delivers back the result from the MySQL database. It comes with a web interface (called greensql-console) so that you can manage GreenSQL through a web browser. This guide shows how you can install GreenSQL and its web interface on a Debian Etch server.

I’ve been working with a client recently who has SELinux on his servers.  It has been quite a struggle sometimes.

My colleages tell me that SELinux has a pretty noticeable performance impact.  I am not sure if we have benchmarks to support this; at any rate, the client said it’s OK, we’ll take the performance hit.

There [...]

This Monday, September 8th, the Boston MySQL User Group broke our 2-month summer hiatus with a presentation on MySQL Views.

The slides can be downloaded from http://www.technocation.org/files/doc/2008_09_Views.pdf -- 89 kB, .pdf format.

The 199 Mb .flv file can be downloaded at http://technocation.org/node/621/download or played directly in your browser at http://technocation.org/node/621/play.

The presentation covers:

read more

If you are security conscious and nowadays who isn’t?, you may have pondered over ways to make your external SSH connection safer.
Of course there’s always One-time Passwords and Public Keys, but if like me you watch the daily barrage of brute force attacks you may be thinking it’s only a matter of time…

That’s what I was thinking at about the same time an SMS arrived on my mobile….then it hit me….I take my mobile everywhere, if only my server could call me and ask if it is really me trying to log in.

My first instinct was to try and insert a Perl or Python script into the login process. After all …

Last week I gave my first webinar for MySQL titled “Bau sicherer LAMP Anwendungen”. The webinar, which was a cooperation between MySQL and my company SektionEins, was held in german, covered SQL-Malware, SQL-Injection, safe programming and some tools to detect and block SQL-Injection attacks.

The recording of this webinar is now available on the MySQL site.

For those that only want to see my slides they are available on the MySQL site after registration or here.

Because it was a german webinar the recording and slides are in german, too.

While SQL-Injection is one of the most discussed security problems in web applications other possible problems for SQL queries like overlong input are usually ignored although they can lead to all kinds of security problems.

This might be caused by the fact that security problems that are the result of overlong input are often buffer overflows and buffer overflows are something many web application security experts know nothing about and choose to ignore.

There are however several security problems for SQL queries that are caused by overlong input and no one talks about.

max_packet_size

In MySQL there exists a configuration option called max_packet_size which is set to one megabyte by default and controls the maximum size of a packet sent between the SQL client and server. When queries or result rows do not fit into a single packet a error is raised. This means an overlong SQL query is never sent to the server …