From http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php I got:

SQL injection refers to the act of someone inserting a MySQL statement to be run on your database without your knowledge. Injection usually occurs when you ask a user for input, like their name, and instead of a name they give you a MySQL statement that you will unknowingly run on your database.

I read the whole article but I still have some major issues understand what it is and how can it be done.

In the first example, what will they actually see?

As far as i understood, if I actually echo $name, the will see all the names because it will always "be true" am I correct?

The other thing I dont understand is whether THE MySQL injection problem is solved with mysql_real_escape_string(), there has to be more to it.

What I really dont get is that mysql_real_escape_string() is made to solve that issue, why isn´t this done automatically, I mean is there a reason you have to add every time mysql_real_escape_string(), is there cases when you should use it and thats why they dont make this automatic?

I hope the question is clear enough, maybe my luck of understanding of the topic makes the question confusing so please ask for any clarification if necessary!

Thanks in advance!!

MySQL won't escape automatically, because you build the query string yourself. For example:

$query = 'SELECT * FROM users WHERE name="' . $name . '"';

You just pass the raw string stored in $query, which is open to SQL injection. For example, if $name is [something" OR "1=1] your query string ends up being:

$query = 'SELECT * FROM users WHERE name="something" OR "1=1"

That would return every user from the user table. Which is why you need to escape values. However, if you use PDO, it is done for you if you use the binding functionality. It's a 2 step process, preparing the querying, then "binding" the data/variables to the placeholders. In PDO, your query string would look something like this:

$query = 'SELECT * FROM users WHERE name=":name"';
$bindings = array('name'=>'something');
prepare($query);
execute($bindings);

Then, things are automatically escaped for you.

Browsing through the more dubious parts of the web, I happened to come across this particular SQL injection:

http://server/path/page.php?id=1+union+select+0,1,concat_ws(user(),0x3a,database(),0x3a,version()),3,4,5,6--

My knowledge of SQL - which I thought was half decent - seems very limiting as I read this.

Since I develop extensively for the web, I was curious to see what this code actually does and more importantly how it works.

It replaces an improperly written parametrized query like this:

$sql = '
SELECT  *
FROM    products
WHERE   id = ' . $_GET['id'];

with this query:

SELECT  *
FROM    products
WHERE   id = 1
UNION ALL
select 0,1,concat_ws(user(),0x3A,database(),0x3A,version()),3,4,5,6

, which gives you information about the database name, version and username connected.

I was discussing this with some friends and we began to wonder about this. Could someone gain access to URLs or other values that are contained in the actual objective-c code after they purchase your app?

Our initial feeling was no, but I wondered if anyone out there had definitive knowledge one way or the other?

I do know that .plist files are readily available.

Examples could be things like:

-URL values kept in a string

-API key and secret values

Yes, strings and information are easily extractable from compiled applications using the strings tool (see here), and it's actually even pretty easy to extract class information using class-dump-x (check here).

Just some food for thought.

Edit: one easy, albeit insecure, way of keeping your secret information hidden is obfuscating it, or cutting it up into small pieces.

The following code:

NSString *string = @"Hello, World!";

will produce "Hello, World!" using the strings tool. Writing your code like this:

NSString *string = @"H";
string = [stringByAppendingString:@"el"];
string = [stringByAppendingString:@"lo"];
...

will show the characters typed, but not necessarily in order.

Again: easy to do, but not very secure.

Snoop allows you to look inside the application and change element properties. Its a great asset for developers, but can be a security issue in some cases, like when we have users who like to look in places where they shouldn't be looking. Is there a way to do something to block applications like Snoop from "snooping" your application?

And if there is no way to block it, what do you recommend to do to minimize security risks?

Snoop is a utility that allows you browse visual tree of a wpf application and view and change properties. Its very useful when you are trying to debug something and have no idea what is going on. You can find more here.

Thank you.

By implementing security properly. If your "security" can be thwarted with a tool like Snoop, then you're doing it wrong.

Suppose there's a command that only certain users can execute. It sounds like the only place you're enforcing this is at the UI level (by disabling the corresponding button, for example). That being the case, you're right - I could easily use Snoop to enable the button and execute the command. But you should be enforcing the security constraints on your server, or perhaps in your command execution logic if you have no server. Basically, security should be implemented as close to the thing you're trying to protect as possible. Security at the UI level is merely for convenience of the user.

HTH,
Kent