2014.10.17. 6:51 ezt írta ("Rasmus Lerdorf" <ras...@lerdorf.com>):
>
> On 10/16/2014 09:10 AM, Ferenc Kovacs wrote:
> > I don't think we should remove the option, just change the defaults, and
> > most people would be fine switching back to the emulation, but it should
> > be their conscious decision imo.
> > Currently many people aren't aware that they are using client side
> > prepares, and they are pretty much ignore the fact, that they can be
> > exposed to sql injections (for example via using mismatching client and
> > server encodings or not properly quoting the
> > identifiers: http://www.codeyellow.nl/identifier-sqli.html because they
> > think that server side prepared statements would be immune to this kind
> > of problems).
>
> I think you have the wrong idea here. That link you pointed to talks
> about SQLi in identifiers. Server-side prepares are just as vulnerable
> to this, so switching from client-side to server-side does nothing to
> make this safer.Server side prepares does not support parameter binding for identifiers so while you can still be vulnerable if you concatenate variables into your query, but you wouldn't think that you are immune to sql injection that way. Emulated prepares make it look like that you are. > > As far as a charset mismatch between the client and the server when it > comes to preparing query values, PDO's implementation handles that. You > need a connection handle to do a prepare so we know the charset and take > that into account. Same thing here, while (since 5.3.6 afair) you are able to pass the encoding information to the pdo driver (before that you could only use set names which pdo doesn't care about) the emulation still make it look like that you are immune, because many people aren't aware of the emulation and assumes that they are immune to sqli because the params travel as separate entity from the query to the server.
