On May 14, 2015, at 8:37 PM, Jigme Datse Yli-Rasku <jigme.da...@gmail.com> wrote:
> 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? Best, Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
