HTML5 WebSockets - security & new tool for attacking

WebSockets is definately one of the brighter features of HTML5. It allows for easy and efficient real-time commucation with the server, and with the introduction of Socket.IO, node.js  and similar libraries, it is sure to gain popularity. It's a must when you're developing an interactive application like chat, game, realtime reporting system etc.

But, from a security standpoint there are many things to consider when implementing WebSockets in your next project. I don't call them vulnerabilities - but they will most likely create a vulnerability when not dealt with correctly. In this post I describe all these aspects and release socket_io_client - tool for testing & exploiting WebSockets servers.

Hardening PHP: How to securely include remote code (part 3)

In this last post of the series we learn how to use Phar archives and OpenSSL together to build a secure remote code deployment framework. I present PharUtil - the library adding convenience and security to Phar functionality.

Hardening PHP: How to securely include remote code (part 2)

In second post of the series I describe methods of checking the integrity of remote code - from checksums to (simple) Public Key Infrastructure. To transfer the code I introduce the popular Phar archives.

Hardening PHP: How to securely include remote code (part 1)

First post of the series discussing various methods of including remote PHP code in your application - from security standpoint. In this post we discuss the history of remote code execution vulnerabilities in PHP apps and ways to prevent them. We finish off by presenting an unsecure method of including a remote code and describe what is the problem with that method.

Hardening PHP: SQL injection - Complete walkthrough

Below are the slides from the presentation I recently gave on SQL injection on OWASP Poland Chapter meeting. The materials teach how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas and caveats are included. I discuss why escaping is usually the wrong choice, which practices to avoid or follow and how stored procedures sometimes offer no protection at all.

I tried to make this as complete as possible, so a PHP developer could learn how to protect his applications no matter what framework / database he uses.

English version

SQL Injection: complete walkthrough (not only) for PHP developers

View more presentations from Krzysztof Kotowicz.

Polish version

Kompletny przewodnik po SQL injection dla developerów PHP (i nie tylko)

You could also watch video recorded from the presentation. There are already some comments on the slides on niebezpiecznik.pl (Polish), but of course feel free to add comment here.

Hardening PHP: magic_quotes_gpc - False sense of security

Writing secure applications from the ground up requires a programmer to fully understand all the features he uses to protect his code from vulnerabilities. Today's languages provide many ways to ease coders with hardening their code. You can rely on built-in libraries to filter input variables, escape the output in HTML etc.

However, staying secure is not that simple - you need to know all the limits and caveats of your tools, because sometimes they promise you something but do not deliver - as it is in case of magic quotes functionality.

Magic quotes

PHP magic_quotes_gpc are sometimes recommended as a protection from SQL injection .When this ini setting is on, all GET/POST/COOKIE variables are automatically run through addslashes() function, basically escaping all quote characters with "\".

All is good

Let's look at an example, where that protection would work:

<?php
// some admin login functionality
$logged_in = mysql_query("SELECT 1 FROM users WHERE login='admin' AND password=sha1('" . $_POST['password'] . "')");
// process $logged_in

When magic_quotes_gpc are ON injecting the PASSWORD variable won't work. A simplest attack vector "' OR 1=1 -- " would transform to

SELECT 1 FROM users WHERE login='admin' AND password=sha1('\' OR 1=1 -- ')

That's a perfectly escaped SQL query, nothing can get injected. magic_quotes_gpc escape the dangerous single quote for us. So - goodbye SQL injection? WRONG!

Magic quotes only insert a backslash before a few characters, nothing more. That protects you from SQL injection only in some particular cases like above and only by coincidence. To prove that, let's analyze the following script.

So much for magic...

<?php
// display a single post based on id
$post_data = mysql_query("SELECT title, content FROM posts WHERE post_id={$_GET['id']}");
// display $post

The same "' OR 1=1 -- " transforms to invalid query:

SELECT title, content FROM posts WHERE post_id= \' OR 1 = 1 --

and if you have display_errors ON, you just made the attacker very happy with your database details outputted right before his eyes. Even if you don't, there still is a possiblity of blind sql injection.

But what if an attacker set id parameter to one of these:

• 1 AND (SELECT COUNT(*) from another table_name) BETWEEN 0 AND 100
• -10000 union select user_password from users where user_login=CHAR(97,100,109,105,110) (admin)
  

You won't get any protection from these vectors - they slip right under the eyes of  magic_quotes_gpc - they don't contain quotes.

In this case a single mysql query parameter that was left unprotected could lead to your whole database content dumped to the attacker (I'm not kidding - see sqlmap and try for yourself).

Know your context

The fundamental problem with magic_quotes_gpc is that they know nothing about the context. They don't know if you're using the data to insert it into MySQL, Oracle, or if you're writing to a file. Maybe you're sending it through SOAP or displaying it in HTML? Or maybe all of it. They just don't have enough information, only you know it. Escaping values depends on a context in which they are used. You should disable magic quotes now also for the following reasons:

• they mangle your data before you get the chance to reach it and can lead to double escaping,
• most frameworks expect them to be off, and if they're enabled, try to undo these changes at bootstrap,
• they're deprecated in PHP 5.3 and will be removed in PHP 6.
  

But you need to escape your data nonetheless. Follow these simple rules:

• to output to a HTML - use htmlspecialchars()
• to escape a string in MySQL - use mysql_real_escape_string(). 
• to escape a string in Postgresql - use pg_escape_string() 
• When you are expecting an integer in SQL query - simply cast to int
• ALWAYS use prepared statements when querying databases.

If you want to read more on bypassing magic quotes and SQL injection in general, I recommend:

• SQL injection: Not only AND 1=1 presentation
• Advanced SQL injection to operating system full control 
• Advanced PostgreSQL SQL Injection and Filter Bypass Techniques
  

Have any comments on the subject to share?  Please do so, this is my first security-related post and I'd like to hear your opinion.