[ciapug] On or Off ...

[Tony Bibbs]

Are you talking about cleaning it as far as escaping arguments to your 
prepared statements?  If so, 4.1.x should be doing it on the server for 
you.  Older ones would have to be done by your database abstraction layer.

I think it's safe to black-box that much of it.  As long as you are 
using prepared statements you are safe(r).

--Tony

Carl Olsen wrote:
> It is unclear to me where the actual "cleaning" of the data in MySQL,
> Improved (mysqli) is occurring.  Is it being emulated in code, or is it
> actually running inside the MySQL server (4.1.2 and higher - I'm on 4.1.13a
> right now)?
> 
> Carl
> 
> -----Original Message-----
> From: ciapug-bounces at cialug.org [mailto:ciapug-bounces at cialug.org] On Behalf
> Of Tony Bibbs
> Sent: Thursday, August 11, 2005 9:28 AM
> To: ciapug at cialug.org
> Subject: Re: [ciapug] On or Off ...
> 
> To be clear prepared statements are not the same as stored procedures 
> and the really aren't related.
> 
> Stored procedures are sets of SQL saved and 'compiled' on the database 
> server for faster execution.  There are a number of pros and cons to 
> stored procedures but, as you eluded to, this is not supported by MySQL 
> in the 4.x. branch (I believe 5.x introduces stored procedures as well 
> as triggers).  The lack of stored procedures and triggers is one of the 
> missing features that keep many from considering MySQL 
> 'enterprise-ready' (though I disagree).
> 
> Prepared statements are specially prepared SQL statements that are 
> pre-parsed on the DBMS server and help avoid one of the most common 
> security vulnerabilities, SQL injections.  I could explain this but 
> there's a ton on this on the web:
> 
> http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html
> 
> It's worth noting that even if your version of MySQL doesn't support 
> prepared statements, your database abstraction layer may emulate it for 
> you.  PEAR::DB and Creole both do this.  The only draw back from this is 
>   that you don't quite get the performance gain of server-side prepared 
> statements but you still get to avoid some of the risks of SQL injections.
> 
> FWIW, security would make for a great topic at one of the upcoming 
> meetings.  Things like SQL injections, JavaScript and XSS 
> vulnerabilities are quite common in PHP applications.  Showing how these 
> work with actual exploitable code and show the fix would help a lot of us.
> 
> --Tony
> 
> Carl Olsen wrote:
> 
>>Is a prepared statement the same thing as a stored procedure?  It's my
>>understanding that MySQL doesn't support them, which is why I've been
> 
> using
> 
>>PostgreSQL on my personal site (www.carl-olsen.com).  I know that the PEAR
>>DB functions support PostgreSQL.  I write stored procedures in PostgreSQL
>>using PL/pgsql and then make a class of functions that simply converts the
>>stored procedures to parameterized functions, with field names becoming
> 
> the
> 
>>properties and the add, update, and delete queries becoming the methods.
>>I'm not exactly sure if this protects me against SQL injection attacks,
> 
> but
> 
>>I'm thinking it does, since each parameter is fed into an input parameter
>>inside the stored procedure before anything happens.  I don't do any kind
> 
> of
> 
>>checking for single or double quotes.  Have I got this right, or should I
> 
> be
> 
>>laundering the user input as well?
>>
>>Carl
>>
>>-----Original Message-----
>>From: ciapug-bounces at cialug.org [mailto:ciapug-bounces at cialug.org] On
> 
> Behalf
> 
>>Of Tony Bibbs
>>Sent: Monday, August 08, 2005 10:55 AM
>>To: ciapug at cialug.org
>>Cc: cjh at raccoon.com
>>Subject: Re: [ciapug] On or Off ...
>>
>>For security reasons register_globals should be turned off, though as 
>>Dave mentioned, many older PHP apps require them.
>>
>>I prefer magic quotes to be turned off as well but that's simply because 
>>we use creole for database abstraction and it handles the quotes for us. 
>>  We've seen issues where PHP code gets ugly when you have a bunch of 
>>addslashes/stripslashes so it's best to leave that to something else 
>>(like you abstraction layer).
>>
>>Similarly PEAR::DB supports prepared statements which, if used, get you 
>>out of the business of worrying about quotes.
>>
>>--Tony
>>
>>Dave J. Hala Jr. wrote:
>>
>>
>>>Register globals off, is prefferred, unless you have some old php apps
>>>that didn't make use of $_POST  when posting variables.
>>>
>>>I believe globals off is now the default. You'll know right away if you
>>>got apps that require globals on. :)
>>>
>>>If you do, you may want to consider putting them on your list of apps
>>>that to be "phased out/rewrote" etc.
>>>
>>>:) Dave
>>>
>>>
>>>On Mon, 2005-08-08 at 09:34, Chris Hettinger wrote:
>>>
>>>
>>>
>>>>magic_quotes_gpc and register_globals .... On or Off ??
>>>>
>>>>I believe that, and correct me if I am wrong, most will say Magic Quotes
>>>>= On and Registered Globals = Off.
>>>>
>>>>Arguements one way or the other?
>>>>
>>>>-ch
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>ciapug mailing list
>>>>ciapug at cialug.org
>>>>http://cialug.org/mailman/listinfo/ciapug
>>
>>_______________________________________________
>>ciapug mailing list
>>ciapug at cialug.org
>>http://cialug.org/mailman/listinfo/ciapug
>>
>>
>>_______________________________________________
>>ciapug mailing list
>>ciapug at cialug.org
>>http://cialug.org/mailman/listinfo/ciapug
> 
> _______________________________________________
> ciapug mailing list
> ciapug at cialug.org
> http://cialug.org/mailman/listinfo/ciapug
> 
> 
> _______________________________________________
> ciapug mailing list
> ciapug at cialug.org
> http://cialug.org/mailman/listinfo/ciapug