Victim Ngamuk-ngamuk obrak-abrik Macromedia Flash & Windows

The Chosen One Beraksi…..

Luckily, there are literally dozens of tools for downloading videos from YouTube and/or converting those YouTube videos to some format other than .flv. It’s hard to pick the best one, as they all have pluses and minuses. Thus, we’ve chosen 23 YouTube downloader tools we’ve found to be actually working. Here they are, categorized according to the platform they work on:

Web based

1. videodownloadx.com doesn’t have a lot of options, but it’s simple, and it works. It also enables you to share the YouTube video with your friends via e-mail. Unfortunately, all the files are called get_video, and you have to add the .flv extension manually.

videodownloadx.com

2. KeepVid is another simple site. No hassle, works not only for YouTube movies but for a number of other sites, including Google Video, MySpace Video, DailyMotion and others. Again, you have to add the .flv extension by hand.

keepvid.com

3. VideoDownloader is very similar to KeepVid, but supports even more video sharing sites, and it’s also available as a Firefox Firefox 3 extension. Just like with KeepVid, all downloads are in .flv format. We recommend MediaCoder for free conversion.

javimoya.com/blog/youtube_en.php

4. YouTube Downloads takes the cake in the longest domain name contest. It also separates itself by using a proxy for downloading videos, which means that you might be able to get videos even if YouTube access is blocked at your workplace or in the country you live. Just search Google for YouTube videos, and copy/paste the URL into YouTube Downloads.

www.downloadandsaveyoutubevideos.info

5. Zamzar is an online file format conversion site which can do a lot more than just converting YouTube videos to another format and downloading them to your hard drive, but it’s doing a great job so we had to include it here. Thoroughly tested by us and highly recommended. See the video of it in action here.

Forms of SQL injection vulnerabilities

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application.

The following line of code illustrates this vulnerability:

statement := "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code is designed to pull up the records of a specified username from its table of users. However, if the “userName” variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the “userName” variable as

a' or 't'='t

renders this SQL statement by the parent language:

SELECT * FROM users WHERE name = 'a' OR 't'='t';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of ‘t’='t’ is always true.

While most SQL Server implementations allow multiple statements to be executed with one call, some SQL APIs such as php’s mysql_query do not allow this for security reasons. This prevents hackers from injecting entirely separate queries, but doesn’t stop them from modifying queries. The following value of “userName” in the statement below would cause the deletion of the “users” table as well as the selection of all data from the “data” table (in essence revealing the information of every user):

a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%

This input renders the final SQL statement as follows:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';

Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM data WHERE id = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the “id” field. However, if it is in fact a string then the end user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will delete the “users” table from the database, since the SQL would be rendered as follows:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

Vulnerabilities inside the database server

Sometimes vulnerabilities can exist within the database server software itself, as was the case with the MySQL server’s mysql_real_escape_string() function. This would allow an attacker to perform a successful SQL injection attack based on bad Unicode characters even if the user’s input is being escaped.

Blind SQL Injection

Blind SQL Injection is used when a web application is vulnerable to SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each byte recovered. A tool called Absinthe can automate these attacks once the location of the vulnerability and the target information has been established.

Conditional Responses

One type of blind sql injection forces the database to evaluate a logical statement on an ordinary application screen.

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1

will result in a normal page while

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2

will likely give a different result if the page is vulnerable to a SQL injection. An injection like this will prove that a blind SQL injection is possible, leaving the attacker to devise statements that evaluate to true or false depending on the contents of a field in another table.

Conditional Errors

This type of blind SQL injection causes a SQL error by forcing the database to evaluate a statement that causes an error if the WHERE statement is true. For example,

SELECT 1/0 FROM users WHERE username='Ralph'

the division by zero will only be evaluated and result in an error if user Ralph exists.

Time Delays

Time Delays are a type of blind SQL injection that cause the SQL engine to execute a long running query or a time delay statement depending on the logic injected. The attacker can then measure the time the page takes to load to determine if the injected statement is true.

Preventing SQL Injection

To protect against SQL injection, user input must not directly be embedded in SQL statements. Instead, user input must be escaped or filtered or parameterized statements must be used.

Using Parameterized Statements

In some programming languages such as Java and .NET parameterized statements can be used that work with parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. In many cases, the SQL statement is fixed. The user input is then assigned (bound) to a parameter. This is an example using Java and the JDBC API:

