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.
--
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
