php-general Digest 17 Jan 2012 22:56:47 -0000 Issue 7654
Topics (messages 316319 through 316323):
Re: SOAP
316319 by: lars.mit-web.dk
When will the ereg extension be removed from PHP?
316320 by: Kirk.Johnson.zootweb.com
316321 by: Kirk.Johnson.zootweb.com
Re: sql injection protection
316322 by: Haluk Karamete
316323 by: Alex Nikitin
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hey there,
If you are running php5 then ot is relativly easy to use the SoapClient
object. It also supports ssl. Look it up in the phpmanual.
Regards
Lars Nielsen
> Hello!
>
>
>
> I am looking for some help on Web Services (SOAP) client.
>
>
>
> Is there anyone here who has already worked with such client?
>
>
>
> Thank you
>
>
>
> Deleo
>
>
--- End Message ---
--- Begin Message ---
All,
The ereg extension was deprecated as of version 5.3.0. Does anyone know
what the schedule is for removing it completely?
Thanks.
Kirk
--- End Message ---
--- Begin Message ---
kirk.john...@zootweb.com wrote on 01/17/2012 09:59:43 AM:
> The ereg extension was deprecated as of version 5.3.0. Does anyone know
> what the schedule is for removing it completely?
Answering my own question, it looks like not before 6.0:
http://marc.info/?l=php-internals&m=132618195307998&w=2
Sorry for the static :)
Kirk
--- End Message ---
--- Begin Message ---
>> This is an interesting conversation, so I'm glad it got brought up,but I
>> find myself curious: Are you actually trying to avoid PDO, or just trying
>> to learn how the security actually works?
Well, It's a learning process. my point is this... If I can make it
safe and sound without the PDO, then I really got to the bottom of it.
Because once you reach there and I would be in a much better shape
cause at the end, I will still use PDO level.
PDO is not safe. I should say, it is not SAFE ENOUGH. You are still
vulnerable with PDO as well.
Cause PDO still requires you to validate your input. If you don't do a
good job at it, then you are using PDO as a drug. You have to go down
to bottom of it and that's validating the darn user input.
Well, if you validate your input well, then one can turn the question
around and ask, then why use PDO? It's not going to make it any safer!
It was already so.
The danger with the PDO articles...
Using/or Recommending PDO without the nitty/gritty details of how
important it is to validate your input is unfortunately leading people
( unexp. dev ) into thinking that it's a safer method, therefore they
can go relax at certain things and PDO will cover them.
I think one should try to make his data secure, first and foremost -
without *relying* PDO to take care of things.
Therefore, we should learn the crux of the matter. By that, I mean all
that multibyte and GPK Greek and some other weird char sets that one
should be aware of and what to do to really safe guard the databases
against all kinds of user data.
Only then and only then, one should START thinking about using PDO.
http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection
That's why I started this thread.
On Tue, Jan 17, 2012 at 4:39 AM, Andy McKenzie <amckenz...@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 10:34 PM, Haluk Karamete
> <halukkaram...@gmail.com> wrote:
>> I understand some ways are better than others in this one, and it
>> looks like the PDO based implementations shine the most as far as SQL
>> Injection.
>>
>> But would not the following be good enough - without implementing a
>> PDO solution?
>>
>> ....
>
>
> This is an interesting conversation, so I'm glad it got brought up,
> but I find myself curious: Are you actually trying to avoid PDO, or
> just trying to learn how the security actually works?
>
> Personally, my decision was that I could spend a lot of time learning
> all the ins and outs, or I could just use PDO and some basic input
> validation, and be more-or-less secure. I'm sure there are cases
> where that's not sensible, but it's always worked for me.
>
> -Andy
--- End Message ---
--- Begin Message ---
Haluk, don't listen to Ross, escaping fails, it was and is a bad
solution to an old and still largely unresolved problem. The problem
is and has been that of language interoperability, and we have been
and continue failing at making a good way for languages to talk to
each other, but because this is so needed, especially on the web,
where you blink and you are in another language; php, css, html, throw
in some javascript, and here is some SQL, oh i need some python, now
let's throw in some C, but none of these languages talk to each other,
so we have had to make it work and we do it with strings... This is
why we have SQL injection and XSS, and the only, i will repeat that,
the ONLY way to fix this issue is to have a clear way to say from
language to language that this is a programmer string, run it, and
this is user input, don't run it.
The only right solution is to pass your code as code and the user
input as user input, this way you are guaranteed that no execution of
user input is possible via usual SQL injection or XSS means. Of course
you still need to check and sanitize your input, there are still
typical issues, buffer and heap overflows, etc, but simple inclusion
of some "special" character and user input code that just gets ran
just like programmer code is simply not possible.
Escaping is a bad and many times failed attempt at saying that it's ok
to pass user input as code, we just escape the characters we think are
bad, to tell the interpreter not to execute them as it normally would.
But what does it mean to be a character? Well back when all these
languages were designed there was ASCII, and life was easy, now,
however we have utf7, utf8, utf16, with tens of thousands of
characters, many of which are the same symbol. Oh and they morph, if
you don't know what best-fit matching is, look it up, but at the end
of the day, if you think that you know what characters you need to
escape, you are wrong, i'm sorry. This is why in javascript there are
3 escape functions: escape, escapeURI and escapeURIComponent. Which
roughly translate to "we failed", "we failed again" and "we failed the
third time".
So in short, no, mysqli_real_escape_string is not a good solution to
SQL injection, PDO (as far as i can tell, though i haven't poured over
the code yet) or prepared statements, are. And neither negate the need
to check your input, as other, more traditional exploits would still
be possible (potentially)
Oh Haluk, drop the idea of occurrences of words, it may stop someone
who is just testing your code for fun, someone determined to get in
will still do plenty of bad with whatever words you allow, and you
have to allow certain words for your queries to run ;)
Anyways, hopefully this is something for you guys to think about and
hopefully enough to stop suggesting escaping as a viable option to
stop any sort of simple code injection...
~ Alex
--
The trouble with programmers is that you can never tell what a
programmer is doing until it’s too late. ~Seymour Cray
--- End Message ---
