₦airaland Forum

A lot of database driven websites are designed without the consideration of SQL injection; a technique where someone could actually (legally or illegally) query the database of a particular database driven website via form text fields or URL manipulations to retrieve data.

Feel free to share your experience and knowledge and if you are a Database/SQL guru who's not comfortable with releasing a whole lot of information to novices, then you can comment transparently in encryption.

brushesz: Feel free to share your experience and knowledge

How do you mean?

Slyr0x: How do you mean?

//Have you successfully injected via data fields or "?" edit before?

if (true){
then post a light comment about it;
}
else{ ignore_thread();
}

brushesz: //Have you successfully injected via data fields or "?" edit before?

Yes.

brushesz: if (true){
then post a light comment about it;
}
else{ ignore_thread();
}

It was an enlightening experience

When u are using PDO Extension with php to deal with mysql, i think you dont need to worry about sql injection.

pasted this s*#@ on a friend's website(http://www.abcdef.com/index.php?) username's field

SELECT*FROM "Bleep.self::$users." WHERE id={$id};
Definitely, $id = 0

Submit and Got it.

Yinksey: When u are using PDO Extension with php to deal with mysql, you dont need to worry about sql injection.

This is not entirely true.

Using the PDO prepared statement is sufficient to prevent 1st order injection (i.e. it takes this input and filters it before inserting into the DB). .

However, for 2nd order injection, let's look at this scenario :

We have an ecommerce web application that has the "wish list" enabled. .Imagine the user types in

'; DELETE Users;-

. .Using prepared statement, the initial apostrophe gets deleted however the seemingly innocent-looking text gets inserted like this

INSERT Wishlist (ID, Item, City, Country) 
VALUES(1, ''';DELETE Users;--', 'Lagos', 'Nigeria')

Now, 1st order injection has been prevented. .However, when the user decides to display his wishlists with the query

SELECT * FROM Wishlist WHERE ID = '', Item);

becomes

SELECT * FROM Wishlist WHERE ID = '', DELETE Users;--);

This innocent-looking query just deleted the Table "Users". .

Having said this, Using only prepared statements is not sufficient to protect against sql injection attacks. .however, it's a step in the right direction

Yinksey: When u are using PDO Extension with php to deal with mysql, you dont need to worry about sql injection.

Let's not go too far. Let's look at the connection method from your beloved pdo class.

public PDO::__construct() ( string $dsn [, string $username
[, string $password [, array $driver_options ]]] )

From above, I have three revealed variables to play with; $dns, $username, $password.

I won't need to inject. All I need do is to {die mysql connection} from $dns.

That's iff pdo is used as a template class or not instantiated

Well maybe am still a kid in this, i only thought pdo got it all, but what are the real steps to take to prevent this dreadful attack @slyrox since i know u be an hacker. and @op.

Have you heard of magic quotes? With magic quotes you are saved. If you want I can paste the code for you.

didadavid: Have you heard of magic quotes? With magic quotes you are saved. If you want I can paste the code for you.

Don't paste it yet. Let's look @ how magical your " " could bend injections.

Came across magic_" " from lYnDaDoTcOm BtB & the abstraction was too easy to get.

Even PHP stopped magic_quotes() further development in recent versions.

I quote this from; www.php.net/manual/en/security.magicquotes.why.php

"There is no reason to use magic quotes
because they are no longer a supported
part of PHP. However, they did exist and
did help a few beginners blissfully and
unknowingly write better (more secure)
code. But, when dealing with code that
relies upon this behavior it's better to
update the code instead of turning
magic quotes on. So why did this feature
exist? Simple, to help prevent SQL
Injection. Today developers are better
aware of security and end up using
database specific escaping mechanisms
and/or prepared statements instead of
relying upon features like magical
quotes."

Yinksey: but what are the real steps to take to prevent this dreadful attack

If I don't know what your key looks like,
It may take me months to crack your lock {no matter how i try to interpret your URL}.
But if I have the least idea of how your key looks like,
it's a matter of minutes and your lock's busted.

That's what happens when people use factory-made locks like magic_" "

PHP answers: www.php.net/manual/en/security.magicquotes.why.php

pasted this s*#@ on a friend's website(http://www.abcdef.com/index.php?) pazzword's field to login /*after registering as a user.*/

**********'; DROP table pazzworde--&ALL went=>*************************************

Submit and Got it.

Hola chicos!

Do you know that "indexDoTphp" is an easy injection initiator, especially for those site without directories?

Try the relational functions and apply them on indexDoTphp. Experimenting on unknown-pages in the same directory with index.

Unknown becomes known!

That great joy when you see a .php on a site's URL. You run a test for escape data value and it's NULL.

You LOL! after the delimiter.