ITWorld has just published a short Q&A with Richard Clarke focusing on Cyberwarfare and how companies can prepare.

This isn't strictly about security, though I suppose it could result from a security breach. The military lost an MQ-8 drone and then found it in restricted airspace over Washington D.C.. Ah well, say hello to our new robot overlords. Happy Friday everybody!

The Washigton Post has an excellent article today on how a USB drive was used to compromise military security. The article is light on technical details but it does act as a good reminder on the importance of physical security, as well as having secure operating systems.

PHP and MySQL are a natural pair. From the very beginning of PHP the language has had direct bindings to the MySQL API and a lot of applications still use those functions (i.e. mysql_connect, mysql_query, etc.) today. PHP has improved a lot and there are certainly better alternatives to using those direct API functions which I'll explore in subsequent articles. But if you have one of these legacy applications that uses the direct APIs you can do a lot to secure it from SQL injection without doing a massive port to one of the newer, better, PHP database APIs.

So, what's the problem with using this direct method? The issue comes in how we construct SQL queries. Here is a classic example:

<?php
$sql = "SELECT * FROM user WHERE ";
$sql .= "user_id='"+$_GET['user']+"' ";
$sql .= "AND password='"+$_GET['password']+"'";
$resp = mysql_query( $sql );
?>

Now leaving aside for the moment that the password field is unencrypted cleartext the primary issue here is that the query is vulnerable to SQL injection. The hacker could easily send a password string that terminated the single quote and added an OR condition that was always satisfied. That would give them instant access to the system because the query would always return the user record regardless of whether the correct password was provided.

The easiest way to secure your application from this type of attack is to use the mysql_real_escape_string method. This method escapes the string that's used in the SQL and thus protects against input that has malicious SQL embedded in it. Shown below is the same code fragment but with the mysql_real_escape_string method used.

<?php
$sql = "SELECT * FROM user WHERE ";
$sql .= "user_id='"+mysql_real_escape_string($_GET['user'])+"' ";
$sql .= "AND password='"+mysql_real_escape_string($_GET['password'])+"'";
$resp = mysql_query( $sql );
?>

Now some of the applications I've seen have had custom versions of mysql_real_escape_string that escaped out quotes. I really don't see the point of doing that. The mysql_real_escape_string does the job the right way. It's secure, it's maintained, and you should use it.

Having said all this, using the MySQL API directly is not really the best option. If you have the time you should use one of the newer database APIs for the following reasons:

• Database Portability - The MySQL functions are bound to MySQL only. Using an abstract database interface allows you to connect to any supported database using the same code.
• Replacement Operators - You place ? characters in your query string wherever you need parameters, then you pass in an array of parameters and they automatically fill those slots. That makes the query code a lot easier to read and maintain.
• SQL Injection Security - If you use replacement operators the database abstraction layer will automatically do the parameter escaping for you, thus saving you the hassle of doing it yourself and keeping you safe from SQL injection.
• Prepared Statements - You can prepare a SQL statement for execution, then use that statement multiple times in an efficient batch mode. That allows the database driver to cache the compiled SQL statement which gives you a real performance boost.

This blog post shows you how to secure the MySQL/PHP application you have today. In the follow-on blog post next week I'll show you how to convert this code to use one of PHPs database abstraction layers to get all of the advantages I enumerated above.

The guys at Python Security are doing an awesome job not only categorizing types of security attacks, but also specific vulnerabilities in Python packages. If you are involved in security and work in Python I hope you will help out their site and contribute your expertise on the Wiki.

Anyone running a ColdFusion server will want to know about this vulnerability. It allows an attacker to get access to any file on the server without authentication. There is a patch for versions 8 and 9 of the CF server.

In the coming months we will be putting more information onto the security blog in a relevant form for front-line engineers. We're happy to take any suggestions you have for what topics we should cover. In this entry we look at how to secure PHP applications from cross-site scripting.

