Re: SQL Injection

On 15/05/14 18:19 , Karl DeSaulniers wrote:
> On May 14, 2015, at 8:09 PM, Aziz Saleh <[email protected]> wrote:
>
>>
>>
>> On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers <[email protected]> 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.


-- 
Datse Multimedia Productions
http://DatseMultimedia.com/
Tel:    250-362-5701
Mobile: 250-354-7094



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