PreparedStatement prep = conn.prepareStatement
("SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?");
prep.setString(1, username);
prep.setString(2, password);

The same goes for C#:

using (SqlCommand myCommand = new SqlCommand
("select * from Users where UserName=@username and Password=@password", myConnection))
                {                    
                    myCommand.Parameters.AddWithValue("@username", user);
                    myCommand.Parameters.AddWithValue("@password", pass);
 
                    myConnection.Open();
                    SqlDataReader myReader = myCommand.ExecuteReader())
                    ...................
                }

In PHP, it’s usual to just escape the parameters before sending the SQL query:

$query = sprintf("SELECT * FROM Users where UserName='%s' and Password='%s'", 
                  mysql_real_escape_string($Username), 
                  mysql_real_escape_string($Password));
mysql_query($query);

For PHP version 4.1 and above, however, you can use extension like msqli for “true” prepared statement queries:

$db = new mysqli("localhost", "user", "pass", "database");
$stmt = $mysqli -> prepare("SELECT priv FROM testUsers WHERE username=? AND password=?");
$stmt -> bind_param("ss", $user, $pass);
$stmt -> execute();

The mysql_real_escape_string adds slashes (/) to escaped characters like single quotes ‘ and double quotes “. Though, you should read this

In ColdFusion, the CFQUERYPARAM statement is useful in conjunction with the CFQUERY statement to nullify the effect of SQL code passed within the CFQUERYPARAM value as part of the SQL clause.^{[5] [6]}. An example is below.

<cfquery name="Recordset1" datasource="cafetownsend">
SELECT *
FROM COMMENTS
WHERE COMMENT_ID =<cfqueryparam value="#URL.COMMENT_ID#" cfsqltype="cf_sql_numeric">
</cfquery>

Enforcing the Use of Parameterized Statements

There are two ways to ensure an application is not vulnerable to SQL injection: using code reviews (which is a manual process), and enforcing the use of parameterized statements. Enforcing the use of parameterized statements means that SQL statements with embedded user input are rejected at runtime. Currently only the H2 Database Engine supports this feature.

If you’ve ever worked with and manipulated MySQL databases, chances are you’ve used phpMyAdmin to manage your databases from a Web interface. But phpMyAdmin can be a little complex; if you want a lightweight alternative, try phpMinAdmin. It’s easier to install than its more robust cousin and has an easy-to-navigate graphical user interface for most important MySQL functions.

GreenSQL is designed to be used as a proxy for a MySQL database. Instead of connecting directly to your MySQL database, you Web site connects to GreenSQL. GreenSQL forwards legitimate SQL to the MySQL database and returns the results. If GreenSQL detects SQL that is not whitelisted and that includes nasty or suspicious SQL, it will block that SQL and return the empty result set without contacting the MySQL database. For an idea of the SQL injection attacks that GreenSQL blocks, see the online demo page.

GreenSQL is not in the distribution repositories for Fedora, openSUSE, or Ubuntu. It is available as a 1-Click install for opneSUSE 10.3, and for Fedora 8. The GreenSQL download page includes packages for Fedora 7, openSUSE 10.2, FreeBSD, and Ubuntu Feisty Fawn and older. In this article I’ll install from source on a 64-bit Fedora 9 machine using version 0.8.4 of greensql-fw.

Installation does not use autotools, and you have to set up things like configuration files, system users, MySQL configuration, log file setup, and /etc/init.d files manually. The procedure is well documented in install.txt. Better yet, by executing a few of the shell scripts in the scripts directory, you can complete much of the setup. To compile the application, simply execute make in the top directory as shown below. On Fedora 9 I got the following error soon after compilation started, which was due to libevent-devel not being installed.

$ tar xzf /.../greensql-fw-0.8.4.tar.gz $ cd greensql-fw-0.8.4/ $ make ... connection.hpp:29: error: field 'proxy_event' has incomplete type connection.hpp:30: error: field 'client_event' has incomplete type

Once I had libevent-devel installed, I found that I needed to modify /usr/include/event.h to include sys/types.h in order to compile event code.

vi /usr/include/event.h
...
#include <sys/time.h>
#include <sys/types.h>
#include <stdint.h>
#include <stdarg.h>

