On May 14, 2015, at 8:37 PM, Jigme Datse Yli-Rasku <jigme.da...@gmail.com> 

> On 15/05/14 18:19 , Karl DeSaulniers wrote:
>> On May 14, 2015, at 8:09 PM, Aziz Saleh <azizsa...@gmail.com> wrote:
>>> On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers <k...@designdrumm.com> 
>>> wrote:
>>> Hello Everyone,
>>> Have a quick question. Was reading some material and wanted some Players 
>>> perspective.
>>> I know w3schools is not the de-facto on everything, so I wanted to know how 
>>> reliable is the information on this page.
>>> http://www.w3schools.com/sql/sql_injection.asp
>>> Namely the @ symbol before SQL Values and because this talks about SQL and 
>>> not MySQL specifically, does this not apply to MySQL?
>>> To my uneducated eyes it seems legit. Any clarification is greatly 
>>> appreciated.
>>> TIA,
>>> Best,
>>> Karl DeSaulniers
>>> Design Drumm
>>> http://designdrumm.com
>>> That is preferred in PHP as well. The SQL/MySQL isn't specifically doing 
>>> the replacement, but rather the driver object. Using parametrized queries:
>>> http://php.net/manual/en/pdo.prepared-statements.php
>> Thank you Aziz,
>> Interesting link, thank you for that. I have not worked with prepared 
>> statements on my own, just in WordPress.
>> So the @ symbol is a preferred method even outside the SQL world because?
>> What specifically is the @ symbol doing?
>> From what I read, and from what you just mentioned,
>> it's the PHP->SQL driver that check this @ symbol and treats the data as 
>> literal text?
>> Meaning it will not execute the text that comes after the @ symbol as code.

> If I understand correctly it is not the @ symbol itself which is the thing 
> you should be looking at.  What you should be looking at is how your 
> programming language handles prepared statements.  What I see is that the @ 
> symbol is how ASP.Net defines the variable name, and also the variable 
> position.
> I am not sure about this, but it looks like PHP uses : for the same function.
> I am even less sure about this, but I think with prepared statements you can 
> also define what "type" of data is being passed.  So if you try to pass a 
> "string" (ie. something that cannot be converted to a number) to a "number" 
> defined variable, you will get an error thrown.  If you use a catch statement 
> that error can be handled by your code, rather than PHP handling it in 
> default manner.
> It really has been a long time since I have been hands on with any of this, 
> and there is a good chance at least some of what I am saying is wrong.
> The point of prepared statements is that what variables you are passing 
> through them, they are passed as literal values, rather than simply putting 
> them through as straight text put into your string you are passing to SQL.
> Even if the string ends up "breaking" your query in a way that can harm 
> either security of data, or your database itself (also a security issue), it 
> is not passed in a way that SQL handles as such.
> I discovered an issue on one of the web apps I used where I would get a SQL 
> error message if I entered certain strings into the input field. Even though 
> what I was doing wasn't at all trying to test for it, my inputs made it clear 
> what was going on.
> With that amount of "what is going on" figured out.  I could send a 
> meaningful bug report that got this issue fixed.  Most people using the site 
> would have had no idea what was happening.
> If I recall, I was putting a " or ' in my input, thus closing the string, 
> which then left the rest being interpreted as SQL code.

Thanks Jigme,

Ok, so understand my own situation, the method I have been using, mysqli real 
escape string is suffice?
Or is the @ symbol is the better preferred method?


Karl DeSaulniers
Design Drumm

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to