Google Frowns On Rogers Injection

The example of Rogers dropping a notice onto Google’s homepage began making the rounds yesterday. Some people called it a threat to net neutrality, which seems a little too extreme an assessment.

Matt Cutts called the practice “pretty uncool,” but noted this was not the official Google party line.

“It may be your only chance to see the word “Yahoo!” on Google

Anyone who has recalled the line from the 1976 movie ‘Network‘ – "I’m mad as hell, and I’m not going to take it any more!" – understands the frustration of having Internet service that has been tweaked by the Internet service provider to stymie peer to peer traffic.

The EFF isn’t happy about this either.

They have added a little whipped cream to their sundae of complaints regarding the business of interfering with how people use their Internet connections.

The Test Your ISP project at EFF helps people understand if their providers may be fiddling with Internet traffic.

Detecting packet injection takes a little technical savvy, but when conducted properly will show if the ISP has been dropping packets into one’s connections.

"This recent interference by Comcast in their subscribers’ Internet communications is a cause for grave concern," said EFF Staff Technologist Peter Eckersley. "It threatens the open Internet standards and architecture that have made the network such an engine of technical and economic innovation."

Hindering Internet traffic shifts what had been a neutral environment of people choosing what they want to participate in online to a model where the ISP treats its network as a chokepoint.

Comcast or others could use this power to arbitrarily determine what their customers can and cannot do with the service they purchase.

That would run counter to the design of the Internet, and the freedom that has led to the development of useful applications and services available to anyone who can connect to them.

follow me on Twitter

Yep, that’s right, the same guys who give us a great Thursday night lineup (“My Name Is Earl,” “The Office,” “Scrubs,” and “30 Rock,” though I think they swapped the order), just gave Healthline, a medical search engine, a great wad of cash.  Other contributors include Aetna Ventures, LLC, Kaiser Permanente Ventures, and U.S. News and World Report.

There’s the financial side for you.  As for the operational aspects, VentureBeat’s Matt Marshall reports that Healthline “is focusing solely on health search, and is making surprising headway.  It has six million monthly unique users, and is the only search engine among the top-twenty U.S. health-related sites – with the exception of Yahoo Health.”

And to connect the financial and operational facets, we’ll go to an official press release from Healthline itself.  “Highlighting this financing round is a series of key operating alliances between Healthline and its strategic investors, including an agreement in which Healthline will provide its industry-leading search, navigation and content services to NBC Universal’s iVillage Total Health, a consumer health portal.”

Sounds like everybody’s coming out ahead.  I am worried about “Scrubs,” though – seems like the show came kinda close to being cancelled.  Perhaps Healthline could send some of the $21 million its way.

When it comes to rules, I believe that management and not execution is the issue for many organizations (such as Sun for instance) and that’s the weakness for me in Nik’s argument. While "dependency injection" may or may not beat out a rule engine, most of us who are serious about rules use business rules management systems and managing code is just way harder, and less effective, that managing rules.

Sorry for the lack of posts recently, had a deadline.

Comments

Hence, most databases you may get from outside sources will probably be in the form of a MySQL injection script. This is fine if you use MySQL for your own website databases, but if you use Microsoft SQL Server the script will require a little editing before it will work.

The first thing you’ll need to do is remove any comment lines from the script. MySQL comment lines begin with a pound character (“#”) and MSSQL comment lines begin with a double dash (“–”), which makes them completely incompatible and will product a syntax error if you try to import a MySQL injection as-is into MSSQL Server. So to get started, open up Query Analyzer if you haven’t already (the easiest way to run scripts in MSSQL Server), load up the injection script you are working with, and remove any comment lines (look for the pound symbol). It is easier just to remove them than it is to try and convert them to propery MSSQL syntax, and they are just comment lines anyway so it won’t affect anything.

The bulk of your script will most likely be a series of INSERT statements, and these aren’t very different in MSSQL as compared to MySQL. However, your script may also include at the beginning a small section that creates the database table where the data will be inserted, and this CREATE TABLE statement is likely to be VERY different in MSSQL, depending on how complicated it is (there could be primary and secondary keys, constraints, even triggers — the more of these the more the syntax changes from MySQL to MSSQL). Since this is likely to give you the most trouble, it is recommended that you create the database tables manually in Enterprise Manager rather than trying to convert the syntax of the script snippet. Looking at the code, you should be able to easily identify the fields and their types (such as int, varchar, text, etc). Once you have the database table created in Enterprise Manager, delete the snippet of code from the injection script that deals with the creation of the table.

Now all that remains is to convert the INSERT statements to the proper syntax for MSSQL Server. There are a few different steps to accomplish this, but none of them are very complicated. The first difference in syntax between MySQL and MSSQL is that in MySQL, all statements must end with a semicolon (“;”). In MSSQL, this is a syntax error. The easiest way to remove these semicolons is to do a search and replace, and since the INSERT statements should be passing a series of values for each record of data, each line of the MySQL script will most likely end with a paranthesis and semicolon (“);”). So, do a search and replace and replace all instances of “);” with just the parenthesis “)”.

