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 into
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
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
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 not
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
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 exploits
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 binded
params properly in place? Just curious.
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 =
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);
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
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 escape
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
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
13 matches
Mail list logo
