Re: SQL Injection

On May 14, 2015, at 8:37 PM, Jigme Datse Yli-Rasku <jigme.datse@gmail.com> wrote: > On 15/05/14 18:19 , Karl DeSaulniers wrote: >> On May 14, 2015, at 8:09 PM, Aziz Saleh <azizsaleh@gmail.com> wrote: >> >>> >>> >>> On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers <karl@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? Best, Karl DeSaulniers Design Drumm http://designdrumm.com