Another difference that you will have to correct for is that your MySQL injection script will most likely use an acute accent / reverse apostrophe (ANSI character 180) around the table name on each line. In MSSQL Server, you can encapsulate an object’s name (such as a table’s) with either square brackets (“[" and "]“) or nothing at all. However, you probably don’t want to do a blanket search-and-replace of the reverse apostrophe character, because that character might be used in the data of each record (especially if the data contains text, such as an article body). The easiest way to correct for this difference in syntax, then, is to do another search and replace, and replace all instances of the reverse apostrophe AND the table name, for example “`articles`” with just the table name “articles”.

Finally, there will also be numerous occurrences of apostrophes throughout the text fields of the data, and the apostrophe character is used to encapsulate strings in the script. In MySQL, the way to escape an apostrophe so that the script knows it is part of the text and not the end of the string, is to use a backslash followed by the apostrophe (“‘”). In a MSSQL Server script, the proper way to escape an apostrophe is to use a double apostrophe (“””). So, one more search and replace is called for — this time, replace all instances of ['] with [''] (double apostrophe, NOT an actual quotation mark).

Once these steps are all complete, you are ready to run the script! There shouldn’t be any other syntax changes you’ll have to make, but don’t worry if there are because when you execute the injection script it will tell you if there are any errors. If everything was corrected properly and there are no errors, you should get a series of “1 row(s) affected” responses — one for each INSERT statement in the script. If you want to verify that the proper number of records are in the database table, you can execute a “select count(*) from tablename” statement to count the rows of the table — it should match the number of lines in the injection script, give or take a few for blank lines, etc.

That’s it! Your options are now increased tremendously, because now you can use either MySQL or MSSQL injection scripts to import acquired databases into your database system. If you use MySQL as your dbms, you can do this process in reverse to convert a MSSQL injection script into a MySQL one. Either way, you now can import data using an injection script from either of the two most popular database management systems in the world. Now, where to obtain such databases or injection scripts is another question entirely, and beyond the scope of this article. Suffice it to say that there are numerous sources on the internet where you can purchase or acquire databases — a good one is www.WebContents.org. I think you will find that not only is it much easier to acquire content databases for your users than it is to build them from scratch, but it also is an easy way to add a lot of new, fresh content for your users with a minimal amount of time and effort. Using this method, you can get databases of articles, jokes, quotes, recipes, etc, and put them right on your website or any other database-integrated application, with very little work. Good luck!

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

This article was written by Lucas Green, a professional private web developer who lives off his internet income. To visit his website and learn more about how he is creating multiple streams of passive income using the internet, please visit www.lucasgreen.com !

1. Cross Site Scripting (21.5%)

2. SQL Injection (14%)

3. PHP includes (9.5%)

4. Buffer overflows (7.9%)

Mike Sutton wanted to know just how prevalent are SQL Injection Vulnerabilities? So he ran a little test, and found that out of 1000 web sites 11.3% of them were vulnerable!

I also heard this from Mike Andrews in his How to Break Web Software talk. He says that the number of buffer overflow vulnerabilities have been going down over the years as more people are aware of them, and there are lots of automated tools for finding them. But the number of web application vulnerabilities has been sky rocketing.

Buffer Overflows were first talked about in the 1970′s by the NSA, and they are still somewhat of a problem – do you think we will still be talking about Cross Site Scripting and SQL Injection in 30 years?

Comments

Related Entries

How to Break Web Software – April 21, 2006

Top 20 Internet Security Vulnerabilities of 2005 – November 23, 2005

MySpace Hacked with CSRF and XSS – October 13, 2005

Detecting SQL Injection with ScriptProtect – May 18, 2005

ScriptProtect in ColdFusion MX 7 not a catch all – May 17, 2005

Digg | Reddit | Furl

Bookmark WebProNews:

*Originally published at Pete Freitag’s Homepage.

Pete Freitag (http://www.petefreitag.com/) is a software engineer, and
web developer located in central new york. Pete specializes in the
HTTP protocol, web services, xml, java, and coldfusion. In 2003 Pete
published the ColdFusion MX Developers Cookbook with SAMs Publishing.

Pete owns a Firm called Foundeo (http://foundeo.com/) that specializes
in Web Consulting, and Products for Web Developers.

If you are not so confident with programming languages and web technologies you may be wondering what SQL stands for. Well, it’s an acronym for Structured Query Language (pronounced “sequel”). It’s “de facto” the standard language to access and manipulate data in databases.

Nowadays most websites rely on a database (usually MySQL) to store and access data.

Our example will be a common login form. Internet surfers see those login forms every day, you put your username and password in and then the server checks the credentials you supplied. Ok, that’s simple, but what happens exactly on the server when he checks your credentials?

The client (or user) sends to the server two strings, the username and the password.

Usually the server will have a database with a table where the user’s data are stored. This table has at least two columns, one to store the username and one for the password. When the server receives the username and password strings he will query the database to see if the supplied credentials are valid. He will use an SQL statement for that that may look like this:

SELECT * FROM users WHERE username='SUPPLIED_USER' AND password='SUPPLIED_PASS'

For those of you who are not familiar with the SQL language, in SQL the ‘ character is used as a delimiter for string variables. Here we use it to delimit the username and password strings supplied by the user.

In this example we see that the username and password supplied are inserted into the query between the ‘ and the entire query is then executed by the database engine. If the query returns any rows, then the supplied credentials are valid (that user exists in the database and has the password that was supplied).

Now, what happens if a user types a ‘ character into the username or password field? Well, by putting only a ‘ into the username field and leaving the password field blank, the query would become:

SELECT * FROM users WHERE username=''' AND password=''

This would trigger an error, since the database engine would consider the end of the string at the second ‘ and then it would trigger a parsing error at the third ‘ character. Let’s now see what would happen if we would send this input data:

Username: ' OR 'a'='a Password: ' OR 'a'='a

The query would become SELECT * FROM users WHERE username='' OR 'a'='a' AND password='' OR 'a'='a'

Since a is always equal to a, this query will return all the rows from the table users and the server will “think” we supplied him with valid credentials and let as in – the SQL injection was successful .

Now we are going to see some more advanced techniques.. My example will be based on a PHP and MySQL platform. In my MySQL database I created the following table:

CREATE TABLE users ( username VARCHAR(128), password VARCHAR(128), email VARCHAR(128))

There’s a single row in that table with data:

username: testuser password: testing email: testuser@testing.com
To check the credentials I made the following query in the PHP code:

$query="select username, password from users where username='".$user."' and password='".$pass."'";

The server is also configured to print out errors triggered by MySQL (this is useful for debugging, but should be avoided on a production server).

So, last time I showed you how SQL injection basically works. Now I’ll show you how can we make more complex queries and how to use the MySQL error messages to get more information about the database structure.

Lets get started! So, if we put just an ‘ character in the username field we get an error message like You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”” and password=”’ at line 1

That’s because the query became

select username, password from users where username=''' and password='' What happens now if we try to put into the username field a string like ‘ or user=’abc ? The query becomes

select username, password from users where username='' or user='abc ' and password=''

And this give us the error message Unknown column ‘user’ in ‘where clause’

That’s fine! Using these error messages we can guess the columns in the table. We can try to put in the username field ‘ or email=’ and since we get no error message, we know that the email column exists in that table. If we know the email address of a user, we can now just try with ‘ or email=’testuser@testing.com in both the username and password fields and our query becomes

select username, password from users where username='' or email='testuser@testing.com' and password='' or email='testuser@testing.com'

which is a valid query and if that email address exists in the table we will successfully login!

You can also use the error messages to guess the table name. Since in SQL you can use the table.column notation, you can try to put in the username field ‘ or user.test=’ and you will see an error message like Unknown table ‘user’ in where clause

Fine! Let’s try with ‘ or users.test=’ and we have Unknown column ‘users.test’ in ‘where clause’

so logically there’s a table named users .

Basically, if the server is configured to give out the error messages, you can use them to enumerate the database structure and then you may be able to use these informations in an attack.

Add to | DiggThis | Yahoo! My Web

Technorati:

The author is a 23-year-old coder. He specializes in computer security, C and PHP coding, networking and server administration.

With more and more programmers creating dynamic, database driven websites, the proliferation of PHP and MYSQL is reaching critical mass proportions. With that however, comes the added “bonus” of many different security holes being opened on hosted boxes everywhere. With the current atmosphere of fear and mistrust when it comes to the security of the Internet right now, as programmers, we should be doing everything that we can to build safe, secure applications.

How can we do that? Well, the first step is education. Knowing the risks you are creating with your programming, and mitigating those risks with good programming practices. The most important part of educating yourself is understanding the different vulnerabilities that you can create with your programs. By far the most dangerous is SQL injection.

What is SQL injection? Simply put, it is the ability to inject and run arbitrary SQL code without having access to the database by traditional means. In lay terms, a user can access information or gain unauthorized access to the information contained in your database. This can be particularity troubling if you keep information such as customer contacts, credit cards, or other personal or critical information in your database.

What does SQL injection look like? Imagine the following SQL query:

select * from customer_info where name=’$_POST[username]‘ and pass=’$_POST[password]‘

If someone wanted to try and gain access to the area you are securing with this query, they could simply enter as their password: ‘ or ’1′=’1′, resulting in the following query being executed:

select * from customer_info where name=’someusername’ and pass=” or ’1′=’1′

If you evaluate that, then it will select everything from that table, since the OR ’1′=’1′ will always be true, resulting in ALL the records being selected.

Protecting against this should take the form of several steps, but the first and foremost is that ANY and ALL input that is going to be used in an SQL query should first be filtered for content. This can be done for each variable individually, but that can get tedious. Instead, when I am processing a form of information that will end up in a database of some sort, I have a function that filters data based on what I want to do with it.

Because I only trust data that I have filtered exclusively for the uses I have in the script, the first thing that I do for all my scripts is filter out any slashes that may be present. I do this specifically because of a couple of php.ini settings that may be turned on: magic_quotes_gpc, and magic_quotes_runtime. These functions automatically escape quotes, which is generally a good thing, but can make a programmer lazy. This is especially true if you are developing an application for widespread use on different systems that may or may not have this setting active.

I prefer to control my own data filtering, so the first thing I do is remove any slashes that may have automatically been added:


function cleanSlashes($array=Array()) {
      foreach($array as $x=>$y) { $array[$x]=stripslashes($y); }
      return $array;
}

This would strip slashes from an array of information – a single variable could be stripped just as $var=stripslashes($var);

Once the slashes are stripped and I have the bare data, I can now decide how the data is used, and where. If I were going to insert the data into a database, I would filter it with:


function makeDBSafe($array=Array()) {
      foreach($array as $x=>$y) { $array[$x]=mysql_real_escape_string($y); }
      return $array;
}

If I wanted to use the data back in a text box (for error checking or the like):


function makeInputBoxSafe($array=Array()) {
      foreach($array as $x=>$y) { $array[$x]=htmlentities($y,ENT_QUOTES); }
      return $array;
}

Or if I were saving it to a file on the server:


function makeShellSafe($array=Array()) {
      foreach($array as $x=>$y) { $array[$x]=escapeshellcmd($y); }
      return $array;
}

Ideally however, I would have one function that would perform all of these, as I need them:


function filterData($value="",$filter_type="basic",$data_type="array") {
      if($data_type=="array") {
           foreach($value as $x=>$y) {
                switch($filter_type) {
                     case 'basic': //filter out slashes from a post/get/cookie
                     $retvar[$x]=stripslashes($y);
                     break;
                     case 'dbencode': //encode db data using mysql_escape_string
                          $retvar[$x]=mysql_real_escape_string($y);
                     break;
                     case 'shellencode': //encode shell argument string data
                          $retvar[$x]=escapeshellarg($y);
                     break;
                     case 'htmlencode': //encode for form display with htmlentities
                          $retvar[$x]=htmlentities($y,ENT_QUOTES);
                     break;
                }
           }
      } elseif($data_type=="string") {
           switch($filter_type) {
                case 'basic': //filter out slashes from a post/get/cookie
                     $retvar=stripslashes($value);
                     break;
                     case 'dbencode': //encode db data using mysql_escape_string
                     $retvar=mysql_real_escape_string($value);
                break;
                case 'shellencode': //encode shell argument string data
$retvar=escapeshellarg($value);
                break;
                case 'htmlencode': //encode for form display with htmlentities
                     $retvar=htmlentities($value,ENT_QUOTES);
                break;
           }
      }
      return $retvar;
}

This function will allow me to pass through an array or a string, and select the type of filtering that I want to perform on the data based on an argument sent to the function.

The data filtering solution for SQL Injection is only one method among many that should be observed when creating web applications. You should also be paying attention to access rights within your database its self, server security, and data management security. However, if you start by filtering your data, then you have a solid foundation from which to build on.

Just as data filtering is only one solution for SQL Injection, SQL Injection is only one type of potential security flaw that is exploitable in PHP code, there are many others such as Cross-Site Scripting, access control flaws, cookie/session protection, and more. As a developer, you should be familiar with each of the potential risks of these expoits, and educated on how to avoid them in your programming.

With more and more Web 2.0 application being built, and technologies such as AJAX being leveraged to build next generation online programs, we have a responsibility as developers to pay more attention to these sorts of potential problems, and be aware that we must stop programming as if our users are all benign and will nicely use the application as developed. There are bad guys out there, and we should always build with them in mind.

Mike Morton has been developing web applications with PHP and MYSQL for more than 6 years, and is the author of Real World PHP Programming: The Basics which can be found at http://www.vtccanada.com

The vulnerability itself showed up in previous version prior to the current 4.71 so the appropriate patchwork should be applied to all the previous version. The original release notes were posted at Sourceforge.net:

Recommended that all postgresql users upgrade to this version.
Fixes important postgresql security issues problems related
to binary strings. Thx to Andy Staudacher.

Also several DSN bugs fixed, including one introduced in 4.70
that corrupts underscores in the DSN, and in PHP5 DSN’s did
not work. Added support for PDO DSN connections.

And the changes include:

DSN bugs found:

Added register shutdown function session_write_close in adodb-session.inc.php for PHP 5 compat.

All this is in addition to other SQL injection vulnerabilities. On Monday, an injection vulnerability was found in Zoph. This one was rated as moderately critical and a vendor patch corrected the problem. This was also an injection vulnerability.

Secunia also discovered another SQL injection vulnerability in e-moBLOG. To exploit this, hackers must disable the “magic_quotes_gpc.” While the vulnerability was confirmed in the 1.3 version, other versions could be affect also.

Input passed to the “monthy” parameter in index.php and the “login” parameter in admin/index.php is not properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

All these vulnerabilities showing up fairly close together suggests a little more editing might need to be done on these products. While they aren’t all exactly the same, SQL was the key to each and all were injection vulnerabilities. In any event, make sure updates are maintained and this will help eliminate problems.

Email the author

Add to | DiggThis | Yahoo My Web

John Stith is a staff writer for WebProNews covering technology and business.

A malicious coder could use the vulnerability to spoof a legitimate web site, and gather personal information from users tricked into visiting and interacting with the spoofed site.

Secunia rates the flaw as moderately critical, and confirms it exists in Firefox 1.0.4 and Mozilla 1.7.8. Mozilla has recommended users close all other tabs in the window before visiting a site where personal information will be entered.

Mozilla has been very quick to deal with security issues as they have arisen. Users should visit the Mozilla web site for updates on the flaw and for a patch when it becomes available.

Last month, Mozilla had to quickly fix three significant security flaws discovered during Mother’s Day weekend.

It appears the growing popularity of Firefox has placed it into the sights of more malicious attackers. Users who have moved from Microsoft’s Internet Explorer to Firefox are starting to find security problems following them to the new browser.

Browser security is an industry problem, not just a problem of manufacturers, as a member of the IE team at Microsoft observed online.

More information on Secunia’s findings, including a link where a user may test their Firefox or Mozilla browser for the vulnerability, may be found online.

David Utter is a staff writer for WebProNews covering technology and business. Email him here.