>>Re-read his example. He encodes the data in PHP. But decodes the data in
>>SQL. So, if you echo the SQL statement, you would see a base64 encoded
>>string that SQL then decodes.
Got it this time! Up until reading your reply, I was reading Alex's
example with my pseudo-code glasses. I did no
On 01/26/2012 06:46 AM, Haluk Karamete wrote:
when we do b64e and then back b64d, you are saying. we get the org
input all as clear text but this time as a string. because it is now a
string, "(which by definition can not be executed)"
what's the difference between b64e+b64d vs (string) casting
On 26-01-2012 15:46, Haluk Karamete wrote:
when we do b64e and then back b64d, you are saying. we get the org
input all as clear text but this time as a string. because it is now a
string, "(which by definition can not be executed)"
what's the difference between b64e+b64d vs (string) casting the
when we do b64e and then back b64d, you are saying. we get the org
input all as clear text but this time as a string. because it is now a
string, "(which by definition can not be executed)"
what's the difference between b64e+b64d vs (string) casting then? if
you were to cast the original input int
You don't need to store it in the database as b64, just undo the
encoding into your inputs
for the purpose of the explanation, this is language independent
b64e - encoding function
b64d - decoding function
pseudo code
given:
bad_num = ') union select * from foo --'
bad_str = ""
good_num = 1234
My reply is in >> delims.
> question 1
>
> If you use the PHP filters & sanitizations, and you plan on using PDO
> with binded params, are you absolutely safe? And if not, why? What are
> the other ways for them to still make it in - even with PD0 and bi
> question 1
>
> If you use the PHP filters & sanitizations, and you plan on using PDO
> with binded params, are you absolutely safe? And if not, why? What are
> the other ways for them to still make it in - even with PD0 and binded
> params properly in place? Just curious.
There are no known expl
4 questions... which is basically all it comes to.. After all this
back and forth emails, I think we should nail down these questions
cause they are still not completely covered in my mind.
question 1
If you use the PHP filters & sanitizations, and you plan on using PDO
with binded params, are
Start off with the fact that that article is from 2006, and its
written by a programmer...
> I was simply asking expert opinion with the intention to learn.
> There is so much docs out there (I mean not just out there but at top
> security sites like owasp ) that recommends database specific escap
I was simply asking expert opinion with the intention to learn.
There is so much docs out there (I mean not just out there but at top
security sites like owasp ) that recommends database specific escape
solution as one of the viable alternatives.
You make it seem like anyone who does not use PDO (
There is so much no, answers are in line.
> At the top of each php page which interacts with a database, just have
> this one liner
This has already been mentioned, but again, no, no connection if you
are not actually interacting with the database.
> $DBH = safe_connection("database_name_here");
Thanks Alex. I re-read Ross's reply but I don't think you and him (
and even me ) is saying something different. It's all about validating
the input. In my dictionary of programming vocabulary, validation is
not just validating user input but also sanitizing it.
You summed it up nicely by saying p
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 i
13 matches
Mail list logo