At this stage, make -k failed on a few files which were calling string functions such as strcasecmp without having included the string.h header file. Depending on which version of gcc you are using the below issues might not be present when you compile GreenSQL.

$ cd src $ vi mysql/mysql_con.cpp ... // License: GPL v2 (http://www.gnu.org/licenses/gpl.html) // #include <string.h> #include "mysql_con.hpp" ... $ vi config.hpp ... #ifndef GREEN_SQL_CONFIG_HPP #define GREEN_SQL_CONFIG_HPP #include <string.h> ... $ vi ../src/parser/expression.hpp ... #ifndef _SQL_EXPRESSION_HPP_ #define _SQL_EXPRESSION_HPP_ #include <string.h> ...

If you are building GreenSQL on a 64-bit distribution you will also have to modify the Makefile slightly so that the build checks lib64 instead of just the lib directory, as shown below:

$ vi src/Makefile
...
LIBS:=-L/usr/local/lib -L/usr/local/lib/mysql -L/usr/lib64/mysql -lmysqlclient -levent -lpcre
 
greensql-fw: $(OBJS)
...
$ make

Shown below are the commands to finish installation once the daemon is compiled. The package’s install.txt file describes manual installation, which uses the same commands that the scripts do. Using the scripts is likely to be the better option because the installation process can be improved (the contents of the scripts) while the procedure remains the same. The installation instructions recommend setting up the MySQL database before the /etc/greensql directory, but if you do that the MySQL script invocation fails to find the configuration file and you must make the changes to /etc/greensql/greensql.conf manually. This is a bit of a chicken and egg problem but the only major change you must make to the greensql.conf file is to get the MySQL database parameters.

greensql-fw-0.8.4]# cd ./scripts/
# ./setup_user.sh
done...
# ./greensql-create-db.sh
 
---------------------------------------------
The following settings will be used:
 
MySQL admin user: [root]
MySQL admin password: []
MySQL server address: [127.0.0.1]
 
GreenSQL configuration DB name: [greendb]
DB user to create: [green]
Password to set: [pwd]
 
Do you want to change anything? [y/N] y
 
MySQL admin user [root]: 
MySQL admin password []: XXxxXXxxXXxx-FIXME
MySQL server address (you can use ip:port string) [127.0.0.1]: 
GreenSQL config db name [greendb]: 
GreenSQL DB user name [green]: greendb
GreenSQL DB user password [pwd]: greendbpass
---------------------------------------------
The following settings will be used:
Do you want to change anything? [y/N] 
 
 
Creating MySQL database...
Adding MySQL user...
Creating MySQL tables...
 
GreenSQL configuration file is not writable!!!
Check that [database] section contains the following settings in
/etc/greensql/greensql.conf
 
[database]
dbhost=127.0.0.1
dbname=greendb
dbuser=greendb
dbpass=greendbpass
# dbport=3306
...
# ./setup_conf.sh
done...
# ./setup_log.sh 
done...
# ./setup_binary.sh
done...
# vi /etc/greensql/greensql.conf 
...
[database]
dbhost=127.0.0.1
dbname=greendb
dbuser=greendb
dbpass=greendbpass
...
# chkconfig  --add greensql 
service greensql does not support chkconfig
 
# /etc/init.d/greensql start

For testing purposes I created the test database and gave the user ben free access to it with the commands shown below:

# mysql -p
Enter password: 
Welcome to the MySQL monitor. Commands end with ; or \g.
mysql> GRANT ALL ON test.* TO ben@"%";
mysql> FLUSH PRIVILEGES;

GreenSQL runs on port 3305 by default, which is one less than the default MySQL port of 3306. If you use the mysql console client and connect to the GreenSQL 3305 port you will not be able to create a new table, even though, as shown in the command below, when you connect directly to MySQL on port 3306 you are able to create a new table.

$ mysql --verbose  -h  127.0.0.1 -P 3305 test
mysql> create table foo ( id int );
--------------
create table foo ( id int )
--------------
 
Query OK, 0 rows affected (0.01 sec)
 
mysql> insert into foo values ( 55 );
--------------
insert into foo values ( 55 )
--------------
 
ERROR 1146 (42S02): Table 'test.foo' doesn't exist
 
 
$ mysql --verbose  -h  127.0.0.1   -P 3306 test
Welcome to the MySQL monitor. Commands end with ; or \g.
mysql> create table foo ( id int );
--------------
create table foo ( id int )
--------------
 