A very common source of PHP security issues in cross site scripting (XSS) attacks based on using unfiltered user input in PHP driven HTML pages. Here is an example of a simple web form:

<html><body>
	<form action="showme.php" method="POST"> 
	<textarea name="mytext"></textarea>
	<input type="submit">
	</form>
</body></html>

Here is the associated showme.php page with the XSS security issue:

<html><body>
<?php echo( $_POST['mytext'] ) ?>
</body></html>

This code allows an attacker to put anything he wants on the page, new tags, and of course, Javascript of his own design.

A simple way to secure the code is to use the PHP strip_tags function:

<html><body>
<?php echo( strip_tags( $_POST['mytext'] ) ) ?>
</body></html>

This will strip any HTML out of posted variable, thus negating any possibility of injected tags or attributes. You can loosen up this filtering by adding a second parameter to strip_tags with a list of allowed tags. However there are issues with the second parameter to strip_tags that you should be aware of.

It is important to understand how to validate input within a context. In this case I've simplified it by outputting HTML. But if you are putting the text into CSS or Javascript, you will need to understand what potential there is for adding malicious scripts in those contexts, and it won't be as easy as simply removing tags. Perhaps more on that in a followup blog.

We have more information on XSS attacks in PHP on our Vulncat site.

Hi, I'm Jack Herrington. I'm a senior software developer at Fortify. I'll be blogging here to give a developers perspective on security, as well as to bring some light to product features, and maybe throw in a relevant article or two.

To start this off I bring you a piece from Marketplace. They had an interesting story yesterday on the privatization of police forces. The software security relevant element is here:

That's right. In other words, up to now, we talked about the lower-level security that private security guards enter into. Now, we have more sophisticated crime, like identity theft, like Internet crime. The police doesn't deal with it anymore at all. So, private security forces got into it, but it's further. A lot of those investigations require high caliber professionals -- accountants, IT people, lawyers, etc. -- that the police have difficulty recruiting, because of limited budget. And it can never pay the high salary that the private sector does.

Nothing too surprising, but it is interesting to see the acknowledged potential for private IT security and the lack of resources in the public sector to handle IT issues. And of course it's nice to hear about high salaries in the security space.

Even though I don’t have to worry about this now, in less than 12 years my son will become a teenager. At that point I will join the parenting crowd in trying to find ways to ensure my child’s safety without compromising his privacy. Considering that the world around us is turning more and more mobile, and it’s becoming impossible to find a phone that just makes phone calls, the idea of a mobile phone application that assists in parenting a teenager sounds less and less fictional.

To be honest, I would not be talking about this now if I did not come across an interesting paper on the subject. The authors conducted interviews with several teens and their parents and, based on their responses, provide guidelines for designing secure and private mobile phone safety technologies. The questions discussed include the kinds of data to collect, as well as when and whom to notify.

One of the interesting and possibly unexpected things that came out of the interviews is the kind of data the parents want and the teens are willing to share. For example, both teenagers and their parents agreed that mood is too private to share with anyone, unlike exact address of location, transportation type, destination, and the names of companions. In addition, the kids are more willing to share various types of information if they are notified when the other party accesses information about them. Both teens and their parents are reluctant to share any information with the government, however their views disagree on whether teenager’s friends should have access to the data – parents feel a lot more reluctant about it than their kids do.

Based on the observations drawn from the analysis of the interviews, the authors of the paper then proceed to make several technical recommendations for the design of future parent-teen mobile safety technologies. For example, they suggest separate encryption pathways for different types of data, as well as multi-party decryption for the data that need to be accessed when, for example, multiple parties must work together during a teen’s disappearance.

It pleases me to see that this type of research is being conducted proactively rather than after-the-fact. There is hope that the developers of these new types of mobile applications will take suggestions from security researchers into consideration when designing new technologies. As for the code of these applications, there are always solutions like those provided by Fortify to assist in making sure that the implementation adheres to the design.