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