Query OK, 0 rows affected (0.01 sec)
 
mysql> insert into foo values ( 55 );
--------------
insert into foo values ( 55 )
--------------
 
Query OK, 1 row affected (0.00 sec)
 
mysql> insert into foo values ( 131 );
--------------
insert into foo values ( 131 )
--------------
 
Query OK, 1 row affected (0.00 sec)
 
mysql>  select * from foo;
--------------
select * from foo
--------------
 
+------+
| id   |
+------+
|   55 | 
|  131 | 
+------+
2 rows in set (0.00 sec)

With the default GreenSQL configuration you cannot drop tables through the GreenSQL firewall. This is just as well, because table structure is not likely to change often and most likely will not change at all from the Web site interface.

$ mysql --verbose  -h  127.0.0.1   -P 3305 test
Welcome to the MySQL monitor. Commands end with ; or \g.
 
mysql>  select * from foo;
--------------
select * from foo
--------------
 
+------+
| id   |
+------+
|   55 | 
|  131 | 
+------+
2 rows in set (0.00 sec)
 
mysql> drop table foo;
--------------
drop table foo
--------------
 
Query OK, 0 rows affected (0.00 sec)
 
mysql>  select * from foo;
--------------
select * from foo
--------------
 
+------+
| id   |
+------+
|   55 | 
|  131 | 
+------+
2 rows in set (0.01 sec)

The injection tests did not seem to work as well as I had hoped. The first test was to delete tuples based on a condition that was always true. This wipes out all the data in a table and leave an empty table schema. By default this query worked through the firewall.

$ mysql --verbose  -h  127.0.0.1   -P 3305 test
 
mysql> delete from foo where 1=1;
--------------
delete from foo where 1=1
--------------
 
Query OK, 2 rows affected (0.00 sec)
 
mysql>  select * from foo;
--------------
select * from foo
--------------
 
Empty set (0.00 sec)

For the above SQL delete command, the /var/log/greensql.log file contained the following information:

SQL_DEBUG: QUERY command[]: delete from foo where 1=1
SQL_DEBUG: AFTER NORM   : delete from foo where ?=?
SQL_DEBUG: RISK         : 0

The /etc/greensql/greensql.conf file allows you to set how risky you think certain things are. For example, you can assign a weight of 10 to the use of the union keyword or with direct variable comparison in a query (something like 1=2). The variables include block_level = 30 so any query with a risk above 30 will not be forwarded to the MySQL server. In an attempt to make GreenSQL flag the above query I increased risk_var_cmp_var and risk_always_true up to 150 from their default of 30. Unfortunately, the query remained seen as a zero-risk query.

Because the above SQL might be valid, I based the query shown in the below logs on the template described in the MySQL SQL Injection Web page of the GreenSQL Web site. This SQL injection relies on the Web site inserting data provided from the user into an SQL query string and submitting it to the database. It too was allowed through.

SQL_DEBUG: QUERY command[]: delete from foo where id=181 or 1=1
SQL_DEBUG: AFTER NORM   : delete from foo where id=? or ?=?
SQL_DEBUG: RISK         : 0
 
SQL_DEBUG: QUERY command[]: delete from s where comment = 'whatever' or '1'='1'
SQL_DEBUG: AFTER NORM   : delete from s where comment = ? or ?=?
SQL_DEBUG: RISK         : 0

After much strace(1)ing and other prodding trying to work out why GreenSQL was flagging the above nasty query as zero risk it dawned on me to try a SELECT query. This was the key to getting GreenSQL to work as expected, blocking this nasty query, as the below portion of the log file shows.

SQL_DEBUG: QUERY command[]: select * from folks where name='sam' or '1'='1'
SQL_DEBUG: AFTER NORM   : select * from folks where name=? or ?=?
DEBUG:     Query has 'or' token
DEBUG:     Variable comparison only
SQL_DEBUG: RISK         : 3

Given that SQL injection in a select statement can allow a user to login to a Web site without a password, having GreenSQL inspecting your selects is a good thing. In future releases I hope the developers extend GreenSQL’s protection to delete statements, as an injection in one of those can clear an entire table.

Source : http://www.linux.com/feature/145341